From owner-linux-xfs@oss.sgi.com Wed Aug 1 00:14:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f717EWa26539 for linux-xfs-outgoing; Wed, 1 Aug 2001 00:14:32 -0700 Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f717EUV26519 for ; Wed, 1 Aug 2001 00:14:30 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f717EMe26516; Wed, 1 Aug 2001 09:14:23 +0200 Message-Id: <4.3.2.7.2.20010801091242.0340bcc0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Aug 2001 09:14:01 +0200 To: Steve Lord , listac@nebelschwaden.de From: Seth Mos Subject: Re: Cannot compile xfsdump Cc: linux-xfs@oss.sgi.com In-Reply-To: <200107312114.f6VLEmT01740@jen.americas.sgi.com> References: <3B6713D4.9040904@nebelschwaden.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:14 31-7-2001 -0500, Steve Lord wrote: > > Hello, > > > > > > the configure script fails when looking for libxfs.h. I have compiled > > and installed the xfsprogs, but those did for what reason ever not > > install the header files - not even after recompiling. The xfslib.h is > > only existent in the xfsprogrogs source/include directory. Also, > > specifying this dir as includedir or oldincludedir to the xfsdump > > configure script does not help. Neither does a plain copy into > > /usr/include (my --prefix for all xfs related software) or into > > xfsdump/include. > >You need to run > > make install_dev to get header files installed > >Steve Let's add this solution to this part of the configure script. > > FATAL ERROR: could not find a valid XFS library header. > > Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) package. > > root@kaperfahrt:/usr/src/xfs/xfsdump-1.0.9# I'll make a trivial patch. -- 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 Aug 1 00:30:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f717UrV27237 for linux-xfs-outgoing; Wed, 1 Aug 2001 00:30:53 -0700 Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f717UoV27218 for ; Wed, 1 Aug 2001 00:30:51 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f717Uke26598; Wed, 1 Aug 2001 09:30:49 +0200 Message-Id: <4.3.2.7.2.20010801091502.03e65d20@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Aug 2001 09:30:25 +0200 To: "Ralf G. R. Bergs" , "Linux XFS Mailing List" From: Seth Mos Subject: Re: xfs_force_shutdown with linux-2.4.6-xfs-07052001? 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 20:50 31-7-2001 +0200, Ralf G. R. Bergs wrote: >Hi there, > >I'm running Debian/GNU Linux (unstable) on a PC equipped with a Pentium >III-450 >(Katmai), 192 M of RAM, and a RAID (easyRAID II) with 165 GB hooked to an >Adaptec AIC-7881U SCSI host adapter. The kernel I'm using is 2.4.6 with XFS >patch "linux-2.4.6-xfs-07052001" applied. > >Soon after I've written some gigs of data I'm seeing the following in >/var/log/messages: > >Jul 31 14:06:43 server kernel: xfs_force_shutdown(sd(8,5),0x1) called from >line >1013 of file xfs_trans.c. Return address = 0xcc8e71b3 >Jul 31 14:06:43 server kernel: I/O Error Detected. Shutting down >filesystem: sd >(8,5) >Jul 31 14:06:43 server kernel: Please umount the filesystem, and rectify the >problem(s) > >Do you have any idea what could be causing this? Or any hints how to further >investigate the problem? This could be a IO error on the device but since you are using raid that should not be a problem unless the driver is doing funky things. Which compiler did you use to compile the kernel? I am not familiar with the easyraid II. Is that a IDE raid card? If XFS detects an IO error (hardware or software error) it will shut down the fs to prevent further damage. 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 Aug 1 00:48:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f717m2227739 for linux-xfs-outgoing; Wed, 1 Aug 2001 00:48:02 -0700 Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f717m0V27717 for ; Wed, 1 Aug 2001 00:48:00 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f717lxe26662 for ; Wed, 1 Aug 2001 09:47:59 +0200 Message-Id: <4.3.2.7.2.20010801094731.03250768@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Aug 2001 09:47:37 +0200 To: Linux XFS Mailing List From: Seth Mos Subject: Re: Cannot compile xfsdump Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:14 1-8-2001 +0200, you wrote: >At 16:14 31-7-2001 -0500, Steve Lord wrote: >> > Hello, >>Let's add this solution to this part of the configure script. > > > > FATAL ERROR: could not find a valid XFS library header. >> > Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) package. >> > root@kaperfahrt:/usr/src/xfs/xfsdump-1.0.9# > >I'll make a trivial patch. --- configure.in.orig Wed Aug 1 09:32:49 2001 +++ configure.in Wed Aug 1 09:34:29 2001 @@ -140,6 +140,7 @@ echo echo 'FATAL ERROR: could not find a valid XFS library header.' echo 'Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) package.' + echo 'Or do a make install-dev if you do not use packages' exit 1 ]) AC_CHECK_LIB(xfs, libxfs_init,, [ -- 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 Aug 1 00:49:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f717n9e27879 for linux-xfs-outgoing; Wed, 1 Aug 2001 00:49:09 -0700 Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f717n6V27860 for ; Wed, 1 Aug 2001 00:49:06 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f717kxe26658; Wed, 1 Aug 2001 09:47:04 +0200 Message-Id: <4.3.2.7.2.20010801093900.033a2008@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Aug 2001 09:46:38 +0200 To: Peter.Kelemen@cern.ch, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs_force_shutdown with linux-2.4.6-xfs-07052001? In-Reply-To: <20010731221624.A7007@lxplus039.cern.ch> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:16 31-7-2001 +0200, Peter.Kelemen@cern.ch wrote: >* Ralf G. R. Bergs (rabe@rwth-aachen.de) [20010731 20:50]: > > > Jul 31 14:06:43 server kernel: xfs_force_shutdown(sd(8,5),0x1) called from > > line 1013 of file xfs_trans.c. Return address = 0xcc8e71b3 > > Jul 31 14:06:43 server kernel: I/O Error Detected. Shutting down > filesystem: > > sd (8,5) > > Jul 31 14:06:43 server kernel: Please umount the filesystem, and > rectify the > > problem(s) > > > Do you have any idea what could be causing this? Or any hints > > how to further investigate the problem? > >Linux nope 2.4.7-xfs #1 Sun Jul 22 14:59:11 CEST 2001 i686 unknown >Not much, but I experienced a similar event with very light load >today, running CVS 2.4.7 as of 2001/07/22: > >Jul 31 12:52:51 nope kernel: xfs_force_shutdown(lvm(58,0),0x1) called from >line > 4069 of file xfs_bmap.c. Return address = 0xc01863ab >Jul 31 12:52:51 nope kernel: Fatal error on root filesystem >Jul 31 12:52:51 nope kernel: I/O Error Detected. Shutting down filesystem: > lvm(58,0) >Jul 31 12:52:51 nope kernel: Please umount the filesystem, and rectify the > problem(s) > >I upgraded couple of Debian packages while running X, then this >error occured, forcing me to reboot. xfs_repair complained about >inodes not belonging to any files. Some of my shared libs turned >into collection of binary zeroes, my /etc/inetd.conf got linked >(!) to /lib/libkdb.so.1 (and yes, I have *never* had a file with >that name -- weird?!). Otherwise everything seems to be intact. That is probably caused by an IO error. I see you are using lvm which could be related. If an IO error occurs the filesystem will shutdown to prevent more damage. This error could be on the device (bad cluster on the disk) or something in a software layer like md or lvm going wrong which is seen by XFS as a hardware error. What is actually the lvm device. Do you use md or any other software that might interfere? IDE or scsi and what controller and system. How is the lvm device constructed. >Sorry for not being able to provide more exact debugging terms and >not preserving the damaged filesystem, but I had to come around >this as it actually was my workstation's root filesystem. Ah, yes. You tried to actually "work" on a "workstation"? :-) 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 Aug 1 01:14:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f718E1f28549 for linux-xfs-outgoing; Wed, 1 Aug 2001 01:14:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f718E0V28530 for ; Wed, 1 Aug 2001 01:14:00 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id BAA05730 for ; Wed, 1 Aug 2001 01:11:46 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA01368; Wed, 1 Aug 2001 18:12:42 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA26011; Wed, 1 Aug 2001 18:12:31 +1000 (AEST) Date: Wed, 1 Aug 2001 18:12:31 +1000 From: Nathan Scott To: Seth Mos Cc: Linux XFS Mailing List Subject: Re: Cannot compile xfsdump Message-ID: <20010801181231.A228095@wobbly.melbourne.sgi.com> References: <4.3.2.7.2.20010801094731.03250768@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <4.3.2.7.2.20010801094731.03250768@pop.xs4all.nl>; from knuffie@xs4all.nl on Wed, Aug 01, 2001 at 09:47:37AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Aug 01, 2001 at 09:47:37AM +0200, Seth Mos wrote: > At 09:14 1-8-2001 +0200, you wrote: > >At 16:14 31-7-2001 -0500, Steve Lord wrote: > >> > Hello, > >>Let's add this solution to this part of the configure script. > > > ... > --- configure.in.orig Wed Aug 1 09:32:49 2001 > +++ configure.in Wed Aug 1 09:34:29 2001 > @@ -140,6 +140,7 @@ > echo > echo 'FATAL ERROR: could not find a valid XFS library header.' > echo 'Install either the xfsprogs-devel (rpm) or the xfslibs-dev > (deb) package.' > + echo 'Or do a make install-dev if you do not use packages' > exit 1 > ]) > AC_CHECK_LIB(xfs, libxfs_init,, [ > That's a good idea - thanks Seth. I'll incorporate something along these lines tomorrow - there's several other places like this which need the same treatment, IIRC. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 1 01:18:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f718IjN28811 for linux-xfs-outgoing; Wed, 1 Aug 2001 01:18:45 -0700 Received: from relay.dera.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f718IgV28792 for ; Wed, 1 Aug 2001 01:18:42 -0700 Received: (qmail 3923 invoked from network); 1 Aug 2001 09:16:36 +0100 Received: from syntax.dera.gov.uk (146.80.9.50) by relay.dera.gov.uk with SMTP; 1 Aug 2001 09:16:36 +0100 Subject: Re: Busy inodes after umount From: Tony Gale To: Ragnar =?ISO-8859-1?Q?Kj=F8rstad?= Cc: Tad Dolphay , mjacob@feral.com, Christian Chip , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net In-Reply-To: <20010731021546.A7750@vestdata.no> References: <20010719165758.D50024-100000@wonky.feral.com> <200107200038.TAA40153@fsgi158.americas.sgi.com> <20010731021546.A7750@vestdata.no> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/0.11.99 (Preview Release) Date: 01 Aug 2001 09:18:40 +0100 Message-Id: <996653920.2941.0.camel@syntax.dera.gov.uk> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f718IhV28793 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Do you have any other patches in your kernel, such as grsecurity? -tony On 31 Jul 2001 02:15:47 +0200, Ragnar Kjørstad wrote: > On Thu, Jul 19, 2001 at 07:38:15PM -0500, Tad Dolphay wrote: > > > > I've now been able to reproduce: > > > > > > > > * make a filesystem > > > > * mount it > > > > * export it (nfs) > > > > * mount on remote machine > > > > * lock file (fcntl) > > > > * unexport > > > > * unmount > > > > > > > > Then you get the VFS message about self-destruct. Tested with both ext2 > > > > and xfs. > > > > > > > > The lock is still present in /proc/locks after the umount. > > > > > > > > With ext2 I can remount the filesystem successfully, but with XFS I get > > > > the message about duplicate UUIDs and the mount failes. I believe this is a totally > > > > different problem from the one you were experiencing. (and blockdev doesn't help for me) > > > > > > > > I suppose this is a generic kernel bug? > > > > I know there was a fix for a "Busy inodes after unmount" problem in > > 2.4.6-pre3. Here's an excerpt from a posting to the NFS mailing list > > from Neil Brown: > > > > -------------Included message----------------------- > > Previously anonymous dentries were hashed (though with no name, the > > hash was pretty meaningless). This meant that they would hang around > > after the last reference was dropped. This was actually fairly > > pointless as they would never get referenced again, and caused a real > > problem as umount wouldn't discard them and so you got the message > > printk("VFS: Busy inodes after unmount. " > > "Self-destruct in 5 seconds. Have a nice day...\n"); > > > > In 2.4.6-pre3 I stopped hashing those dentries so now when the last > > reference is dropped, the dentry is freed. So now there will never be > > more anonymous dentries than there are active nfsd threads. > > ---------------end included message------------------- > > I just tested with 2.4.7, and the problem remains. > > > -- > Ragnar Kjorstad > Big Storage > From owner-linux-xfs@oss.sgi.com Wed Aug 1 03:01:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71A18k32265 for linux-xfs-outgoing; Wed, 1 Aug 2001 03:01:08 -0700 Received: from mail.isg.de (foobar.isg.de [62.96.243.63]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71A15V32245 for ; Wed, 1 Aug 2001 03:01:05 -0700 Received: from isg.de (wall2-outer.isg.de [62.96.243.126]) by mail.isg.de (Postfix) with ESMTP id BF81874A511; Wed, 1 Aug 2001 12:01:03 +0200 (CEST) Message-ID: <3B67D35E.64877CBF@isg.de> Date: Wed, 01 Aug 2001 12:01:02 +0200 From: Constantin Loizides Organization: Innovative Software AG X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: fsdevel-list , xfs-list , reiserfs-list , jfs-list Subject: Fragmentation of Journaling FS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I would like to announce the new version of my fragmentation project website at http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ Please note, that this page is not intended to jugde and compare the absolut performance of the different filesystems. I rather hope that it may help developers in designing their filesystems and maybe users in deciding which one to choose for which task. It's one of the powers of linux that it provides so many different filesystems, so we should be aware of the pros and cons of each. Two results of the "agesystem" tool I describe on the page, really are strange and need to be understood. Why is there the sharp performance degrade of XFS and JFS? (the cpu time does not show this behaviour, so it seems to be disk time). Surely more work has to be done, newer versions of the systems to be tested, different setups to be tried. Please note, that agesystem is a misleading term, it doesnot age up to now, it just write to the disk once without deletion of any created file. Please read through my descriptions and look at the results, maybe you have ideas and suggestions what to measure in future. At the moment test are running with a different setup, I will describe the tool "agesystem2" on the page today or tomorrow. Regards, Constantin From owner-linux-xfs@oss.sgi.com Wed Aug 1 03:37:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71Abow32728 for linux-xfs-outgoing; Wed, 1 Aug 2001 03:37:50 -0700 Received: from smtp-ft2.fr.colt.net (smtp-ft2.fr.colt.net [213.41.78.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71AblV32709 for ; Wed, 1 Aug 2001 03:37:48 -0700 Received: from [10.233.1.69] ([213.41.95.158]) by smtp-ft2.fr.colt.net with ESMTP id f71Af9b14301 for ; Wed, 1 Aug 2001 12:41:09 +0200 Subject: xfs_force_shutdown with kernel 2.4.3-SGI_XFS_1.0.1 From: angus To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11.99 (Preview Release) Date: 01 Aug 2001 12:34:53 +0200 Message-Id: <996662095.6013.16.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I had one problem with a linux box in xFS. This box is in IDE (no VIA or other buggy chipset), no RAID SOFT or LVM. This is the dmesg output: xfs_force_shutdown(ide0(3,8),0x1) called from line 4069 of file xfs_bmap.c. Return address = 0xc017fbcb I/O Error Detected. Shutting down filesystem: ide0(3,8) Please umount the filesystem, and rectify the problem(s) ide0(3,8) is the /var partition lspci output: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:04.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:0f.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 03) My system was unaccessible and I reboot the system, boot in linux-rescue mode (with CD1) and ran xfs_repair on all xFS partition. there was no error and the system restart perfectly. The uptime of this system was around 2 days so I prefer to solve the problem before this week-end :) I can provide additionnal information. Any help will be appreciate. Thanks. -David From owner-linux-xfs@oss.sgi.com Wed Aug 1 03:57:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71Avvx00535 for linux-xfs-outgoing; Wed, 1 Aug 2001 03:57:57 -0700 Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71AvsV00515 for ; Wed, 1 Aug 2001 03:57:54 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f71Avne27380; Wed, 1 Aug 2001 12:57:51 +0200 Message-Id: <4.3.2.7.2.20010801124904.03ced9d8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Aug 2001 12:57:27 +0200 To: angus , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs_force_shutdown with kernel 2.4.3-SGI_XFS_1.0.1 In-Reply-To: <996662095.6013.16.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:34 1-8-2001 +0200, angus wrote: >Hello, > >I had one problem with a linux box in xFS. >This box is in IDE (no VIA or other buggy chipset), >no RAID SOFT or LVM. > >This is the dmesg output: > >xfs_force_shutdown(ide0(3,8),0x1) called from line 4069 of file >xfs_bmap.c. Return address = 0xc017fbcb >I/O Error Detected. Shutting down filesystem: ide0(3,8) >Please umount the filesystem, and rectify the problem(s) This is error is common when XFS runs into IO error. It is there to protect your data. Since in your case there is nothing in between the disk and the fs layer I suspect that you have run into a bad cluster on your disk. This is not always fatal since in some cases the newer IDE drives will map a bad cluster out to a new one that is spare. This will be done untill all spare clusters inside the disk are gone and then will produce errors. Note: If you have S.M.A.R.T. you can be notified when a drive is going bad. This does not always work right since some disks will only start reporting errors when all the spare clusters are gone while others start barking loudly and give warnings when it starts mapping out bad clusters in the first place. Each disks manufacturer behaves different. What also can happen is that a bad cluster is detected but it is not restored untill the first powercycle/reboot. This is something that has been observed but should not happen. It's a very rare case. Maybe the folks at linux-ide.org can tell you something more. 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 Aug 1 04:53:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71Brw001558 for linux-xfs-outgoing; Wed, 1 Aug 2001 04:53:58 -0700 Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71BrtV01539 for ; Wed, 1 Aug 2001 04:53:55 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f71Brse27602 for ; Wed, 1 Aug 2001 13:53:54 +0200 Message-Id: <4.3.2.7.2.20010801135320.03246bb8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Aug 2001 13:53:32 +0200 To: Linux XFS Mailing List From: Seth Mos Subject: Re: xfs_force_shutdown with kernel 2.4.3-SGI_XFS_1.0.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:57 1-8-2001 +0200, you wrote: >At 12:34 1-8-2001 +0200, angus wrote: >>Hello, >> >>I had one problem with a linux box in xFS. >>This box is in IDE (no VIA or other buggy chipset), >>no RAID SOFT or LVM. >> >>This is the dmesg output: >> >>xfs_force_shutdown(ide0(3,8),0x1) called from line 4069 of file >>xfs_bmap.c. Return address = 0xc017fbcb >>I/O Error Detected. Shutting down filesystem: ide0(3,8) >>Please umount the filesystem, and rectify the problem(s) Added to the FAQ -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Aug 1 06:05:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71D5Eh02575 for linux-xfs-outgoing; Wed, 1 Aug 2001 06:05:14 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71D59V02556 for ; Wed, 1 Aug 2001 06:05:09 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) 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 GAA06518 for ; Wed, 1 Aug 2001 06:04:43 -0700 (PDT) mail_from (leh@mail.tecosim.de) Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f71CRxX20348; Wed, 1 Aug 2001 14:27:59 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdBOD0SD; Wed Aug 1 14:27:49 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f71ChN430822; Wed, 1 Aug 2001 14:43:23 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f71ChNR07578; Wed, 1 Aug 2001 14:43:23 +0200 Date: Wed, 1 Aug 2001 14:43:23 +0200 From: Utz Lehmann To: Constantin Loizides Cc: xfs-list Subject: Re: Fragmentation of Journaling FS Message-ID: <20010801144322.C1132@de.tecosim.com> References: <3B67D35E.64877CBF@isg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B67D35E.64877CBF@isg.de>; from Constantin.Loizides@isg.de on Wed, Aug 01, 2001 at 12:01:02PM +0200 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Constantin Sorry, I'm in doubt with the sharp performace drop at 50% disk usage on a xfs filesystem. I made a quick and dirty test running this: while time cp -a /usr/src/linux/drivers/ /mnt/xxx-`date '+%s'`; do sync; \ df | grep mnt; done /mnt is a 4GB lvm volume on a 18GB 10000rpm IBM SCSI Disk. It's formatted with default mkfs.xfs (no tuning). /usr is a LVM volume on this disk too. Athlon 650/ 256MB RAM. Linux-xfs kernel 2.4.8-pre3 (CVS from 2001-07-31). The test was running in multiuser mode with X. du -ks /usr/src/linux/drivers/ 73980 /usr/src/linux/drivers Here are the results: user system elapsed CPU Used Avail. Use% 0.10 2.98 0:30.25 10% 95196 4094308 3% 0.15 2.78 0:29.47 9% 169176 4020328 5% 0.14 2.75 0:27.83 10% 243156 3946348 6% 0.15 2.86 0:27.04 11% 317136 3872368 8% 0.03 3.10 0:26.61 11% 391116 3798388 10% 0.07 2.86 0:27.88 10% 465096 3724408 12% 0.09 3.04 0:27.26 11% 539076 3650428 13% 0.14 3.02 0:27.06 11% 613060 3576444 15% 0.10 2.98 0:27.48 11% 687040 3502464 17% 0.11 3.14 0:28.07 11% 761020 3428484 19% 0.13 3.12 0:28.17 11% 835000 3354504 20% 0.12 3.19 0:28.03 11% 908980 3280524 22% 0.09 3.27 0:27.71 12% 983024 3206480 24% 0.05 3.04 0:27.93 11% 1057452 3132052 26% 0.18 3.06 0:28.12 11% 1131816 3057688 28% 0.13 3.24 0:28.57 11% 1206244 2983260 29% 0.10 3.04 0:28.55 10% 1280608 2908896 31% 0.16 3.61 0:28.37 13% 1355036 2834468 33% 0.12 3.26 0:28.59 11% 1429400 2760104 35% 0.16 3.10 0:29.04 11% 1503844 2685660 36% 0.08 3.66 0:29.75 12% 1578192 2611312 38% 0.12 3.63 0:29.05 12% 1652604 2536900 40% 0.11 3.60 0:29.53 12% 1726968 2462536 42% 0.20 3.70 0:29.48 13% 1801396 2388108 43% 0.13 3.81 0:29.24 13% 1876096 2313408 45% 0.12 3.72 0:29.29 13% 1950908 2238596 47% 0.12 3.97 0:29.96 13% 2025720 2163784 49% 0.22 3.78 0:29.46 13% 2100532 2088972 51% 0.08 3.94 0:30.05 13% 2175104 2014400 52% 0.10 3.76 0:30.35 12% 2249084 1940420 54% 0.15 3.61 0:30.43 12% 2323240 1866264 56% 0.18 3.45 0:29.15 12% 2398116 1791388 58% 0.06 4.04 0:29.33 13% 2473056 1716448 60% 0.16 3.94 0:31.83 12% 2547996 1641508 61% 0.16 3.71 0:34.60 11% 2622920 1566584 63% 0.10 4.12 0:30.80 13% 2697876 1491628 65% 0.12 4.13 0:29.61 14% 2772768 1416736 67% 0.14 3.99 0:30.26 13% 2847708 1341796 68% 0.15 3.81 0:29.50 13% 2922632 1266872 70% 0.12 3.93 0:29.31 13% 2997572 1191932 72% 0.10 4.07 0:29.44 14% 3072512 1116992 74% 0.18 4.13 0:33.74 12% 3147468 1042036 76% 0.19 4.09 0:36.55 11% 3222424 967080 77% 0.16 4.00 0:36.65 11% 3297364 892140 79% 0.19 4.50 0:34.12 13% 3372304 817200 81% 0.13 4.38 0:37.02 12% 3447244 742260 83% 0.06 4.38 0:36.82 12% 3522168 667336 85% 0.11 4.21 0:41.77 10% 3597124 592380 86% 0.11 4.11 0:38.03 11% 3672016 517488 88% 0.12 3.97 0:38.16 10% 3746956 442548 90% 0.17 4.33 0:47.37 9% 3821896 367608 92% 0.15 4.53 0:47.34 9% 3896820 292684 94% 0.16 4.34 0:46.26 9% 3971760 217744 95% 0.16 4.30 0:47.54 9% 4046700 142804 97% 0.16 4.31 0:49.44 9% 4121640 67864 99% My results looks very resonable for me. A sliding performance degrade with a full disk. No performace sharp drop at about 50% usage. This is my real life experience too. Is it possible to get your agesystem tool? cheers utz lehmann Constantin Loizides [Constantin.Loizides@isg.de] wrote: > Hello, > > I would like to announce the new version of my > fragmentation project website at > > http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ [...] > > Two results of the "agesystem" tool I describe on the page, really are > strange and need to be understood. Why is there the sharp performance > degrade > of XFS and JFS? (the cpu time does not show this behaviour, so it > seems to be disk time). Surely more work has to be done, newer versions > of the > systems to be tested, different setups to be tried. Please note, > that agesystem is a misleading term, it doesnot age up to now, it just > write to the disk once without deletion of any created file. [...] From owner-linux-xfs@oss.sgi.com Wed Aug 1 06:19:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71DJmo02910 for linux-xfs-outgoing; Wed, 1 Aug 2001 06:19:48 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71DJiV02891 for ; Wed, 1 Aug 2001 06:19:44 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA07839 for ; Wed, 1 Aug 2001 06:17:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2583545; Wed, 1 Aug 2001 08:18:26 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA78539; Wed, 1 Aug 2001 08:18:26 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f71DJAA03114; Wed, 1 Aug 2001 08:19:10 -0500 Message-Id: <200108011319.f71DJAA03114@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Utz Lehmann cc: Constantin Loizides , xfs-list Subject: Re: Fragmentation of Journaling FS In-Reply-To: Message from Utz Lehmann of "Wed, 01 Aug 2001 14:43:23 +0200." <20010801144322.C1132@de.tecosim.com> Date: Wed, 01 Aug 2001 08:19:10 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi Constantin > > Sorry, I'm in doubt with the sharp performace drop at 50% disk usage on a > xfs filesystem. Hmmm, you probably need to do some random deleting in between times here, if I read Constantin's page correctly he is trying to simulate the an aged filesystem which has had lots of data created and removed over time - this has the effect of making the free space distribution a lot more random. Steve > > I made a quick and dirty test running this: > > while time cp -a /usr/src/linux/drivers/ /mnt/xxx-`date '+%s'`; do sync; \ > df | grep mnt; done > > > /mnt is a 4GB lvm volume on a 18GB 10000rpm IBM SCSI Disk. > It's formatted with default mkfs.xfs (no tuning). > /usr is a LVM volume on this disk too. > Athlon 650/ 256MB RAM. > Linux-xfs kernel 2.4.8-pre3 (CVS from 2001-07-31). > The test was running in multiuser mode with X. > > du -ks /usr/src/linux/drivers/ > 73980 /usr/src/linux/drivers > > > Here are the results: > > user system elapsed CPU Used Avail. Use% > > 0.10 2.98 0:30.25 10% 95196 4094308 3% > 0.15 2.78 0:29.47 9% 169176 4020328 5% > 0.14 2.75 0:27.83 10% 243156 3946348 6% > 0.15 2.86 0:27.04 11% 317136 3872368 8% > 0.03 3.10 0:26.61 11% 391116 3798388 10% > 0.07 2.86 0:27.88 10% 465096 3724408 12% > 0.09 3.04 0:27.26 11% 539076 3650428 13% > 0.14 3.02 0:27.06 11% 613060 3576444 15% > 0.10 2.98 0:27.48 11% 687040 3502464 17% > 0.11 3.14 0:28.07 11% 761020 3428484 19% > 0.13 3.12 0:28.17 11% 835000 3354504 20% > 0.12 3.19 0:28.03 11% 908980 3280524 22% > 0.09 3.27 0:27.71 12% 983024 3206480 24% > 0.05 3.04 0:27.93 11% 1057452 3132052 26% > 0.18 3.06 0:28.12 11% 1131816 3057688 28% > 0.13 3.24 0:28.57 11% 1206244 2983260 29% > 0.10 3.04 0:28.55 10% 1280608 2908896 31% > 0.16 3.61 0:28.37 13% 1355036 2834468 33% > 0.12 3.26 0:28.59 11% 1429400 2760104 35% > 0.16 3.10 0:29.04 11% 1503844 2685660 36% > 0.08 3.66 0:29.75 12% 1578192 2611312 38% > 0.12 3.63 0:29.05 12% 1652604 2536900 40% > 0.11 3.60 0:29.53 12% 1726968 2462536 42% > 0.20 3.70 0:29.48 13% 1801396 2388108 43% > 0.13 3.81 0:29.24 13% 1876096 2313408 45% > 0.12 3.72 0:29.29 13% 1950908 2238596 47% > 0.12 3.97 0:29.96 13% 2025720 2163784 49% > 0.22 3.78 0:29.46 13% 2100532 2088972 51% > 0.08 3.94 0:30.05 13% 2175104 2014400 52% > 0.10 3.76 0:30.35 12% 2249084 1940420 54% > 0.15 3.61 0:30.43 12% 2323240 1866264 56% > 0.18 3.45 0:29.15 12% 2398116 1791388 58% > 0.06 4.04 0:29.33 13% 2473056 1716448 60% > 0.16 3.94 0:31.83 12% 2547996 1641508 61% > 0.16 3.71 0:34.60 11% 2622920 1566584 63% > 0.10 4.12 0:30.80 13% 2697876 1491628 65% > 0.12 4.13 0:29.61 14% 2772768 1416736 67% > 0.14 3.99 0:30.26 13% 2847708 1341796 68% > 0.15 3.81 0:29.50 13% 2922632 1266872 70% > 0.12 3.93 0:29.31 13% 2997572 1191932 72% > 0.10 4.07 0:29.44 14% 3072512 1116992 74% > 0.18 4.13 0:33.74 12% 3147468 1042036 76% > 0.19 4.09 0:36.55 11% 3222424 967080 77% > 0.16 4.00 0:36.65 11% 3297364 892140 79% > 0.19 4.50 0:34.12 13% 3372304 817200 81% > 0.13 4.38 0:37.02 12% 3447244 742260 83% > 0.06 4.38 0:36.82 12% 3522168 667336 85% > 0.11 4.21 0:41.77 10% 3597124 592380 86% > 0.11 4.11 0:38.03 11% 3672016 517488 88% > 0.12 3.97 0:38.16 10% 3746956 442548 90% > 0.17 4.33 0:47.37 9% 3821896 367608 92% > 0.15 4.53 0:47.34 9% 3896820 292684 94% > 0.16 4.34 0:46.26 9% 3971760 217744 95% > 0.16 4.30 0:47.54 9% 4046700 142804 97% > 0.16 4.31 0:49.44 9% 4121640 67864 99% > > > My results looks very resonable for me. A sliding performance degrade with a > full disk. No performace sharp drop at about 50% usage. > > This is my real life experience too. > > Is it possible to get your agesystem tool? > > > cheers > > utz lehmann > > > > > Constantin Loizides [Constantin.Loizides@isg.de] wrote: > > Hello, > > > > I would like to announce the new version of my > > fragmentation project website at > > > > http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ > [...] > > > > Two results of the "agesystem" tool I describe on the page, really are > > strange and need to be understood. Why is there the sharp performance > > degrade > > of XFS and JFS? (the cpu time does not show this behaviour, so it > > seems to be disk time). Surely more work has to be done, newer versions > > of the > > systems to be tested, different setups to be tried. Please note, > > that agesystem is a misleading term, it doesnot age up to now, it just > > write to the disk once without deletion of any created file. > [...] From owner-linux-xfs@oss.sgi.com Wed Aug 1 06:53:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71Druu03399 for linux-xfs-outgoing; Wed, 1 Aug 2001 06:53:56 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71DrrV03379 for ; Wed, 1 Aug 2001 06:53:53 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f71DZX620627; Wed, 1 Aug 2001 15:35:33 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdbwBQo5; Wed Aug 1 15:35:28 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f71Dp3402325; Wed, 1 Aug 2001 15:51:03 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f71Dp3Q09089; Wed, 1 Aug 2001 15:51:03 +0200 Date: Wed, 1 Aug 2001 15:51:03 +0200 From: Utz Lehmann To: Steve Lord Cc: Utz Lehmann , Constantin Loizides , xfs-list Subject: Re: Fragmentation of Journaling FS Message-ID: <20010801155102.D1132@de.tecosim.com> References: <200108011319.f71DJAA03114@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108011319.f71DJAA03114@jen.americas.sgi.com>; from lord@sgi.com on Wed, Aug 01, 2001 at 08:19:10AM -0500 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve Steve Lord [lord@sgi.com] wrote: > > Hi Constantin > > > > Sorry, I'm in doubt with the sharp performace drop at 50% disk usage on a > > xfs filesystem. > > Hmmm, you probably need to do some random deleting in between times here, > if I read Constantin's page correctly he is trying to simulate the an > aged filesystem which has had lots of data created and removed over > time - this has the effect of making the free space distribution a lot > more random. > > Steve >From Constantin's mail: Please note, that agesystem is a misleading term, it doesnot age up to now, it just write to the disk once without deletion of any created file. utz From owner-linux-xfs@oss.sgi.com Wed Aug 1 06:55:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71Dt7X03508 for linux-xfs-outgoing; Wed, 1 Aug 2001 06:55:07 -0700 Received: from mail.isg.de (foobar.isg.de [62.96.243.63]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71Dt4V03477 for ; Wed, 1 Aug 2001 06:55:04 -0700 Received: from isg.de (wall2-outer.isg.de [62.96.243.126]) by mail.isg.de (Postfix) with ESMTP id BAACF750163; Wed, 1 Aug 2001 15:55:03 +0200 (CEST) Message-ID: <3B680A34.C08783AC@isg.de> Date: Wed, 01 Aug 2001 15:55:00 +0200 From: Constantin Loizides Organization: Innovative Software AG X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Utz Lehmann , xfs-list Subject: Re: Fragmentation of Journaling FS References: <3B67D35E.64877CBF@isg.de> <20010801144322.C1132@de.tecosim.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Utz, > Sorry, I'm in doubt with the sharp performace drop at 50% disk usage on a > xfs filesystem. No need to be sorry :-) > > I made a quick and dirty test running this: > > while time cp -a /usr/src/linux/drivers/ /mnt/xxx-`date '+%s'`; do sync; \ > df | grep mnt; done > Ok, will try this when my test system is available... Please notice, that I am using a different setup: different version of xfs, different file size distribution (i checked that on my /drivers/ dir) Can you check your test on a small partition of 512 MB, just to make sure, that it gives the same flatness? > > My results looks very resonable for me. A sliding performance degrade with a > full disk. No performace sharp drop at about 50% usage. Yes, indeed, that looks by far more reasonable, compare it to my 1GB results which are also quit smooth and only slowly degrading. > > Is it possible to get your agesystem tool? > Yes, I will make it available on the web. Constantin From owner-linux-xfs@oss.sgi.com Wed Aug 1 07:22:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71EMYP03971 for linux-xfs-outgoing; Wed, 1 Aug 2001 07:22:34 -0700 Received: from mail.isg.de (foobar.isg.de [62.96.243.63]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71EMWV03952 for ; Wed, 1 Aug 2001 07:22:32 -0700 Received: from isg.de (wall2-outer.isg.de [62.96.243.126]) by mail.isg.de (Postfix) with ESMTP id B7B2D43ECA7; Wed, 1 Aug 2001 16:22:31 +0200 (CEST) Message-ID: <3B6810A7.C5C7FFAE@isg.de> Date: Wed, 01 Aug 2001 16:22:31 +0200 From: Constantin Loizides Organization: Innovative Software AG X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord Cc: xfs-list Subject: Re: Fragmentation of Journaling FS References: <3B67D35E.64877CBF@isg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, thanks for the comment, I quote it as you sent it directly to me: > > Interesting project, you should note however that your filesystem sizes > are VERY small in XFS terms, scalable for XFS is refering to scalable > upwards. You might also want to think about having filesystems which are > many times your memory size - at 512M you are only 4 times the memory size, > so a good percentage of the filesystem will be cachable. Yes, that might be a problem, but it was a quick way to test the setup of the kernel patches (all went into 2.4.5) > > XFS divides the disk space into allocation groups, these are independent > chunks of space management. The mkfs output will show you how many you have, > the mkfs.xfs man page will tell you how to experiment with them. You default > to having 8 on a device this small, the allocation groups can be up to > 4Gbytes each. The drop off in XFS performance at the full filesystem end > of things is probably caused by having to scan multiple allocation groups > looking for space - there is an in memory summary, but allocations are > probably getting scattered around several allocation groups at this point. > > You may find that the performance drop off is caused by seek activity > in order to get to the log, on ext2 pretty much all seek activity will > be outside the user's context and happen in the background. With XFS > at least you can put the log on a separate device and see what happens > to the numbers. > Ok, that would be easy to check and redo the gauge runs on a system where the log is on a different device. Constantin From owner-linux-xfs@oss.sgi.com Wed Aug 1 07:55:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71Et4O04687 for linux-xfs-outgoing; Wed, 1 Aug 2001 07:55:04 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71Et0V04668 for ; Wed, 1 Aug 2001 07:55:00 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f71EbGp20938; Wed, 1 Aug 2001 16:37:16 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdfpaZjU; Wed Aug 1 16:37:11 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f71Eqk405898; Wed, 1 Aug 2001 16:52:46 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f71EqkQ10892; Wed, 1 Aug 2001 16:52:46 +0200 Date: Wed, 1 Aug 2001 16:52:46 +0200 From: Utz Lehmann To: Constantin Loizides Cc: Utz Lehmann , xfs-list Subject: Re: Fragmentation of Journaling FS Message-ID: <20010801165246.F1132@de.tecosim.com> References: <3B67D35E.64877CBF@isg.de> <20010801144322.C1132@de.tecosim.com> <3B680A34.C08783AC@isg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B680A34.C08783AC@isg.de>; from Constantin.Loizides@isg.de on Wed, Aug 01, 2001 at 03:55:00PM +0200 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Constantin Constantin Loizides [Constantin.Loizides@isg.de] wrote: > > I made a quick and dirty test running this: > > > > while time cp -a /usr/src/linux/drivers/ /mnt/xxx-`date '+%s'`; do sync; \ > > df | grep mnt; done > > > Ok, will try this when my test system is available... > > Please notice, that I am using a different setup: > different version of xfs, > different file size distribution (i checked that on my /drivers/ dir) > > Can you check your test on a small partition of 512 MB, just to > make sure, that it gives the same flatness? Ok, i have run my test on a 1GB and 512MB volume (using lvreduce). 1GB volume: user system elapsed CPU Used Avail. Use% 0.10 2.55 0:22.01 12% 75100 968676 8% 0.17 2.98 0:22.92 13% 150040 893736 15% 0.09 2.62 0:22.63 11% 224996 818780 22% 0.14 2.77 0:22.51 12% 299952 743824 29% 0.08 3.01 0:23.24 13% 374892 668884 36% 0.10 2.92 0:22.77 13% 449832 593944 44% 0.18 2.89 0:22.95 13% 524772 519004 51% 0.07 3.10 0:22.88 13% 599668 444108 58% 0.09 3.11 0:22.95 13% 674592 369184 65% 0.12 2.78 0:23.20 12% 749516 294260 72% 0.14 3.02 0:23.92 13% 824456 219320 79% 0.14 3.11 0:24.03 13% 899412 144364 87% 0.14 3.29 0:23.91 14% 974304 69472 94% 512MB volume: user system elapsed CPU Used Avail. Use% 0.12 2.60 0:16.69 16% 75100 444388 15% 0.16 2.68 0:17.29 16% 150040 369448 29% 0.09 2.72 0:16.96 16% 224996 294492 44% 0.11 2.61 0:16.62 16% 299904 219584 58% 0.11 2.60 0:16.29 16% 374828 144660 73% 0.12 2.79 0:15.70 18% 449768 69720 87% No sharp drop. That the elapsed time is reduced by the volume size is very interessting. On the 512MB volume it's only half of the 4GB volume. My test is very quick and very dirty. btw: For your agesystem you can maybe add following: - random file deletion - deletion of whole trees - simultaneous writing of files (very important, a lot of filesystems are fragmenting these files badly) - appending to files in different sized pieces (like logfiles) utz From owner-linux-xfs@oss.sgi.com Wed Aug 1 08:23:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71FNIw05304 for linux-xfs-outgoing; Wed, 1 Aug 2001 08:23:18 -0700 Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71FNGV05285 for ; Wed, 1 Aug 2001 08:23:16 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f71FNCe28264; Wed, 1 Aug 2001 17:23:12 +0200 Message-Id: <4.3.2.7.2.20010801172159.0324d9f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Aug 2001 17:22:51 +0200 To: Utz Lehmann , Constantin Loizides From: Seth Mos Subject: Re: Fragmentation of Journaling FS Cc: xfs-list In-Reply-To: <20010801165246.F1132@de.tecosim.com> References: <3B680A34.C08783AC@isg.de> <3B67D35E.64877CBF@isg.de> <20010801144322.C1132@de.tecosim.com> <3B680A34.C08783AC@isg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:52 1-8-2001 +0200, Utz Lehmann wrote: >Hi Constantin > >No sharp drop. >That the elapsed time is reduced by the volume size is very interessting. On >the 512MB volume it's only half of the 4GB volume. My test is very quick and >very dirty. > > >btw: For your agesystem you can maybe add following: >- random file deletion >- deletion of whole trees >- simultaneous writing of files (very important, a lot of filesystems are > fragmenting these files badly) >- appending to files in different sized pieces (like logfiles) And after running those test using xfs_fsr to see if it helps :-) 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 Aug 1 08:43:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71FhkJ05852 for linux-xfs-outgoing; Wed, 1 Aug 2001 08:43:46 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71FhjV05831 for ; Wed, 1 Aug 2001 08:43:45 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA26194 for ; Wed, 1 Aug 2001 08:43:32 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2585692; Wed, 1 Aug 2001 10:42:28 -0500 (CDT) 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 KAA13448; Wed, 1 Aug 2001 10:42:28 -0500 (CDT) Subject: Re: Fragmentation of Journaling FS From: Eric Sandeen To: Seth Mos Cc: Utz Lehmann , Constantin Loizides , xfs-list In-Reply-To: <4.3.2.7.2.20010801172159.0324d9f8@pop.xs4all.nl> References: <3B680A34.C08783AC@isg.de> <3B67D35E.64877CBF@isg.de> <20010801144322.C1132@de.tecosim.com> <3B680A34.C08783AC@isg.de> <4.3.2.7.2.20010801172159.0324d9f8@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 01 Aug 2001 10:40:13 -0500 Message-Id: <996680413.1458.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 01 Aug 2001 17:22:51 +0200, Seth Mos wrote: > And after running those test using xfs_fsr to see if it helps :-) Actually..... I'm chasing down a problem with xfs_fsr at the moment, after running fsstress for a while to create a bunch of fragmented files, then running xfs_fsr, and then trying to unmount the filesystem, we wind up with some busy inodes. Feel free to try it out, but you may hit this problem at the moment. -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 Aug 1 08:58:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71Fwgr06355 for linux-xfs-outgoing; Wed, 1 Aug 2001 08:58:42 -0700 Received: from bobas.nowytarg.top.pl (ghostwheel.underley.eu.org [217.97.235.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71FwcV06335 for ; Wed, 1 Aug 2001 08:58:39 -0700 Received: by bobas.nowytarg.top.pl with BSMTP id ; Wed, 1 Aug 2001 18:01:03 +0200 Received: by witch.underley.eu.org id ; Tue, 31 Jul 2001 22:57:52 +0200 Date: Tue, 31 Jul 2001 22:57:52 +0200 From: Daniel Podlejski To: linux-xfs@oss.sgi.com Subject: 2.4.7-xfs from CVS and missing files Message-ID: <20010731225752.A14071@witch.underley.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i X-PGP-Fingerprint: 4D 72 53 F8 FE 8C 53 B9 66 AD F6 EA C9 17 CD 82 X-GPG-Fingerprint: 299F 1820 582B 283A 5F50 37D9 AA0B 6E10 03D4 EA5D X-Homepage: http://www.underley.eu.org/ X-Cert: http://www.brainbench.com/transcript.jsp?pid=124954 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, 2.4.7-xfs kernel, compiled with gcc 2.95.4 some random files disappear, there are in directory, but when I stat them, I go "no such file" error. After reboot everything is ok. I'm not try newer cvs version yet. -- Daniel Podlejski ... Seven deadly sins, Seven ways to win Seven holy paths to hell, And your trip begins ... From owner-linux-xfs@oss.sgi.com Wed Aug 1 09:15:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71GFb006810 for linux-xfs-outgoing; Wed, 1 Aug 2001 09:15:37 -0700 Received: from imapserver2.fnal.gov (imapserver2.fnal.gov [131.225.9.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71GFZV06791 for ; Wed, 1 Aug 2001 09:15:35 -0700 Received: from imapserver2.fnal.gov ([131.225.9.7]) by imapserver2.fnal.gov (Netscape Messaging Server 3.62) with SMTP id 1188 for ; Wed, 1 Aug 2001 11:15:34 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserver2.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001080111153402211 for ; Wed, 01 Aug 2001 11:15:34 -0500 Message-ID: <3B682BBE.3A29386D@fnal.gov> Date: Wed, 01 Aug 2001 11:18:06 -0500 From: yocum@fnal.gov 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: XFS fs size limit? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I asked this of mkp but he doesn't know off the top of his head: is there a limit to the XFS fs size? I've tried creating one on just over 1.1TB with no success: [root@sdssdp6 /]# fdisk -l /dev/md6 Device Boot Start End Blocks Id System /dev/md6p1 1 280147712 1120590846 83 Linux [root@sdssdp6 /]# mkfs.xfs /dev/md6 mkfs.xfs: can't get size for data subvolume Usage: mkfs.xfs /* blocksize */ [-b log=n|size=num] /* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num, sunit=value,swidth=value,unwritten=0|1, su=value,sw=value] /* inode size */ [-i log=n|perblock=n|size=num,maxpct=n] /* log subvol */ [-l agnum=n,internal,size=num,logdev=xxx] /* naming */ [-n log=n|size=num|version=n] /* label */ [-L label (maximum 12 characters)] /* prototype file */ [-p fname] /* quiet */ [-q] /* version */ [-V] /* realtime subvol */ [-r extsize=num,size=num,rtdev=xxx] devicename is required unless -d name=xxx is given. Internal log by default, size is scaled from 1,000 blocks to 32,768 blocks based on the filesystem size. Default log reaches its largest size at 1TB. This can be overridden with the -l options or using a volume manager with a log subvolume. is xxx (bytes), or xxxb (blocks), or xxxk (xxx KB), or xxxm (xxx MB) is xxx (512 blocks). >From recent comments made by Steve, (http://oss.sgi.com/projects/xfs/mail_archive/0107/msg00727.html) it sounds that since I'm trying to make a fs with inode numbers > 32 bits, I might be hosed. FWIW, I'm using 2.4.5 kernel with R1.0.1. 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 Wed Aug 1 10:02:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71H2hY08165 for linux-xfs-outgoing; Wed, 1 Aug 2001 10:02:43 -0700 Received: from mail.isg.de (foobar.isg.de [62.96.243.63]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71H2fV08146 for ; Wed, 1 Aug 2001 10:02:41 -0700 Received: from isg.de (wall2-outer.isg.de [62.96.243.126]) by mail.isg.de (Postfix) with ESMTP id A328F750D61; Wed, 1 Aug 2001 19:02:40 +0200 (CEST) Message-ID: <3B683630.5BBEE21C@isg.de> Date: Wed, 01 Aug 2001 19:02:40 +0200 From: Constantin Loizides Organization: Innovative Software AG X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Constantin Loizides Cc: xfs-list Subject: Re: Fragmentation of Journaling FS References: <3B67D35E.64877CBF@isg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I put agesystem on the web (with explanation). There is also a tool fibmap(with explanation) I would like you to use it on the directory after finishing agesystem. eg. if /mnt/test is the partition to test -d /mnt/test for agesystem , then call "fibmap /mnt/test" and send the resulting output to me, please. Cheers, Constantin From owner-linux-xfs@oss.sgi.com Wed Aug 1 11:06:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71I6A109331 for linux-xfs-outgoing; Wed, 1 Aug 2001 11:06:10 -0700 Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71I68V09312 for ; Wed, 1 Aug 2001 11:06:08 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.9.3/8.9.3) id UAA31977; Wed, 1 Aug 2001 20:05:51 +0200 Date: Wed, 1 Aug 2001 20:05:50 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Tony Gale Cc: Tad Dolphay , mjacob@feral.com, Christian Chip , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net Subject: Re: Busy inodes after umount Message-ID: <20010801200550.B30796@vestdata.no> References: <20010719165758.D50024-100000@wonky.feral.com> <200107200038.TAA40153@fsgi158.americas.sgi.com> <20010731021546.A7750@vestdata.no> <996653920.2941.0.camel@syntax.dera.gov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <996653920.2941.0.camel@syntax.dera.gov.uk>; from Tony Gale on Wed, Aug 01, 2001 at 09:18:40AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 01, 2001 at 09:18:40AM +0100, Tony Gale wrote: > Do you have any other patches in your kernel, such as grsecurity? The only patch I have is the xfs patch. -- Ragnar Kjorstad Big Storage From owner-linux-xfs@oss.sgi.com Wed Aug 1 14:17:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71LHOm12198 for linux-xfs-outgoing; Wed, 1 Aug 2001 14:17:24 -0700 Received: from zok.corp.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71LHLV12178 for ; Wed, 1 Aug 2001 14:17:21 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f71LMQm06679 for ; Wed, 1 Aug 2001 14:22:26 -0700 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 QAA2594727 for ; Wed, 1 Aug 2001 16:15:52 -0500 (CDT) 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 LAA09681; Wed, 1 Aug 2001 11:44:19 -0500 (CDT) Subject: Re: 2.4.7-xfs from CVS and missing files From: Eric Sandeen To: Daniel Podlejski Cc: linux-xfs@oss.sgi.com In-Reply-To: <20010731225752.A14071@witch.underley.eu.org> References: <20010731225752.A14071@witch.underley.eu.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 01 Aug 2001 11:42:03 -0500 Message-Id: <996684313.1496.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 31 Jul 2001 22:57:52 +0200, Daniel Podlejski wrote: > Hi, > > 2.4.7-xfs kernel, compiled with gcc 2.95.4 > > some random files disappear, there are in directory, > but when I stat them, I go "no such file" error. > After reboot everything is ok. Is there any chance you could try compiling it with gcc 2.91.66, and see if the problem persists? -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 Aug 1 14:17:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71LHTI12223 for linux-xfs-outgoing; Wed, 1 Aug 2001 14:17:29 -0700 Received: from zok.corp.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71LHRV12203 for ; Wed, 1 Aug 2001 14:17:27 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f71LMWm06683 for ; Wed, 1 Aug 2001 14:22:32 -0700 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 QAA2464930; Wed, 1 Aug 2001 16:15:57 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA66318; Wed, 1 Aug 2001 13:29:41 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f71IUN203982; Wed, 1 Aug 2001 13:30:23 -0500 Message-Id: <200108011830.f71IUN203982@jen.americas.sgi.com> To: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= cc: Tony Gale , Tad Dolphay , mjacob@feral.com, Christian Chip , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net Subject: Re: Busy inodes after umount References: <20010719165758.D50024-100000@wonky.feral.com> <200107200038.TAA40153@fsgi158.americas.sgi.com> <20010731021546.A7750@vestdata.no> <996653920.2941.0.camel@syntax.dera.gov.uk> <20010801200550.B30796@vestdata.no> Comments: In-reply-to =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= message dated "Wed, 01 Aug 2001 20:05:50 +0200." Date: Wed, 01 Aug 2001 13:30:22 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Aug 01, 2001 at 09:18:40AM +0100, Tony Gale wrote: > > Do you have any other patches in your kernel, such as grsecurity? > > The only patch I have is the xfs patch. > > I thought Trond pointed to a patch on linux-kernel this morning: The NLM lock reclaiming code in the stock 2.4.x kernel is incomplete. Please apply the patch on http://www.fys.uio.no/~trondmy/src/2.4.7/linux-2.4.7-reclaim.dif Cheers, Trond Steve > > -- > Ragnar Kjorstad > Big Storage From owner-linux-xfs@oss.sgi.com Wed Aug 1 17:13:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f720DmG22552 for linux-xfs-outgoing; Wed, 1 Aug 2001 17:13:48 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f720DkV22530 for ; Wed, 1 Aug 2001 17:13:46 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA01800 for ; Wed, 1 Aug 2001 17:13:30 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA74815; Wed, 1 Aug 2001 17:18:20 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id DC75115A47E; Wed, 1 Aug 2001 17:12:20 -0700 (PDT) Subject: [reiserfs-list] A question for a redhat reiserfs user (oh, my sympathies....) From: Florin Andrei To: David Rees Cc: linux-xfs , redhat-devel-list@redhat.com In-Reply-To: <20010730172657.B30532@greenhydrant.com> References: <3B65E677.710A7B34@namesys.com> <20010730172657.B30532@greenhydrant.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 01 Aug 2001 17:12:20 -0700 Message-Id: <996711140.10880.56.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 30 Jul 2001 17:26:57 -0700, David Rees wrote: > On Tue, Jul 31, 2001 at 02:57:59AM +0400, Hans Reiser wrote: > > A user who wants to be anonymous says: > > > > "In RH 7.1's initscripts package, it appears to me that they only remount / > > ro in /etc/rc.d/init.d/halt if / is ext2. I'm not sure if that was just > > on my system though (was having problems with / being another journaling > > filesystem, so *every* time the machine got rebooted, / was being marked > > as unclean and had to go through the full fsck treatment instead of just > > being quickly checked)." > > > > I don't have a RedHat box to check. I would hope that when this happens, it > > runs reiserfsck with the options that cause reiserfsck to take a fraction of a > > second to exit doing nothing, like happens with SuSE. > > The anonymous user is correct. This diff to /etc/init.d/halt should fix > it. > > --- halt.orig Mon Jul 30 17:26:24 2001 > +++ halt Mon Jul 30 17:26:36 2001 > @@ -165,7 +165,7 @@ > > # Remount read only anything that's left mounted. > #echo $"Remounting remaining filesystems (if any) readonly" > -mount | awk '/ext2/ { print $3 }' | while read line; do > +mount | awk '/ext2|reiserfs/ { print $3 }' | while read line; do > mount -n -o ro,remount $line > done I believe it's better like this: +mount | awk '/ext2|reiserfs|xfs/ { print $3 }' | while read line; do ;-) -- Florin Andrei From owner-linux-xfs@oss.sgi.com Wed Aug 1 18:47:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f721l7127137 for linux-xfs-outgoing; Wed, 1 Aug 2001 18:47:07 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f721l5V27115 for ; Wed, 1 Aug 2001 18:47:05 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA08129 for ; Wed, 1 Aug 2001 18:46:47 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA96329 for linux-xfs@oss.sgi.com; Thu, 2 Aug 2001 11:45:40 +1000 (EST) Date: Thu, 2 Aug 2001 11:45:40 +1000 (EST) From: Nathan Scott Message-Id: <200108020145.LAA96329@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - configure scripts Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 31 21:32:23 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:99934a cmd/xfsdump/common/content.c - 1.2 - not used, nuke it. Date: Wed Aug 1 18:44:45 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100036a cmd/xfsdump/configure.in - 1.13 cmd/xfstests/configure.in - 1.10 cmd/dmapi/configure.in - 1.10 - additional diagnostic messages when we can't find headers/libs we need. From owner-linux-xfs@oss.sgi.com Wed Aug 1 21:06:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7246RJ03639 for linux-xfs-outgoing; Wed, 1 Aug 2001 21:06:27 -0700 Received: from mail15b.boca15-verio.com (mail15b.boca15-verio.com [208.55.91.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7246PV03619 for ; Wed, 1 Aug 2001 21:06:25 -0700 Received: from www.sigmastorage.com (128.241.173.170) by mail15b.boca15-verio.com (RS ver 1.0.60s) with SMTP id 018982823; Thu, 2 Aug 2001 00:06:09 -0400 (EDT) Message-ID: <3B68D0F6.6433B6FB@sigmastorage.com> Date: Wed, 01 Aug 2001 21:03:02 -0700 From: Matt Ryan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2-june14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Linux XFS Mailing List Subject: Re: raid5 resync aborted under heavy XFS use References: <200107301351.f6UDp6J04035@jen.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 - > o There was a stall problem where the raid would just grind to a halt, > this was fixed by a kernel change in the 2.4.7-pre series. This was sorry to beat a dead horse, but I have a couple questions related to this and the fact that I might have to go with the redhat-based 2.4.3 1.0.1 release kernel on a couple of machines. - what was the fix to the 'grind to a halt' problem? was it a patch against the md code in particular, or some other part of the kernel? - does anybody know if this same problem existed in the redhat 1.0.1 kernel? I don't know how much rigorous testing that kernel has been subjected to. is there a specific test that triggered this problem in the stock + xfs kernel that I could run on the redhat kernel? - if this problem does turn out to be in the redhat 1.0.1 kernel, and there is a specific, simple patch that fixes it, my next step would be to figure out if it has any chance of working with the 2.4.3 -ac kernel. I wonder what my chances of that would be. thanks, Matt From owner-linux-xfs@oss.sgi.com Thu Aug 2 00:38:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f727cRA13944 for linux-xfs-outgoing; Thu, 2 Aug 2001 00:38:27 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f727cPV13925 for ; Thu, 2 Aug 2001 00:38:25 -0700 Received: from mail.coltex.nl (root@edge.coltex.nl [194.151.97.115]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA29062 for ; Thu, 2 Aug 2001 00:38:11 -0700 (PDT) mail_from (knuffie@xs4all.nl) Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f727JtK01791; Thu, 2 Aug 2001 09:19:56 +0200 Message-Id: <4.3.2.7.2.20010802090925.033e7dd8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Aug 2001 09:19:33 +0200 To: Matt Ryan , Steve Lord From: Seth Mos Subject: Re: raid5 resync aborted under heavy XFS use Cc: Linux XFS Mailing List In-Reply-To: <3B68D0F6.6433B6FB@sigmastorage.com> References: <200107301351.f6UDp6J04035@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:03 1-8-2001 -0700, Matt Ryan wrote: >Precedence: bulk >X-UIDL: 996725357.maildrop8.8834 > >hi - > > > o There was a stall problem where the raid would just grind to a halt, > > this was fixed by a kernel change in the 2.4.7-pre series. This was > >sorry to beat a dead horse, but I have a couple questions related to >this and the fact that I might have to go with the redhat-based 2.4.3 >1.0.1 release kernel on a couple of machines. > >- what was the fix to the 'grind to a halt' problem? was it a patch >against the md code in particular, or some other part of the kernel? You would have to scour the archive for the TAKE messages of the past week. You can then see what files have been touched and fetch diffs from the webcvs frontend. >- does anybody know if this same problem existed in the redhat 1.0.1 RedHat never released a 1.0.1 (was that mothersday?). Do you mean The RedHat 7.1 2.4.3 updated kernel? >kernel? I don't know how much rigorous testing that kernel has been >subjected to. is there a specific test that triggered this problem in >the stock + xfs kernel that I could run on the redhat kernel? This was a specific interaction between xfs and the md raid code IIRC. This would not happen with ext2 but I believe reiserfs was also affected because of the journaling. The 2.4.5 based xfs kernel had the same problem and even the CVS tree untill last week. >- if this problem does turn out to be in the redhat 1.0.1 kernel, and >there is a specific, simple patch that fixes it, my next step would be >to figure out if it has any chance of working with the 2.4.3 -ac >kernel. I wonder what my chances of that would be. They are beating on a 2.4.7 based tree. No exact plans or release dates for 1.0.2 yet. The chances of patching a -ac kernel are slimm ;) -- 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 Aug 2 02:31:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f729VAK17951 for linux-xfs-outgoing; Thu, 2 Aug 2001 02:31:10 -0700 Received: from mx.linux.net.cn ([210.52.24.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f729V8V17920 for ; Thu, 2 Aug 2001 02:31:09 -0700 Received: from dfbbb.cn.mvd (unknown [211.99.247.66]) by mx.linux.net.cn (Postfix) with ESMTP id 5C6A2A37 for ; Thu, 2 Aug 2001 17:27:36 +0800 (CST) Received: (from dfbb@localhost) by dfbbb.cn.mvd (8.11.2/8.11.2) id f729UPL11976 for linux-xfs@oss.sgi.com; Thu, 2 Aug 2001 17:30:25 +0800 Date: Thu, 2 Aug 2001 17:30:24 +0800 From: Fang Han To: Linux XFS Mailing List Subject: [BUG]Can't work with -no-common flag Message-ID: <20010802173023.B1135@dfbbb.cn.mvd> Mail-Followup-To: Linux XFS Mailing List 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 When I add -no-common flag on Makefile, XFS linking will broken. It complain xfsstats redefined. Dan From owner-linux-xfs@oss.sgi.com Thu Aug 2 03:08:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72A8CU23036 for linux-xfs-outgoing; Thu, 2 Aug 2001 03:08:12 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72A88V23004 for ; Thu, 2 Aug 2001 03:08:09 -0700 Received: (qmail 4708 invoked from network); 2 Aug 2001 10:06:20 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Aug 2001 10:06:20 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Fang Han cc: Linux XFS Mailing List Subject: Re: [BUG]Can't work with -no-common flag In-reply-to: Your message of "Thu, 02 Aug 2001 17:30:24 +0800." <20010802173023.B1135@dfbbb.cn.mvd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Aug 2001 20:06:19 +1000 Message-ID: <25188.996746779@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2 Aug 2001 17:30:24 +0800, Fang Han wrote: >When I add -no-common flag on Makefile, XFS linking will broken. >It complain xfsstats redefined. I cannot reproduce this with XFS CVS, using egcs-2.91.66. Which version of gcc are you using (gcc -v) and what are the exact error messages you get? From owner-linux-xfs@oss.sgi.com Thu Aug 2 04:35:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72BZDi04279 for linux-xfs-outgoing; Thu, 2 Aug 2001 04:35:13 -0700 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72BZAV04256 for ; Thu, 2 Aug 2001 04:35:10 -0700 Received: From notabene ([129.94.242.30] == xylophone.orchestra.cse.unsw.EDU.AU) (for ) (for ) (for ) (for ) (for ) By tone With Smtp ; Thu, 2 Aug 2001 21:34:20 +1000 Received: from neilb by notabene with local (Exim 3.22 #1 (Debian)) id 15SGk9-0004Px-00; Thu, 02 Aug 2001 21:34:21 +1000 From: Neil Brown To: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= Date: Thu, 2 Aug 2001 21:34:17 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15209.15033.502548.995201@notabene.cse.unsw.edu.au> Cc: Tad Dolphay , mjacob@feral.com, Christian Chip , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net Subject: Re: Busy inodes after umount In-Reply-To: message from =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= on Tuesday July 31 References: <20010719165758.D50024-100000@wonky.feral.com> <200107200038.TAA40153@fsgi158.americas.sgi.com> <20010731021546.A7750@vestdata.no> X-Mailer: VM 6.72 under Emacs 20.7.2 X-face: [Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D On Thu, Jul 19, 2001 at 07:38:15PM -0500, Tad Dolphay wrote: > > > > I've now been able to reproduce: > > > > > > > > * make a filesystem > > > > * mount it > > > > * export it (nfs) > > > > * mount on remote machine > > > > * lock file (fcntl) > > > > * unexport > > > > * unmount > > > > > > > > Then you get the VFS message about self-destruct. Tested with both ext2 > > > > and xfs. > > > > > > > > The lock is still present in /proc/locks after the umount. > > > > > > > > With ext2 I can remount the filesystem successfully, but with XFS I get > > > > the message about duplicate UUIDs and the mount failes. I believe this is a totally > > > > different problem from the one you were experiencing. (and blockdev doesn't help for me) > > > > > > > > I suppose this is a generic kernel bug? Yep. It is not filesystem specific. nfsd does not flush locks when a filesystem is un-exported, only when a client is removed, and that actually never happens. In fs/nfsd/lockd.c there is a comment: /* * When removing an NFS client entry, notify lockd that it is gone. * FIXME: We should do the same when unexporting an NFS volume. */ That FIXME needs to be fixed. I need to read through some more code before I am sure how to do it, but it shouldn't be too hard. NeilBrown From owner-linux-xfs@oss.sgi.com Thu Aug 2 04:35:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72BZlA04388 for linux-xfs-outgoing; Thu, 2 Aug 2001 04:35:47 -0700 Received: from zok.corp.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72BZjV04368 for ; Thu, 2 Aug 2001 04:35:45 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f72Befm27612 for ; Thu, 2 Aug 2001 04:40:41 -0700 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 GAA2600609; Thu, 2 Aug 2001 06:34:04 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA47031; Thu, 2 Aug 2001 06:34:03 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f72BYba06220; Thu, 2 Aug 2001 06:34:37 -0500 Message-Id: <200108021134.f72BYba06220@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Keith Owens cc: Fang Han , Linux XFS Mailing List Subject: Re: [BUG]Can't work with -no-common flag In-Reply-To: Message from Keith Owens of "Thu, 02 Aug 2001 20:06:19 +1000." <25188.996746779@ocs3.ocs-net> Date: Thu, 02 Aug 2001 06:34:37 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Thu, 2 Aug 2001 17:30:24 +0800, > Fang Han wrote: > >When I add -no-common flag on Makefile, XFS linking will broken. > >It complain xfsstats redefined. > > I cannot reproduce this with XFS CVS, using egcs-2.91.66. Which > version of gcc are you using (gcc -v) and what are the exact error > messages you get? This is fixed in the cvs tree - and possibly in the 2.4.7 patch, there were some changes to make this compile option work. If you are using an earlier code base this compile flag will cause errors. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 2 05:47:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72ClFD15417 for linux-xfs-outgoing; Thu, 2 Aug 2001 05:47:15 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72CkwV15343 for ; Thu, 2 Aug 2001 05:46:59 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id OAA08247 for ; Thu, 2 Aug 2001 14:45:08 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA21764 for linux-xfs@oss.sgi.com; Thu, 2 Aug 2001 14:45:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 5FDB357306 for ; Thu, 2 Aug 2001 14:44:57 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 42BF925835 for ; Thu, 2 Aug 2001 14:44:57 +0200 (CEST) Message-ID: <3B694B49.209B904C@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 14:44:57 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Insecure world writable files from XFS 1.0.1 ISO installer Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When installing from the ISO RH7.1-SGI-XFS-1.0.1, all system config files and directories which are not part of an RPM are installed world writeable (mode 666/777). This was mentioned on this list before but I didn't realize that it happens with the 1.0.1 installer ISO. Is there an easy way to modify the installer to get around this problem or is it better to use the 1.0 ISO and upgrade packages after the install? I'm just worried what to do with all those already installed system because a chmod -R go-w ... is not a good solution. -Simon From owner-linux-xfs@oss.sgi.com Thu Aug 2 06:54:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72DsvD25384 for linux-xfs-outgoing; Thu, 2 Aug 2001 06:54:57 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72DssV25362 for ; Thu, 2 Aug 2001 06:54:54 -0700 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA03389 for ; Thu, 2 Aug 2001 06:52:51 -0700 (PDT) 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 GAA95583; Thu, 2 Aug 2001 06:52:34 -0700 (PDT) Message-ID: <3B695A70.6C2D70FD@sgi.com> Date: Thu, 02 Aug 2001 08:49:36 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer References: <3B694B49.209B904C@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > > When installing from the ISO RH7.1-SGI-XFS-1.0.1, all system config > files and directories which are not part of an RPM are installed world > writeable (mode 666/777). Which files, for example? So this does NOT happen with either stock Red Hat or XFS 1.0? Not sure what might be causing this... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Aug 2 07:18:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72EIQm28243 for linux-xfs-outgoing; Thu, 2 Aug 2001 07:18:26 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72EIMV28223 for ; Thu, 2 Aug 2001 07:18:23 -0700 Received: (qmail 6294 invoked from network); 2 Aug 2001 14:16:28 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Aug 2001 14:16:28 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Eric Sandeen cc: Simon Matter , linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer In-reply-to: Your message of "Thu, 02 Aug 2001 08:49:36 EST." <3B695A70.6C2D70FD@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Aug 2001 00:16:27 +1000 Message-ID: <6321.996761787@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 02 Aug 2001 08:49:36 -0500, Eric Sandeen wrote: >Simon Matter wrote: >> >> When installing from the ISO RH7.1-SGI-XFS-1.0.1, all system config >> files and directories which are not part of an RPM are installed world >> writeable (mode 666/777). > >Which files, for example? So this does NOT happen with either stock Red >Hat or XFS 1.0? Not sure what might be causing this... Almost certainly the kernel bug introduced somewhere around 2.4.3 and fixed in 2.4.7. The default umask for kernel threads, including init was incorrectly set to 000. Stock RedHat init scripts have umask 022 at the start which hides the kernel bug. From owner-linux-xfs@oss.sgi.com Thu Aug 2 07:21:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72ELwf28813 for linux-xfs-outgoing; Thu, 2 Aug 2001 07:21:58 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72ELtV28787 for ; Thu, 2 Aug 2001 07:21:55 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id QAA00166; Thu, 2 Aug 2001 16:19:47 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id QAA29069; Thu, 2 Aug 2001 16:19:46 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id D647757306; Thu, 2 Aug 2001 16:17:47 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id B551725835; Thu, 2 Aug 2001 16:17:47 +0200 (CEST) Message-ID: <3B69610B.41A40F18@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 16:17:47 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer References: <3B694B49.209B904C@ch.sauter-bc.com> <3B695A70.6C2D70FD@sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > Simon Matter wrote: > > > > When installing from the ISO RH7.1-SGI-XFS-1.0.1, all system config > > files and directories which are not part of an RPM are installed world > > writeable (mode 666/777). > > Which files, for example? So this does NOT happen with either stock Red > Hat or XFS 1.0? Not sure what might be causing this... Sorry for not providing more information. It does NOT happen with XFS 1.0 release. I guess it also does not occur with stock RH installer. My dirty find script looks like that: #!/bin/sh find . -type f -o -type d | while read xxx; do rpm -qf $xxx > /dev/null RETVAL=$? if [ $RETVAL -gt 0 ]; then find $xxx -perm -022 -exec ls -lad {} \; fi done when run in /etc it gives something like: [root@ga-www /etc]# /root/checkit.2 drwxrwxrwx 8 root root 4096 Aug 2 15:35 ./sysconfig lrwxrwxrwx 1 root root 20 Jul 31 14:34 ./sysconfig/network-scripts/ifdown -> ../../../sbin/ifdown lrwxrwxrwx 1 root root 18 Jul 31 14:34 ./sysconfig/network-scripts/ifup -> ../../../sbin/ifup -rw-rw-rw- 1 root root 74 Jul 31 14:35 ./sysconfig/i18n -rw-rw-rw- 1 root root 90 Jul 31 14:35 ./sysconfig/mouse -rw-rw-rw- 1 root root 32 Jul 31 14:35 ./sysconfig/keyboard -rw-rw-rw- 1 root root 40 Jul 31 14:35 ./sysconfig/clock -rw-rw-rw- 1 root root 11 Jul 31 14:35 ./sysconfig/desktop -rw-rw-rw- 1 root root 38 Jul 31 14:35 ./sysconfig/pcmcia -rw-rw-rw- 1 root root 2150 Aug 2 16:52 ./sysconfig/hwconf -rw-rw-rw- 1 root root 58 Jul 31 15:07 ./sysconfig/network -rw-rw-rw- 1 root root 74 Jul 31 14:35 ./sysconfig/i18n -rw-rw-rw- 1 root root 90 Jul 31 14:35 ./sysconfig/mouse -rw-rw-rw- 1 root root 32 Jul 31 14:35 ./sysconfig/keyboard -rw-rw-rw- 1 root root 40 Jul 31 14:35 ./sysconfig/clock -rw-rw-rw- 1 root root 11 Jul 31 14:35 ./sysconfig/desktop -rw-rw-rw- 1 root root 38 Jul 31 14:35 ./sysconfig/pcmcia -rw-rw-rw- 1 root root 2150 Aug 2 16:52 ./sysconfig/hwconf -rw-rw-rw- 1 root root 58 Jul 31 15:07 ./sysconfig/network -rw-rw-rw- 1 root root 16342 Jul 31 14:35 ./X11/XF86Config -rw-rw-rw- 1 root root 3698 Jul 31 14:35 ./X11/XF86Config-4 -rw-rw-rw- 1 root root 66 Jul 31 14:33 ./shells -rw-rw-rw- 1 root root 221 Jul 31 14:34 ./sgml/sgml-docbook-3.0.cat -rw-rw-rw- 1 root root 156 Jul 31 14:34 ./sgml/catalog -rw-rw-rw- 1 root root 221 Jul 31 14:34 ./sgml/sgml-docbook-3.1.cat -rw-rw-rw- 1 root root 221 Jul 31 14:34 ./sgml/sgml-docbook-4.0.cat -rw-rw-rw- 1 root root 221 Jul 31 14:34 ./sgml/sgml-docbook-4.1.cat lrwxrwxrwx 1 root root 30 Jul 31 14:34 ./sgml/sgml-docbook.cat -> /etc/sgml/sgml-docbook-4.1.cat-rw-rw-rw- 1 root root 221 Jul 31 14:34 ./sgml/sgml-docbook-3.0.cat -rw-rw-rw- 1 root root 156 Jul 31 14:34 ./sgml/catalog -rw-rw-rw- 1 root root 221 Jul 31 14:34 ./sgml/sgml-docbook-3.1.cat -rw-rw-rw- 1 root root 221 Jul 31 14:34 ./sgml/sgml-docbook-4.0.cat -rw-rw-rw- 1 root root 221 Jul 31 14:34 ./sgml/sgml-docbook-4.1.cat -rw-rw-rw- 1 root root 15 Jul 31 14:35 ./resolv.conf -rw-rw-rw- 1 root root 238 Aug 2 12:07 ./hosts What a nice toy for the kiddies :-) There was an earlier thread on this list and Keith Owens said: > Which kernel? There was a kernel bug from 2.4.3-pre5 until 2.4.7-pre7 > where the initscripts ran with umask 000 instead of 022, that would > give the effect above. It is fixed in the XFS CVS tree because that is > at 2.4.7, but the old releases might be bitten by this kernel bug. Hope this helps. > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Thu Aug 2 07:42:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72EgB631568 for linux-xfs-outgoing; Thu, 2 Aug 2001 07:42:11 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72Eg9V31546 for ; Thu, 2 Aug 2001 07:42:09 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id QAA25797; Thu, 2 Aug 2001 16:40:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id QAA00720; Thu, 2 Aug 2001 16:40:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3961157306; Thu, 2 Aug 2001 16:39:51 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id DF41025835; Thu, 2 Aug 2001 16:39:50 +0200 (CEST) Message-ID: <3B696636.E497C497@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 16:39:50 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Keith Owens Cc: Eric Sandeen , linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer References: <6321.996761787@ocs3.ocs-net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens schrieb: > > On Thu, 02 Aug 2001 08:49:36 -0500, > Eric Sandeen wrote: > >Simon Matter wrote: > >> > >> When installing from the ISO RH7.1-SGI-XFS-1.0.1, all system config > >> files and directories which are not part of an RPM are installed world > >> writeable (mode 666/777). > > > >Which files, for example? So this does NOT happen with either stock Red > >Hat or XFS 1.0? Not sure what might be causing this... > > Almost certainly the kernel bug introduced somewhere around 2.4.3 and > fixed in 2.4.7. The default umask for kernel threads, including init > was incorrectly set to 000. Stock RedHat init scripts have umask 022 > at the start which hides the kernel bug. So this means that intalling with the 1.0 installer and upgrading to 1.0.1 is secure but installing with the 1.0.1 installer will create a system with open doors. -Simon From owner-linux-xfs@oss.sgi.com Thu Aug 2 08:03:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72F3NS01130 for linux-xfs-outgoing; Thu, 2 Aug 2001 08:03:23 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72F3LV01103 for ; Thu, 2 Aug 2001 08:03:21 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA27683 for ; Thu, 2 Aug 2001 08:01:15 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2591845; Thu, 2 Aug 2001 09:59:15 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA62462; Thu, 2 Aug 2001 09:59:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f72ExmB06735; Thu, 2 Aug 2001 09:59:48 -0500 Message-Id: <200108021459.f72ExmB06735@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Simon Matter cc: Keith Owens , Eric Sandeen , linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer In-Reply-To: Message from Simon Matter of "Thu, 02 Aug 2001 16:39:50 +0200." <3B696636.E497C497@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 09:59:48 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Keith Owens schrieb: > > > > On Thu, 02 Aug 2001 08:49:36 -0500, > > Eric Sandeen wrote: > > >Simon Matter wrote: > > >> > > >> When installing from the ISO RH7.1-SGI-XFS-1.0.1, all system config > > >> files and directories which are not part of an RPM are installed world > > >> writeable (mode 666/777). > > > > > >Which files, for example? So this does NOT happen with either stock Red > > >Hat or XFS 1.0? Not sure what might be causing this... > > > > Almost certainly the kernel bug introduced somewhere around 2.4.3 and > > fixed in 2.4.7. The default umask for kernel threads, including init > > was incorrectly set to 000. Stock RedHat init scripts have umask 022 > > at the start which hides the kernel bug. > > So this means that intalling with the 1.0 installer and upgrading to > 1.0.1 is secure but installing with the 1.0.1 installer will create a > system with open doors. The interesting thing is that the initscripts should stay the same, so I would suspect something running in the kernel at install time is at fault. The 1.0.1 install package does not have a redhat equivalent, they did not respin their iso images when they released a 2.4.3 based kernel rpm, the only way for a redhat user to get to this configuration was a 7.1 install followed by a kernel rpm upgrade. It seems like we should have stuck to the same path. Eric, which kernel is running when the installer is doing it's stuff, it is possible there is something about this kernel. In the meantime, I am not sure we should leave the 1.0.1 iso images up on the web site but recommend people use the 1.0 and then do a kernel upgrade. This means the installer fixes get lost, but it may be the most prudent path here. Steve > > -Simon > From owner-linux-xfs@oss.sgi.com Thu Aug 2 08:14:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72FEgm02342 for linux-xfs-outgoing; Thu, 2 Aug 2001 08:14:42 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72FEeV02319 for ; Thu, 2 Aug 2001 08:14:40 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08665 for ; Thu, 2 Aug 2001 08:12:30 -0700 (PDT) mail_from (wim@queron.nl) Received: from qserve-n.queron.nl (queron.xs4all.nl [213.84.91.119]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id RAA22962 for ; Thu, 2 Aug 2001 17:11:41 +0200 (CEST) Received: from wim (dhcp35.queron [192.168.1.35]) by qserve-n.queron.nl (Postfix on SuSE Linux 7.1 (i386)) with SMTP id 782E2281D84 for ; Thu, 2 Aug 2001 17:07:10 +0200 (CEST) Message-ID: <001901c11b64$cd9ecae0$2301a8c0@wim> From: "Wim Verhoogt" To: Subject: Assertion failure in xfsrestore Date: Thu, 2 Aug 2001 17:07:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I'm attemting to make backups using xfsdump/xfsrestore, however xfsrestore terminates with the message: xfsrestore: examining media file 1 xfsrestore: seeking past media file directory dump xfsrestore: drive_scsitape.c:1461: do_next_mark: Assertion `rechdrp->first_mark_offset - rechdrp->file_offset <= off64_t )( contextp->dc_recsz )' failed. Aborted I'm using the xfsrestore from xfsdump-1.0.11-0.rpm, the xfs patches for a vanilla 2.4.6 kernel on SuSE 7.1. The backup used was from a filesystem some 2.3 GB in size, backed up to a DDS-3 tapedrive. I tried to restore a small subset from that backup as a test. I've tested this with older versions as well, and they all had this problem. Anyone has a solution? Greetings, Wim From owner-linux-xfs@oss.sgi.com Thu Aug 2 08:17:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72FHwx02801 for linux-xfs-outgoing; Thu, 2 Aug 2001 08:17:58 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72FHvV02774 for ; Thu, 2 Aug 2001 08:17:57 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA04202 for ; Thu, 2 Aug 2001 08:13:55 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2605973; Thu, 2 Aug 2001 10:14:50 -0500 (CDT) 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 KAA86817; Thu, 2 Aug 2001 10:14:49 -0500 (CDT) Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer From: Eric Sandeen To: Steve Lord Cc: Simon Matter , Keith Owens , linux-xfs In-Reply-To: <200108021459.f72ExmB06735@jen.americas.sgi.com> References: <200108021459.f72ExmB06735@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 02 Aug 2001 10:12:25 -0500 Message-Id: <996765146.16847.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 02 Aug 2001 09:59:48 -0500, Steve Lord wrote: > The 1.0.1 install package does not have a redhat equivalent, they did > not respin their iso images when they released a 2.4.3 based kernel rpm, > the only way for a redhat user to get to this configuration was a 7.1 > install followed by a kernel rpm upgrade. It seems like we should have > stuck to the same path. Ah, hindsight is great, isn't it? :( > Eric, which kernel is running when the installer is doing it's stuff, it > is possible there is something about this kernel. In the meantime, I am > not sure we should leave the 1.0.1 iso images up on the web site but > recommend people use the 1.0 and then do a kernel upgrade. This means > the installer fixes get lost, but it may be the most prudent path > here. The Red Hat 2.4.3 + XFS kernel is running at install time, so I guess that's where this problem comes from. Hm, might be time to come up with a script to fix this up, and a "warning" email to users... Darn. I could do a 1.0.1a kernel with this bug fixed, and respin the installer, too, I suppose. -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 Aug 2 08:28:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72FSac04338 for linux-xfs-outgoing; Thu, 2 Aug 2001 08:28:36 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72FSYV04319 for ; Thu, 2 Aug 2001 08:28:34 -0700 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 IAA01924 for ; Thu, 2 Aug 2001 08:26:38 -0700 (PDT) mail_from (nstraz@sgi.com) 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 KAA31981 for ; Thu, 2 Aug 2001 10:14:30 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.31 #1 (Debian)) id 15SKBB-0001fV-00 for ; Thu, 02 Aug 2001 10:14:29 -0500 Date: Thu, 2 Aug 2001 10:14:29 -0500 From: Nathan Straz To: linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer Message-ID: <20010802101429.A1694@sgi.com> Mail-Followup-To: linux-xfs References: <6321.996761787@ocs3.ocs-net> <3B696636.E497C497@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B696636.E497C497@ch.sauter-bc.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 02, 2001 at 04:39:50PM +0200, Simon Matter wrote: > So this means that intalling with the 1.0 installer and upgrading to > 1.0.1 is secure but installing with the 1.0.1 installer will create a > system with open doors. You list of files indicates that the house is probably still locked, but once you're in the house, some of the rooms that should be locked, aren't. That doesn't make it any less of an unpleasant surprise. -- 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 Thu Aug 2 08:34:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72FY8605329 for linux-xfs-outgoing; Thu, 2 Aug 2001 08:34:08 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72FY5V05303 for ; Thu, 2 Aug 2001 08:34:05 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id RAA04015; Thu, 2 Aug 2001 17:32:06 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id RAA04515; Thu, 2 Aug 2001 17:32:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id E077F57306; Thu, 2 Aug 2001 17:31:10 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id CBF5325835; Thu, 2 Aug 2001 17:31:10 +0200 (CEST) Message-ID: <3B69723E.624D31E@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 17:31:10 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: Steve Lord , Keith Owens , linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer References: <200108021459.f72ExmB06735@jen.americas.sgi.com> <996765146.16847.3.camel@stout.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > On 02 Aug 2001 09:59:48 -0500, Steve Lord wrote: > > > The 1.0.1 install package does not have a redhat equivalent, they did > > not respin their iso images when they released a 2.4.3 based kernel rpm, > > the only way for a redhat user to get to this configuration was a 7.1 > > install followed by a kernel rpm upgrade. It seems like we should have > > stuck to the same path. > > Ah, hindsight is great, isn't it? :( > > > Eric, which kernel is running when the installer is doing it's stuff, it > > is possible there is something about this kernel. In the meantime, I am > > not sure we should leave the 1.0.1 iso images up on the web site but > > recommend people use the 1.0 and then do a kernel upgrade. This means > > the installer fixes get lost, but it may be the most prudent path > > here. > > The Red Hat 2.4.3 + XFS kernel is running at install time, so I guess > that's where this problem comes from. Hm, might be time to come up with /etc/rc.d/init.d/functions keeps umask sane at 022 but when booting with linux init=/bin/sh the umask is 000. I'm not an expert but I guess this is the dangerous 'feature' :( > a script to fix this up, and a "warning" email to users... Darn. > > I could do a 1.0.1a kernel with this bug fixed, and respin the > installer, too, I suppose. If you're doing so, could you please include my modified RPM's: My previous mail: http://oss.sgi.com/projects/xfs/mail_archive/0107/msg01211.html RPM's: http://home.datacomm.ch/~simix/XFS/ > > -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 Aug 2 08:45:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72FjnR07311 for linux-xfs-outgoing; Thu, 2 Aug 2001 08:45:49 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72FjlV07281 for ; Thu, 2 Aug 2001 08:45:47 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.31 #1) id 15SKdm-0008Ik-00; Thu, 02 Aug 2001 17:44:02 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.0/8.9.3) id f72Fg2x19626; Thu, 2 Aug 2001 11:42:02 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: Eric Sandeen Cc: Steve Lord , Simon Matter , Keith Owens , linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer References: <200108021459.f72ExmB06735@jen.americas.sgi.com> <996765146.16847.3.camel@stout.americas.sgi.com> From: "Martin K. Petersen" Organization: mkp.net Date: 02 Aug 2001 11:42:02 -0400 In-Reply-To: <996765146.16847.3.camel@stout.americas.sgi.com> Message-ID: Lines: 20 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 >>>>> "Eric" == Eric Sandeen writes: >> Eric, which kernel is running when the installer is doing it's >> stuff, it is possible there is something about this kernel. In the >> meantime, I am not sure we should leave the 1.0.1 iso images up on >> the web site but recommend people use the 1.0 and then do a kernel >> upgrade. This means the installer fixes get lost, but it may be the >> most prudent path here. Eric> The Red Hat 2.4.3 + XFS kernel is running at install time, so I Eric> guess that's where this problem comes from. The Alpha installer uses the RedHat Alpha 2.4.3 RPM + XFS patches but doesn't suffer from the problem. Do you have the anaconda-7.1-umask patch in the IA32 installer? -- Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME From owner-linux-xfs@oss.sgi.com Thu Aug 2 09:06:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72G6nw10093 for linux-xfs-outgoing; Thu, 2 Aug 2001 09:06:49 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72G6mV10071 for ; Thu, 2 Aug 2001 09:06:48 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA04456 for ; Thu, 2 Aug 2001 09:04:44 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2605045; Thu, 2 Aug 2001 11:03:40 -0500 (CDT) 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 LAA79552; Thu, 2 Aug 2001 11:03:40 -0500 (CDT) Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer From: Eric Sandeen To: "Martin K. Petersen" Cc: Steve Lord , Simon Matter , Keith Owens , linux-xfs In-Reply-To: References: <200108021459.f72ExmB06735@jen.americas.sgi.com> <996765146.16847.3.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 02 Aug 2001 11:01:15 -0500 Message-Id: <996768076.16844.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 02 Aug 2001 11:42:02 -0400, Martin K. Petersen wrote: > The Alpha installer uses the RedHat Alpha 2.4.3 RPM + XFS patches but > doesn't suffer from the problem. > > Do you have the anaconda-7.1-umask patch in the IA32 installer? Hm, where might one find this patch? Also, FWIW, this isn't an xfs-specific problem, I just did an ext2 install with the 1.0.1 CD, and it's still there. So I guess it is the kernel bug previously mentioned... -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 Aug 2 09:11:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72GBja10266 for linux-xfs-outgoing; Thu, 2 Aug 2001 09:11:45 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72GBgV10244 for ; Thu, 2 Aug 2001 09:11:43 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.31 #1) id 15SL2k-0008L1-00; Thu, 02 Aug 2001 18:09:50 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.0/8.9.3) id f72G8Ox19637; Thu, 2 Aug 2001 12:08:24 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: Eric Sandeen Cc: Steve Lord , Simon Matter , Keith Owens , linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer References: <200108021459.f72ExmB06735@jen.americas.sgi.com> <996765146.16847.3.camel@stout.americas.sgi.com> <996768076.16844.10.camel@stout.americas.sgi.com> From: "Martin K. Petersen" Organization: mkp.net Date: 02 Aug 2001 12:08:24 -0400 In-Reply-To: <996768076.16844.10.camel@stout.americas.sgi.com> Message-ID: Lines: 18 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 >>>>> "Eric" == Eric Sandeen writes: Eric> On 02 Aug 2001 11:42:02 -0400, Martin K. Petersen wrote: >> The Alpha installer uses the RedHat Alpha 2.4.3 RPM + XFS patches >> but doesn't suffer from the problem. >> >> Do you have the anaconda-7.1-umask patch in the IA32 installer? Eric> Hm, where might one find this patch? In your mail. In general the bits in the Alpha packages are slightly more recent than in the IA32 versions. -- Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME From owner-linux-xfs@oss.sgi.com Thu Aug 2 09:30:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72GUtE10655 for linux-xfs-outgoing; Thu, 2 Aug 2001 09:30:55 -0700 Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72GUqV10636 for ; Thu, 2 Aug 2001 09:30:53 -0700 Received: from [192.168.1.17] (router.vexcel.com [192.92.90.254]) by biobio.vexcel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA13290 for ; Thu, 2 Aug 2001 10:29:23 -0600 (MDT) Mime-Version: 1.0 X-Sender: brissing@mail.vexcel.com (Unverified) Message-Id: In-Reply-To: <3B69610B.41A40F18@ch.sauter-bc.com> References: <3B694B49.209B904C@ch.sauter-bc.com> <3B695A70.6C2D70FD@sgi.com> <3B69610B.41A40F18@ch.sauter-bc.com> Date: Thu, 2 Aug 2001 10:29:20 -0600 To: linux-xfs From: Dean Brissinger Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 4:17 PM +0200 8/2/01, Simon Matter wrote: >Eric Sandeen schrieb: >> >> Simon Matter wrote: >> > >> > When installing from the ISO RH7.1-SGI-XFS-1.0.1, all system config >> > files and directories which are not part of an RPM are installed world >> > writeable (mode 666/777). >> >> Which files, for example? So this does NOT happen with either stock Red >> Hat or XFS 1.0? Not sure what might be causing this... > >Sorry for not providing more information. > >It does NOT happen with XFS 1.0 release. I guess it also does not occur >with stock RH installer. >My dirty find script looks like that: > >#!/bin/sh >find . -type f -o -type d | while read xxx; do > rpm -qf $xxx > /dev/null > RETVAL=$? > if [ $RETVAL -gt 0 ]; then > find $xxx -perm -022 -exec ls -lad {} \; > fi >done I haven't looked to see if this applies to directories other than /etc yet. But here's a brute force way of patching the problem on 1.0.1 systems based on an expanded version of the above script. Uncomment the chmod commands if you want to actually change the modes otherwise it just tells you what it would be doing to your system. Use at your own risk and I suggest testing it w/ the comments in there before you let it loose. =) #!/bin/sh find . -type f -o -type d | while read xxx; do rpm -qf $xxx > /dev/null RETVAL=$? if [ $RETVAL -gt 0 ]; then files=`find $xxx -perm -022 -a ! -type l` for file in $files; do if [ -n "$file" ]; then ls -ld $file if [ -e $file -a ! -d $file ]; then echo "Changing mode: chmod 644 $file"; #chmod 644 $file else echo "Changing mode: chmod 755 $file"; #chmod 755 $file fi fi done fi done -- . . . . . . . . ooo . . . . ooo . . . . . . . . . . . . Dean Brissinger - Systems Administrator . . Direct: 303-583-0278 Main: 303-444-0094 . . Fax: 303-583-0246 http://www.vexcel.com/ . . . . . . . . . . oOOo . . A . . oOOo . . . . . . . . 0 0 '```` From owner-linux-xfs@oss.sgi.com Thu Aug 2 09:34:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72GYMp10791 for linux-xfs-outgoing; Thu, 2 Aug 2001 09:34:22 -0700 Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72GYKV10772 for ; Thu, 2 Aug 2001 09:34:20 -0700 Received: from [192.168.1.17] (router.vexcel.com [192.92.90.254]) by biobio.vexcel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA13453 for ; Thu, 2 Aug 2001 10:32:25 -0600 (MDT) Mime-Version: 1.0 X-Sender: brissing@mail.vexcel.com (Unverified) Message-Id: In-Reply-To: <3B69723E.624D31E@ch.sauter-bc.com> References: <200108021459.f72ExmB06735@jen.americas.sgi.com> <996765146.16847.3.camel@stout.americas.sgi.com> <3B69723E.624D31E@ch.sauter-bc.com> Date: Thu, 2 Aug 2001 10:32:20 -0600 To: linux-xfs From: Dean Brissinger Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 5:31 PM +0200 8/2/01, Simon Matter wrote: >Eric Sandeen schrieb: >> > > I could do a 1.0.1a kernel with this bug fixed, and respin the >> installer, too, I suppose. > >If you're doing so, could you please include my modified RPM's: > >My previous mail: >http://oss.sgi.com/projects/xfs/mail_archive/0107/msg01211.html > >RPM's: >http://home.datacomm.ch/~simix/XFS/ Do these RPM's include the fix for xfsrestore and device file major numbers? -- . . . . . . . . ooo . . . . ooo . . . . . . . . . . . . Dean Brissinger - Systems Administrator . . Direct: 303-583-0278 Main: 303-444-0094 . . Fax: 303-583-0246 http://www.vexcel.com/ . . . . . . . . . . oOOo . . A . . oOOo . . . . . . . . 0 0 '```` From owner-linux-xfs@oss.sgi.com Thu Aug 2 10:13:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HD6h11587 for linux-xfs-outgoing; Thu, 2 Aug 2001 10:13:06 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72HD3V11564 for ; Thu, 2 Aug 2001 10:13:03 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id TAA21475; Thu, 2 Aug 2001 19:11:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id TAA11193; Thu, 2 Aug 2001 19:11:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id AA77657306; Thu, 2 Aug 2001 19:10:20 +0200 (CEST) Received: from ch.sauter-bc.com (ppp01.cad.sba [10.1.249.1]) by mobile.sauter-bc.com (Postfix) with ESMTP id 9C7BD25835; Thu, 2 Aug 2001 19:10:18 +0200 (CEST) Message-ID: <3B69899A.C4E7B099@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 19:10:50 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dean Brissinger Cc: linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer References: <3B694B49.209B904C@ch.sauter-bc.com> <3B695A70.6C2D70FD@sgi.com> <3B69610B.41A40F18@ch.sauter-bc.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f72HD4V11568 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean Brissinger schrieb: > At 4:17 PM +0200 8/2/01, Simon Matter wrote: > >Eric Sandeen schrieb: > >> > >> Simon Matter wrote: > >> > > >> > When installing from the ISO RH7.1-SGI-XFS-1.0.1, all system config > >> > files and directories which are not part of an RPM are installed world > >> > writeable (mode 666/777). > >> > >> Which files, for example? So this does NOT happen with either stock Red > >> Hat or XFS 1.0? Not sure what might be causing this... > > > >Sorry for not providing more information. > > > >It does NOT happen with XFS 1.0 release. I guess it also does not occur > >with stock RH installer. > >My dirty find script looks like that: > > > >#!/bin/sh > >find . -type f -o -type d | while read xxx; do > > rpm -qf $xxx > /dev/null > > RETVAL=$? > > if [ $RETVAL -gt 0 ]; then > > find $xxx -perm -022 -exec ls -lad {} \; > > fi > >done > > I haven't looked to see if this applies to directories other than > /etc yet. But here's a brute force way of patching the problem on Unfortunately the problem applies to all directories, but for example in /usr there are just a few files with wrong permissions because usually the problem applies to config files created at boot time. I tried to figure out which device files do not belong to an RPM and could also have wrong permissions. I guess this could be a difficult task because mode 644 is not always the solution there. > > 1.0.1 systems based on an expanded version of the above script. > Uncomment the chmod commands if you want to actually change the modes > otherwise it just tells you what it would be doing to your system. > Use at your own risk and I suggest testing it w/ the comments in > there before you let it loose. =) > > #!/bin/sh > find . -type f -o -type d | while read xxx; do > rpm -qf $xxx > /dev/null > RETVAL=$? > if [ $RETVAL -gt 0 ]; then > files=`find $xxx -perm -022 -a ! -type l` > for file in $files; do > if [ -n "$file" ]; then > ls -ld $file > if [ -e $file -a ! -d $file ]; then > echo "Changing mode: chmod 644 $file"; #chmod 644 $file > else > echo "Changing mode: chmod 755 $file"; #chmod 755 $file > fi > fi > done > fi > done > > -- > . . . . . . . . ooo . . . . ooo . . . . . . . . . > . . > . Dean Brissinger - Systems Administrator . > . Direct: 303-583-0278 Main: 303-444-0094 . > . Fax: 303-583-0246 http://www.vexcel.com/ . > . . > . . . . . . . oOOo . . A . . oOOo . . . . . . . . > 0 0 > '```` From owner-linux-xfs@oss.sgi.com Thu Aug 2 10:12:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HC7711492 for linux-xfs-outgoing; Thu, 2 Aug 2001 10:12:07 -0700 Received: from imapserver2.fnal.gov (imapserver2.fnal.gov [131.225.9.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72HC5V11473 for ; Thu, 2 Aug 2001 10:12:05 -0700 Received: from imapserver2.fnal.gov ([131.225.9.7]) by imapserver2.fnal.gov (Netscape Messaging Server 3.62) with SMTP id 1176 for ; Thu, 2 Aug 2001 12:10:25 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserver2.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001080212102403908 for ; Thu, 02 Aug 2001 12:10:24 -0500 Message-ID: <3B698A1F.D4FD4736@fnal.gov> Date: Thu, 02 Aug 2001 12:13:03 -0500 From: yocum@fnal.gov 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: Re: XFS fs size limit? References: <3B682BBE.3A29386D@fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk yocum@fnal.gov wrote: > > Hi all, > > I asked this of mkp but he doesn't know off the top of his head: is there a > limit to the XFS fs size? I've tried creating one on just over 1.1TB with > no success: > FWIW, I'm using 2.4.5 kernel with R1.0.1. Seth suggested that I get the TOT cmds and try mkfs.xfs with that. I did, it worked. Hopefully, I won't run into the problem Jani had a couple weeks ago with FS freezes. I'll let you know if I do. Now there's rumors on l-k that the FS size might be limited by the signedness of something in the block layer, effectively limiting us to 1TB. Oh, joy. 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 Aug 2 10:14:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HExr11798 for linux-xfs-outgoing; Thu, 2 Aug 2001 10:14:59 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72HEuV11779 for ; Thu, 2 Aug 2001 10:14:56 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id TAA21637; Thu, 2 Aug 2001 19:13:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id TAA11293; Thu, 2 Aug 2001 19:13:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 2145357306; Thu, 2 Aug 2001 19:12:54 +0200 (CEST) Received: from ch.sauter-bc.com (ppp01.cad.sba [10.1.249.1]) by mobile.sauter-bc.com (Postfix) with ESMTP id EECF325835; Thu, 2 Aug 2001 19:12:52 +0200 (CEST) Message-ID: <3B698A35.18A9E962@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 19:13:25 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dean Brissinger Cc: linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer References: <200108021459.f72ExmB06735@jen.americas.sgi.com> <996765146.16847.3.camel@stout.americas.sgi.com> <3B69723E.624D31E@ch.sauter-bc.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f72HEvV11780 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean Brissinger schrieb: > At 5:31 PM +0200 8/2/01, Simon Matter wrote: > >Eric Sandeen schrieb: > >> > > > I could do a 1.0.1a kernel with this bug fixed, and respin the > >> installer, too, I suppose. > > > >If you're doing so, could you please include my modified RPM's: > > > >My previous mail: > >http://oss.sgi.com/projects/xfs/mail_archive/0107/msg01211.html > > > >RPM's: > >http://home.datacomm.ch/~simix/XFS/ > > Do these RPM's include the fix for xfsrestore and device file > major numbers? No, they don't. They just fix the problem that you can not create bootdisks with mkbootdisk and a problem where SoftRAID does not start up correctly with devfs enabled. > > -- > . . . . . . . . ooo . . . . ooo . . . . . . . . . > . . > . Dean Brissinger - Systems Administrator . > . Direct: 303-583-0278 Main: 303-444-0094 . > . Fax: 303-583-0246 http://www.vexcel.com/ . > . . > . . . . . . . oOOo . . A . . oOOo . . . . . . . . > 0 0 > '```` From owner-linux-xfs@oss.sgi.com Thu Aug 2 10:17:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HH8S11973 for linux-xfs-outgoing; Thu, 2 Aug 2001 10:17:08 -0700 Received: from nss4.cc.lehigh.edu (root@nss4.CC.Lehigh.EDU [128.180.39.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72HH6V11951 for ; Thu, 2 Aug 2001 10:17:06 -0700 Received: from lehigh.edu (sgr0-450.CC.Lehigh.EDU [128.180.3.16]) by nss4.cc.lehigh.edu (8.11.2/8.11.1) with ESMTP id f72HGWI08722 for ; Thu, 2 Aug 2001 13:16:32 -0400 Message-ID: <3B698AEA.5A40D3D6@lehigh.edu> Date: Thu, 02 Aug 2001 13:16:26 -0400 From: Steve Roseman X-Mailer: Mozilla 4.77 [en]C-CCK-MCD {C-UDP; LEHIGHUNIV} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfsrestore assertion failure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > # xfsrestore -t -f /dev/st0 >.... > xfsrestore: examining media file 1 > xfsrestore: seeking past media file directory dump > xfsrestore: drive_scsitape.c:1461: do_next_mark: Assertion > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t ) > ( contextp->dc_recsz )' failed. > Aborted (core dumped) The following fix seems to resolve the problem. xfsrestore -t works, at least. (I'll try a real restore later.) I suspect the problem is in endian-converting first_mark_offset, maybe when it contains the value -1. Possibly this fix will make the dumps compatible with IRIX, but I suspect few will mind. Steve 523c523 < IXLATE(rh1, rh2, first_mark_offset); --- > /* IXLATE(rh1, rh2, first_mark_offset); */ 532a533 > BXLATE(first_mark_offset); ---------------------------------------------------------------------------- Steve Roseman Lehigh University Information Resources sgr0@Lehigh.EDU From owner-linux-xfs@oss.sgi.com Thu Aug 2 10:32:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HWem12383 for linux-xfs-outgoing; Thu, 2 Aug 2001 10:32:40 -0700 Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72HWcV12364 for ; Thu, 2 Aug 2001 10:32:38 -0700 Received: from [192.168.1.17] (router.vexcel.com [192.92.90.254]) by biobio.vexcel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA14926; Thu, 2 Aug 2001 11:30:49 -0600 (MDT) Mime-Version: 1.0 X-Sender: brissing@mail.vexcel.com (Unverified) Message-Id: In-Reply-To: <3B69899A.C4E7B099@ch.sauter-bc.com> References: <3B694B49.209B904C@ch.sauter-bc.com> <3B695A70.6C2D70FD@sgi.com> <3B69610B.41A40F18@ch.sauter-bc.com> <3B69899A.C4E7B099@ch.sauter-bc.com> Date: Thu, 2 Aug 2001 11:29:45 -0600 To: Simon Matter From: Dean Brissinger Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer Cc: linux-xfs Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 7:10 PM +0200 8/2/01, Simon Matter wrote: >Unfortunately the problem applies to all directories, but for example in /usr >there are just a few files with wrong permissions because usually the problem >applies to config files created at boot time. I tried to figure out which >device files do not belong to an RPM and could also have wrong permissions. I >guess this could be a difficult task because mode 644 is not always the >solution there. I recall there being some tools out there to backup/restore UNIX permissions. If someone could backup the permissions on a default Linux install and share the tool/data on the list we could apply it to 1.0.1 systems. The only tool I came up with was 'licen' (check sourceforge.net). I thought there was a perl script someone published once to do this too but didn't find it. -- . . . . . . . . ooo . . . . ooo . . . . . . . . . . . . Dean Brissinger - Systems Administrator . . Direct: 303-583-0278 Main: 303-444-0094 . . Fax: 303-583-0246 http://www.vexcel.com/ . . . . . . . . . . oOOo . . A . . oOOo . . . . . . . . 0 0 '```` From owner-linux-xfs@oss.sgi.com Thu Aug 2 10:33:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HXPj12441 for linux-xfs-outgoing; Thu, 2 Aug 2001 10:33:25 -0700 Received: from zok.corp.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72HXNV12422 for ; Thu, 2 Aug 2001 10:33:23 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f72Hahm10657 for ; Thu, 2 Aug 2001 10:36:43 -0700 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 MAA2608458; Thu, 2 Aug 2001 12:30:14 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA39285; Thu, 2 Aug 2001 12:30:14 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f72HUkb07093; Thu, 2 Aug 2001 12:30:46 -0500 Message-Id: <200108021730.f72HUkb07093@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Simon Matter cc: Dean Brissinger , linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer In-Reply-To: Message from Simon Matter of "Thu, 02 Aug 2001 19:10:50 +0200." <3B69899A.C4E7B099@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 12:30:46 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Unfortunately the problem applies to all directories, but for example in /usr > there are just a few files with wrong permissions because usually the problem > applies to config files created at boot time. I tried to figure out which > device files do not belong to an RPM and could also have wrong permissions. I > guess this could be a difficult task because mode 644 is not always the > solution there. > We are working on a list of the effected files, and extracting the correct permissions, the end result will hopefully be a fixup script. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 2 10:36:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HavL12655 for linux-xfs-outgoing; Thu, 2 Aug 2001 10:36:57 -0700 Received: from zok.corp.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72HatV12636 for ; Thu, 2 Aug 2001 10:36:55 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f72HeAm10905 for ; Thu, 2 Aug 2001 10:40:10 -0700 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 MAA2606327; Thu, 2 Aug 2001 12:33:40 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA71096; Thu, 2 Aug 2001 12:33:40 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f72HYDo07108; Thu, 2 Aug 2001 12:34:13 -0500 Message-Id: <200108021734.f72HYDo07108@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: yocum@fnal.gov cc: xfs-list Subject: Re: XFS fs size limit? In-Reply-To: Message from yocum@fnal.gov of "Thu, 02 Aug 2001 12:13:03 CDT." <3B698A1F.D4FD4736@fnal.gov> Date: Thu, 02 Aug 2001 12:34:12 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > yocum@fnal.gov wrote: > > > > Hi all, > > > > I asked this of mkp but he doesn't know off the top of his head: is there a > > limit to the XFS fs size? I've tried creating one on just over 1.1TB with > > no success: > > > > > FWIW, I'm using 2.4.5 kernel with R1.0.1. > > > Seth suggested that I get the TOT cmds and try mkfs.xfs with that. I did, > it worked. Hopefully, I won't run into the problem Jani had a couple weeks > ago with FS freezes. I'll let you know if I do. The freeze was a raid5 specific thing, and the only way out of it at this kernel revision is to use an external log device with raid5. You must also make sure to use an inode size larger than the default with a filesystem this big (mkfs ... -i size=512 ...). Without getting to technical, this will stop your inode numbers from overflowing 32 bits. > > Now there's rumors on l-k that the FS size might be limited by the > signedness of something in the block layer, effectively limiting us to 1TB. We appear to have people working successfully beyond the 1Tbyte boundary, the 1Tb limit may be specific to some device drivers which are not as cleanly coded. Steve > Oh, joy. > > 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 Aug 2 10:40:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72He6q12862 for linux-xfs-outgoing; Thu, 2 Aug 2001 10:40:06 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72He4V12843 for ; Thu, 2 Aug 2001 10:40:04 -0700 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 KAA00022 for ; Thu, 2 Aug 2001 10:37:55 -0700 (PDT) mail_from (nstraz@sgi.com) 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 MAA37047 for ; Thu, 2 Aug 2001 12:36:56 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.31 #1 (Debian)) id 15SMP1-0002ak-00 for ; Thu, 02 Aug 2001 12:36:55 -0500 Date: Thu, 2 Aug 2001 12:36:55 -0500 From: Nathan Straz To: linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer Message-ID: <20010802123654.D1694@sgi.com> Mail-Followup-To: linux-xfs References: <3B694B49.209B904C@ch.sauter-bc.com> <3B695A70.6C2D70FD@sgi.com> <3B69610B.41A40F18@ch.sauter-bc.com> <3B69899A.C4E7B099@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B69899A.C4E7B099@ch.sauter-bc.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 02, 2001 at 07:10:50PM +0200, Simon Matter wrote: > Unfortunately the problem applies to all directories, but for example in /usr > there are just a few files with wrong permissions because usually the problem > applies to config files created at boot time. I tried to figure out which > device files do not belong to an RPM and could also have wrong permissions. I > guess this could be a difficult task because mode 644 is not always the > solution there. Does an `rpm --setperms -a` fix most of the wrong permissions? -- 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 Thu Aug 2 10:46:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HkCu13214 for linux-xfs-outgoing; Thu, 2 Aug 2001 10:46:12 -0700 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 f72HkAV13195 for ; Thu, 2 Aug 2001 10:46:10 -0700 Received: from www.sigmastorage.com (128.241.173.170) by mail15a.boca15-verio.com (RS ver 1.0.60s) with SMTP id 0258382; Thu, 2 Aug 2001 13:43:55 -0400 (EDT) Message-ID: <3B699088.1E6C564A@sigmastorage.com> Date: Thu, 02 Aug 2001 10:40:24 -0700 From: Matt Ryan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2-june14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Linux XFS Mailing List Subject: Re: raid5 resync aborted under heavy XFS use References: <200107301351.f6UDp6J04035@jen.americas.sgi.com> <4.3.2.7.2.20010802090925.033e7dd8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > > o There was a stall problem where the raid would just grind to a halt, > > > this was fixed by a kernel change in the 2.4.7-pre series. This was > > > >- what was the fix to the 'grind to a halt' problem? was it a patch > >against the md code in particular, or some other part of the kernel? > > You would have to scour the archive for the TAKE messages of the past week. > You can then see what files have been touched and fetch diffs from the > webcvs frontend. sort of... as Steve said it was fixed by a 'kernel change', all this would amount to on the XFS list is a TAKE to sync with the latest 2.4.7-pre. I just found this in the 2.4.7 changelog: -pre5: ... - Neil Brown: raid5 stall fix, nfsd filehandle sanity check fix that looks promising... I'll see what I can do with it. > >- does anybody know if this same problem existed in the redhat 1.0.1 > > RedHat never released a 1.0.1 (was that mothersday?). heh. just trying to use shorthand. I did earlier refer to it as the 'redhat-based 2.4.3 1.0.1 release kernel.' > They are beating on a 2.4.7 based tree. No exact plans or release dates for > 1.0.2 yet. > The chances of patching a -ac kernel are slimm ;) that I'm well aware of - I've seen the requests for an -ac merge come in about once a month, and I understand how much extra work that would be. which is why I was hoping to extract that one fix. Since it looks like the patch might be isolated to the md code, I think I have a good chance of being able to apply it to the redhat-based kernel. thanks, Matt From owner-linux-xfs@oss.sgi.com Thu Aug 2 11:03:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72I39T13620 for linux-xfs-outgoing; Thu, 2 Aug 2001 11:03:09 -0700 Received: from imapserver2.fnal.gov (imapserver2.fnal.gov [131.225.9.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72I37V13600 for ; Thu, 2 Aug 2001 11:03:07 -0700 Received: from imapserver2.fnal.gov ([131.225.9.7]) by imapserver2.fnal.gov (Netscape Messaging Server 3.62) with SMTP id 1555 for ; Thu, 2 Aug 2001 13:03:03 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserver2.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001080213030308257 for ; Thu, 02 Aug 2001 13:03:03 -0500 Message-ID: <3B699676.DD3D2BE3@fnal.gov> Date: Thu, 02 Aug 2001 13:05:42 -0500 From: yocum@fnal.gov 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: XFS fs size limit? References: <200108021734.f72HYDo07108@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, Steve Lord wrote: > > > yocum@fnal.gov wrote: > > > > > > Hi all, > > > > > > I asked this of mkp but he doesn't know off the top of his head: is there a > > > limit to the XFS fs size? I've tried creating one on just over 1.1TB with > > > no success: > > > > > > > > > FWIW, I'm using 2.4.5 kernel with R1.0.1. > > > > > > Seth suggested that I get the TOT cmds and try mkfs.xfs with that. I did, > > it worked. Hopefully, I won't run into the problem Jani had a couple weeks > > ago with FS freezes. I'll let you know if I do. > > The freeze was a raid5 specific thing, and the only way out of it at I assume you mean software RAID5, right? I've got a RAID50 array: 2 8-port 3ware cards in hw raid5, then those two devices combined software raid0. I didn't bother to make the log on a separate device, but I could, if need be. > this kernel revision is to use an external log device with raid5. You > must also make sure to use an inode size larger than the default with > a filesystem this big (mkfs ... -i size=512 ...). Without getting to > technical, this will stop your inode numbers from overflowing 32 bits. > > > > > Now there's rumors on l-k that the FS size might be limited by the > > signedness of something in the block layer, effectively limiting us to 1TB. > > We appear to have people working successfully beyond the 1Tbyte boundary, > the 1Tb limit may be specific to some device drivers which are not as > cleanly coded. I haven't been terribly happy with the 3ware drivers/cards in general, so we'll see. FWIW, I tried upgrading to their latest driver on an smp system and simply insmod-ing the newly compiled driver tickles the NMI watchdog which dumps me directly into kdb. Fun stuff. :-/ 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 Aug 2 11:04:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72I4O913718 for linux-xfs-outgoing; Thu, 2 Aug 2001 11:04:24 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72I4NV13699 for ; Thu, 2 Aug 2001 11:04:23 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA18781 for ; Thu, 2 Aug 2001 11:02:25 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2606433 for ; Thu, 2 Aug 2001 13:01:22 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA06923; Thu, 2 Aug 2001 13:01:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f72I1li07302; Thu, 2 Aug 2001 13:01:47 -0500 Message-Id: <200108021801.f72I1li07302@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Nathan Straz cc: linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer In-Reply-To: Message from Nathan Straz of "Thu, 02 Aug 2001 12:36:55 CDT." <20010802123654.D1694@sgi.com> Date: Thu, 02 Aug 2001 13:01:47 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Thu, Aug 02, 2001 at 07:10:50PM +0200, Simon Matter wrote: > > Unfortunately the problem applies to all directories, but for example in /u > sr > > there are just a few files with wrong permissions because usually the probl > em > > applies to config files created at boot time. I tried to figure out which > > device files do not belong to an RPM and could also have wrong permissions. > I > > guess this could be a difficult task because mode 644 is not always the > > solution there. > > Does an `rpm --setperms -a` fix most of the wrong permissions? Hmm, probably not, since the files being discussed are not directly installed from rpms, but are created by the install process. Steve > -- > 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 Thu Aug 2 11:26:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72IQSf16943 for linux-xfs-outgoing; Thu, 2 Aug 2001 11:26:28 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72IQOV16920 for ; Thu, 2 Aug 2001 11:26:24 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA542478 for ; Thu, 2 Aug 2001 20:25:58 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2544522; Thu, 2 Aug 2001 13:24:57 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA06116; Thu, 2 Aug 2001 13:24:56 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f72IPTi07424; Thu, 2 Aug 2001 13:25:29 -0500 Message-Id: <200108021825.f72IPTi07424@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: yocum@fnal.gov cc: xfs-list Subject: Re: XFS fs size limit? In-Reply-To: Message from yocum@fnal.gov of "Thu, 02 Aug 2001 13:05:42 CDT." <3B699676.DD3D2BE3@fnal.gov> Date: Thu, 02 Aug 2001 13:25:28 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Steve, > > Steve Lord wrote: > > > > The freeze was a raid5 specific thing, and the only way out of it at > > > I assume you mean software RAID5, right? I've got a RAID50 array: 2 8-port > 3ware cards in hw raid5, then those two devices combined software raid0. I > didn't bother to make the log on a separate device, but I could, if need be. Yes, software raid5, this should not be an issue for hardware raid - unless it is broken.... Steve > > > > this kernel revision is to use an external log device with raid5. You > > must also make sure to use an inode size larger than the default with > > a filesystem this big (mkfs ... -i size=512 ...). Without getting to > > technical, this will stop your inode numbers from overflowing 32 bits. > > > > > > > > Now there's rumors on l-k that the FS size might be limited by the > > > signedness of something in the block layer, effectively limiting us to 1T > B. > > > > We appear to have people working successfully beyond the 1Tbyte boundary, > > the 1Tb limit may be specific to some device drivers which are not as > > cleanly coded. > > > I haven't been terribly happy with the 3ware drivers/cards in general, so > we'll see. FWIW, I tried upgrading to their latest driver on an smp system > and simply insmod-ing the newly compiled driver tickles the NMI watchdog > which dumps me directly into kdb. Fun stuff. :-/ > > 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 Aug 2 11:32:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72IWIQ18056 for linux-xfs-outgoing; Thu, 2 Aug 2001 11:32:18 -0700 Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72IWGV18029 for ; Thu, 2 Aug 2001 11:32:16 -0700 Received: from online.no (217-13-10-85.dd.nextgentel.com [217.13.10.85]) by mail.broadpark.no (Postfix) with ESMTP id 4E2AE7F50 for ; Thu, 2 Aug 2001 20:32:07 +0200 (MET DST) Message-ID: <3B69F041.90696624@online.no> Date: Thu, 02 Aug 2001 20:28:49 -0400 From: Knut J Bjuland X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-pre3-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: redhat linux 7.2 beta roswel. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are there any chance off seing XFS patched redhat 7.1 beta kernel from SGI. I have manage to patch redhat kernel with IBMs JFS but I am unable to hand patch it with XFS. From owner-linux-xfs@oss.sgi.com Thu Aug 2 11:41:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72IfCQ19658 for linux-xfs-outgoing; Thu, 2 Aug 2001 11:41:12 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72IfAV19637 for ; Thu, 2 Aug 2001 11:41:10 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id UAA27246; Thu, 2 Aug 2001 20:41:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id UAA16203; Thu, 2 Aug 2001 20:41:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id F419F57306; Thu, 2 Aug 2001 20:41:01 +0200 (CEST) Received: from ch.sauter-bc.com (ppp01.cad.sba [10.1.249.1]) by mobile.sauter-bc.com (Postfix) with ESMTP id 83E8C25835; Thu, 2 Aug 2001 20:41:00 +0200 (CEST) Message-ID: <3B699EDB.552A4951@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 20:41:31 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Straz Cc: linux-xfs Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer References: <3B694B49.209B904C@ch.sauter-bc.com> <3B695A70.6C2D70FD@sgi.com> <3B69610B.41A40F18@ch.sauter-bc.com> <3B69899A.C4E7B099@ch.sauter-bc.com> <20010802123654.D1694@sgi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f72IfBV19638 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Straz schrieb: > On Thu, Aug 02, 2001 at 07:10:50PM +0200, Simon Matter wrote: > > Unfortunately the problem applies to all directories, but for example in /usr > > there are just a few files with wrong permissions because usually the problem > > applies to config files created at boot time. I tried to figure out which > > device files do not belong to an RPM and could also have wrong permissions. I > > guess this could be a difficult task because mode 644 is not always the > > solution there. > > Does an `rpm --setperms -a` fix most of the wrong permissions? The affected files are not installed from an RPM packet so rpm will most likely not help us. > > -- > 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 Thu Aug 2 11:42:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72IgpA19996 for linux-xfs-outgoing; Thu, 2 Aug 2001 11:42:51 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72IgoV19977 for ; Thu, 2 Aug 2001 11:42:50 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA09907 for ; Thu, 2 Aug 2001 11:42:32 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2609432; Thu, 2 Aug 2001 13:41:25 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA41400; Thu, 2 Aug 2001 13:41:25 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f72Ifvt07480; Thu, 2 Aug 2001 13:41:57 -0500 Message-Id: <200108021841.f72Ifvt07480@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Knut J Bjuland cc: linux-xfs@oss.sgi.com Subject: Re: redhat linux 7.2 beta roswel. In-Reply-To: Message from Knut J Bjuland of "Thu, 02 Aug 2001 20:28:49 EDT." <3B69F041.90696624@online.no> Date: Thu, 02 Aug 2001 13:41:57 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Are there any chance off seing XFS patched redhat 7.1 beta kernel from > SGI. I have manage to patch redhat kernel with IBMs JFS but I am unable > to hand patch it with XFS. Just to stamp on this before the flood of requests starts, no we do not plan on providing patches to Redhat Beta releases. As we have frequently stated, we do not want to be in the business of doing a Linux distribution, we do not have the time or the man power. Sorry, Steve From owner-linux-xfs@oss.sgi.com Thu Aug 2 11:54:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72IsH122106 for linux-xfs-outgoing; Thu, 2 Aug 2001 11:54:17 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72IsEV22083 for ; Thu, 2 Aug 2001 11:54:14 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA24957 for ; Thu, 2 Aug 2001 11:54:00 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2609544 for ; Thu, 2 Aug 2001 13:52:57 -0500 (CDT) 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 NAA89160 for ; Thu, 2 Aug 2001 13:52:57 -0500 (CDT) Subject: FIX: World-writeable files repair script From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-uHcugs/Nhs7bOBV4kwPS" X-Mailer: Evolution/0.11 (Beta Release) Date: 02 Aug 2001 13:50:32 -0500 Message-Id: <996778232.17558.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-uHcugs/Nhs7bOBV4kwPS Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, thanks for all the feedback on this one... Here's a script that should fix all the mis-permed files that may be lurking out there... Sending this out now to get feedback before I unleash it on the world at large. I'll probably re-spin the installer, but only with a quick tweak to anaconda to squash this bug. I really can't go down the path of fixing all the buglets that have turned up since 1.0.1. Those will get fixed in the next "real" release. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. --=-uHcugs/Nhs7bOBV4kwPS Content-Type: text/plain Content-Disposition: attachment; filename=fix-perms Content-ID: <996778211.17404.8.camel@stout.americas.sgi.com> Content-Transfer-Encoding: 7bit #!/bin/bash echo echo "This script will change permissions on many system config files." echo "These files were set wrong during install due to a generic" echo "kernel bug in 2.4.3." echo echo -n "Continue? (Y/N) " read continue case "$continue" in "Y" | "y" ) ;; * ) echo "Ok, but you really should fix this... please take a look at the script" exit ;; esac FILES="/boot/initrd-2.4.3-SGI_XFS_1.0.1smp.img /boot/initrd-2.4.3-SGI_XFS_1.0.1.img /etc/sysconfig/i18n /etc/sysconfig/mouse /etc/sysconfig/keyboard /etc/sysconfig/network /etc/sysconfig/clock /etc/sysconfig/desktop /etc/sysconfig/hwconf /etc/X11/XF86Config /etc/X11/XF86Config-4 /etc/ld.so.conf /etc/shells /etc/syslog.conf /etc/rndc.conf /etc/resolv.conf /etc/sgml/sgml-docbook-3.0.cat /etc/sgml/catalog /etc/sgml/sgml-docbook-3.1.cat /etc/sgml/sgml-docbook-4.0.cat /etc/sgml/sgml-docbook-4.1.cat /etc/sgml/xml-docbook-4.1.cat /etc/pango/pango.modules /etc/hosts /usr/share/doc/libtool-1.3.5/demo/config.h.in /usr/share/fonts/default/TrueType/fonts.scale /usr/share/fonts/fontmap /usr/share/texmf/web2c/jadetex.log /usr/share/texmf/web2c/pdfjadetex.log /usr/share/texmf/web2c/jadetex.fmt /usr/share/texmf/web2c/pdfjadetex.fmt /usr/lib/mozilla/chrome/overlayinfo/communicator/content/overlays.rdf /usr/lib/mozilla/chrome/overlayinfo/navigator/content/overlays.rdf /usr/lib/mozilla/chrome/overlayinfo/messenger/content/overlays.rdf /usr/lib/mozilla/chrome/overlayinfo/editor/content/overlays.rdf /usr/lib/mozilla/chrome/all-packages.rdf /usr/lib/mozilla/chrome/all-locales.rdf /usr/lib/mozilla/chrome/all-skins.rdf /usr/lib/mozilla/chrome/user-skins.rdf /usr/lib/mozilla/chrome/user-locales.rdf /usr/lib/mozilla/component.reg" DIRS="/etc/sysconfig /usr/lib/mozilla/chrome/overlayinfo" # Fix files... echo echo "Fixing permissions on files:" for FILE in $FILES do if [ -e $FILE ] then echo "Setting $FILE to 644" chmod 644 $FILE fi done # And directories... echo echo "Fixing permissions on directories:" for DIR in $DIRS do if [ -e $DIR ] then echo "Setting $DIR/ to 755" chmod 755 $DIR fi done echo echo "Done" --=-uHcugs/Nhs7bOBV4kwPS-- From owner-linux-xfs@oss.sgi.com Thu Aug 2 11:55:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72ItFB22328 for linux-xfs-outgoing; Thu, 2 Aug 2001 11:55:15 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72ItDV22309 for ; Thu, 2 Aug 2001 11:55:13 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA25020 for ; Thu, 2 Aug 2001 11:55:00 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2594189; Thu, 2 Aug 2001 13:53:57 -0500 (CDT) 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 NAA90753; Thu, 2 Aug 2001 13:53:56 -0500 (CDT) Subject: Re: Insecure world writable files from XFS 1.0.1 ISO installer From: Eric Sandeen To: Simon Matter Cc: Nathan Straz , linux-xfs In-Reply-To: <3B699EDB.552A4951@ch.sauter-bc.com> References: <3B694B49.209B904C@ch.sauter-bc.com> <3B695A70.6C2D70FD@sgi.com> <3B69610B.41A40F18@ch.sauter-bc.com> <3B69899A.C4E7B099@ch.sauter-bc.com> <20010802123654.D1694@sgi.com> <3B699EDB.552A4951@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 02 Aug 2001 13:51:31 -0500 Message-Id: <996778291.17558.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 02 Aug 2001 20:41:31 +0200, Simon Matter wrote: > Nathan Straz schrieb: > > Does an `rpm --setperms -a` fix most of the wrong permissions? > > The affected files are not installed from an RPM packet so rpm will most likely > not help us. Although, it's interesting - there are a FEW mis-permed files that ARE from an RPM - they must have been tweaked after they were installed, I guess. -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 Aug 2 13:13:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72KDm004081 for linux-xfs-outgoing; Thu, 2 Aug 2001 13:13:48 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72KDjV04050 for ; Thu, 2 Aug 2001 13:13:45 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.31 #1) id 15SOqm-0000A5-00; Thu, 02 Aug 2001 22:13:45 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.0/8.9.3) id f72KD6u19691; Thu, 2 Aug 2001 16:13:06 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: linux-xfs@oss.sgi.com, axp-list@redhat.com Subject: Alpha XFS installer update disk From: "Martin K. Petersen" Organization: mkp.net Date: 02 Aug 2001 16:13:06 -0400 Message-ID: Lines: 23 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 Rich Payne discovered that when using the automagic server install path, /boot wouldn't be big enough. This update fixes that problem. If you can't wait until the next ISO comes out and you intend to install a server system using automatic partitioning, here's what to do: Grab the following disk image, dd it to a floppy and add `update' to the aboot command line arguments when booting off the install CD. When prompted if you have an update disk, insert the floppy and press return. Proceed with installation as usual. ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/unsupported/Alpha-XFS-Update-Aug02-15.img Enjoy! -- 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 Aug 2 13:26:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72KQnD06478 for linux-xfs-outgoing; Thu, 2 Aug 2001 13:26:49 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72KQmV06459 for ; Thu, 2 Aug 2001 13:26:48 -0700 Received: from thebarn.com ([63.231.179.33]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f72KQhXi058690; Thu, 2 Aug 2001 15:26:43 -0500 (CDT) Message-ID: <3B69B6F7.CAB2F89B@thebarn.com> Date: Thu, 02 Aug 2001 15:24:23 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.3-xfs-1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Knut J Bjuland CC: linux-xfs@oss.sgi.com Subject: Re: redhat linux 7.2 beta roswel. References: <3B69F041.90696624@online.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Knut J Bjuland wrote: > Are there any chance off seing XFS patched redhat 7.1 beta kernel from > SGI. I have manage to patch redhat kernel with IBMs JFS but I am unable > to hand patch it with XFS. I might do one if I find the time, I was thinking it might be time for a new mandrake rpm also. But I wouldn't count on it real soon, lots of stuff in the queue before new rpm's. BTW patching really isn't a good way to do tree merging, the tool of choice seems to be mergetrees. -Russell From owner-linux-xfs@oss.sgi.com Thu Aug 2 13:39:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72KdCi08780 for linux-xfs-outgoing; Thu, 2 Aug 2001 13:39:12 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72KdAV08746 for ; Thu, 2 Aug 2001 13:39:10 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA02620 for ; Thu, 2 Aug 2001 13:38:53 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2585667 for ; Thu, 2 Aug 2001 15:37:48 -0500 (CDT) 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 PAA90253; Thu, 2 Aug 2001 15:37:47 -0500 (CDT) Subject: Re: FIX: World-writeable files repair script From: Eric Sandeen To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <996778232.17558.9.camel@stout.americas.sgi.com> References: <996778232.17558.9.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 02 Aug 2001 15:35:21 -0500 Message-Id: <996784521.17558.13.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 02 Aug 2001 13:50:32 -0500, Eric Sandeen wrote: > Here's a script that should fix all the mis-permed files that may be > lurking out there... Whoops, if you use this on a laptop, it misses /etc/sysconfig/pcmcia, you'll need to fix that one up by hand. -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 Aug 2 13:40:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72Kee509106 for linux-xfs-outgoing; Thu, 2 Aug 2001 13:40:40 -0700 Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72KebV09075 for ; Thu, 2 Aug 2001 13:40:38 -0700 Received: from auto-nb1.arosa.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA21359; Thu, 2 Aug 2001 22:40:34 +0200 (CEST) Message-Id: <4.3.2.7.2.20010802223908.03ebe188@pop.xs4all.nl> X-Sender: seth@pop.arosa.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Aug 2001 22:40:11 +0200 To: Steve Roseman , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfsrestore assertion failure In-Reply-To: <3B698AEA.5A40D3D6@lehigh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:16 2-8-2001 -0400, Steve Roseman wrote: > > # xfsrestore -t -f /dev/st0 > >.... > > xfsrestore: examining media file 1 > > xfsrestore: seeking past media file directory dump > > xfsrestore: drive_scsitape.c:1461: do_next_mark: Assertion > > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t ) > > ( contextp->dc_recsz )' failed. > > Aborted (core dumped) > >The following fix seems to resolve the problem. xfsrestore -t works, at >least. (I'll try a real restore later.) I suspect the problem is in >endian-converting first_mark_offset, maybe when it contains the value >-1. > >Possibly this fix will make the dumps compatible with IRIX, but I >suspect few will mind. I suspect more since this means that people migrating from Irix can still read their backups. I know I would be happy if you could still restore your backup. 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 Aug 2 13:47:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72KlKQ10413 for linux-xfs-outgoing; Thu, 2 Aug 2001 13:47:20 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72KlHV10390 for ; Thu, 2 Aug 2001 13:47:17 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id WAA05269; Thu, 2 Aug 2001 22:47:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id WAA23302; Thu, 2 Aug 2001 22:47:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3EEB357306; Thu, 2 Aug 2001 22:47:03 +0200 (CEST) Received: from ch.sauter-bc.com (ppp01.cad.sba [10.1.249.1]) by mobile.sauter-bc.com (Postfix) with ESMTP id E2A7625835; Thu, 2 Aug 2001 22:47:01 +0200 (CEST) Message-ID: <3B69BC63.7F526832@ch.sauter-bc.com> Date: Thu, 02 Aug 2001 22:47:31 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: FIX: World-writeable files repair script References: <996778232.17558.9.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f72KlIV10395 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > Ok, thanks for all the feedback on this one... > > Here's a script that should fix all the mis-permed files that may be > lurking out there... Sending this out now to get feedback before I > unleash it on the world at large. The script looks promising but the list of files is not complete. How did you create the list of files? I just found that /etc/sysconfig/pcmcia is not on the list but it is actually installed with wrong permissions. > > > I'll probably re-spin the installer, but only with a quick tweak to > anaconda to squash this bug. I really can't go down the path of fixing > all the buglets that have turned up since 1.0.1. Those will get fixed > in the next "real" release. > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > > ------------------------------------------------------------------------ > Name: fix-perms > fix-perms Type: Plain Text (text/plain) > Encoding: 7bit From owner-linux-xfs@oss.sgi.com Thu Aug 2 13:49:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72KnTl10894 for linux-xfs-outgoing; Thu, 2 Aug 2001 13:49:29 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72KnQV10874 for ; Thu, 2 Aug 2001 13:49:26 -0700 Received: from auto-nb1.arosa.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA25678; Thu, 2 Aug 2001 22:49:13 +0200 (CEST) Message-Id: <4.3.2.7.2.20010802224302.03e82e68@pop.xs4all.nl> X-Sender: seth@pop.arosa.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Aug 2001 22:48:50 +0200 To: yocum@fnal.gov From: Seth Mos Subject: Re: XFS fs size limit? Cc: xfs-list In-Reply-To: <3B699676.DD3D2BE3@fnal.gov> References: <200108021734.f72HYDo07108@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:05 2-8-2001 -0500, yocum@fnal.gov wrote: >Steve, > >I assume you mean software RAID5, right? I've got a RAID50 array: 2 8-port >3ware cards in hw raid5, then those two devices combined software raid0. I >didn't bother to make the log on a separate device, but I could, if need be. That is silly. Just make a big raid0 of it. If for some reason one of the 3ware cards takes a dump you WILL LOSE ALL YOUR DATA. I have seen this mistake (if it is) before at www.tweakers.net where they configured the 4 disk into a raid 01 instead of 10. If you want redundancy make a raid0 on the 3ware disk and a raid1 of these 2 3ware cards. That is make 2 raid1 devices and then a raid0. If something happens to either one of the raid1 array logical devices (not disk but software failure) everything will be lost. Which was exactly what happend. They raid controller (Ami megaraid) got upset after one disk died and they lost there complete Mysql Database. > > this kernel revision is to use an external log device with raid5. You > > must also make sure to use an inode size larger than the default with > > a filesystem this big (mkfs ... -i size=512 ...). Without getting to > > technical, this will stop your inode numbers from overflowing 32 bits. > > > > > > > > Now there's rumors on l-k that the FS size might be limited by the > > > signedness of something in the block layer, effectively limiting us > to 1TB. > > > > We appear to have people working successfully beyond the 1Tbyte boundary, > > the 1Tb limit may be specific to some device drivers which are not as > > cleanly coded. > > >I haven't been terribly happy with the 3ware drivers/cards in general, so >we'll see. FWIW, I tried upgrading to their latest driver on an smp system >and simply insmod-ing the newly compiled driver tickles the NMI watchdog >which dumps me directly into kdb. Fun stuff. :-/ Which is exactly the reason to avoid the above mentioned configuration. If one card dies you have just lost all your data. 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 Aug 2 13:52:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72Kq9F11482 for linux-xfs-outgoing; Thu, 2 Aug 2001 13:52:09 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72Kq7V11463 for ; Thu, 2 Aug 2001 13:52:07 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA26231; Thu, 2 Aug 2001 22:52:05 +0200 (CEST) Message-Id: <4.3.2.7.2.20010802224927.03e36be8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Aug 2001 22:51:43 +0200 To: Knut J Bjuland , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: redhat linux 7.2 beta roswel. In-Reply-To: <3B69F041.90696624@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 20:28 2-8-2001 -0400, Knut J Bjuland wrote: >Are there any chance off seing XFS patched redhat 7.1 beta kernel from >SGI. I have manage to patch redhat kernel with IBMs JFS but I am unable >to hand patch it with XFS. That's because it is based on a -ac tree which makes it near impossible to patch unless your first name is Russel (Hi!). :-) A 1.1 release will be brought out after 7.2 hits the street. We might have some testing releases along the way. They have to fetch the beta first :-) 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 Aug 2 13:54:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72Ks3D11880 for linux-xfs-outgoing; Thu, 2 Aug 2001 13:54:03 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72Ks1V11860 for ; Thu, 2 Aug 2001 13:54:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA10792 for ; Thu, 2 Aug 2001 13:53:48 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2611452; Thu, 2 Aug 2001 15:52:45 -0500 (CDT) 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 PAA00947; Thu, 2 Aug 2001 15:52:44 -0500 (CDT) Subject: Re: FIX: World-writeable files repair script From: Eric Sandeen To: Simon Matter Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B69BC63.7F526832@ch.sauter-bc.com> References: <996778232.17558.9.camel@stout.americas.sgi.com> <3B69BC63.7F526832@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 02 Aug 2001 15:50:18 -0500 Message-Id: <996785418.17555.20.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 02 Aug 2001 22:47:31 +0200, Simon Matter wrote: > The script looks promising but the list of files is not complete. Yep, I just found the pcmcia problem. > How did you > create the list of files? Essentially by searching for files w/ 666, and dirs with 777, and taking out the obvious ones (like game scores, etc...) Your RPM query trick is nifty, but I actually found a few files with bad permissions which did belong to RPMs... I have an anaconda update disk going to fix this, installing a full system with it now, we'll see what's left when it's done. -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 Aug 2 13:57:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72Kvfr12665 for linux-xfs-outgoing; Thu, 2 Aug 2001 13:57:41 -0700 Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72KvdV12646 for ; Thu, 2 Aug 2001 13:57:39 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA22506; Thu, 2 Aug 2001 22:57:31 +0200 (CEST) Message-Id: <4.3.2.7.2.20010802225356.03e88a78@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Aug 2001 22:57:08 +0200 To: Russell Cattelan , Knut J Bjuland From: Seth Mos Subject: Re: redhat linux 7.2 beta roswel. Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B69B6F7.CAB2F89B@thebarn.com> References: <3B69F041.90696624@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:24 2-8-2001 -0500, Russell Cattelan wrote: >Knut J Bjuland wrote: > > > Are there any chance off seing XFS patched redhat 7.1 beta kernel from > > SGI. I have manage to patch redhat kernel with IBMs JFS but I am unable > > to hand patch it with XFS. > >I might do one if I find the time, I was thinking it might be time for a >new mandrake rpm also. Are there some Mandrake people monitoring the list? I have seen one of the developers post to the list before. >But I wouldn't count on it real soon, lots of stuff in the queue before >new rpm's. As always. >BTW patching really isn't a good way to do tree merging, >the tool of choice seems to be mergetrees. hmmm. 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 Aug 2 14:04:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72L4uZ14118 for linux-xfs-outgoing; Thu, 2 Aug 2001 14:04:56 -0700 Received: from codon.com (www.stampingchat.com [64.78.130.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72L4sV14093 for ; Thu, 2 Aug 2001 14:04:54 -0700 Received: (qmail 24815 invoked by uid 516); 2 Aug 2001 21:13:39 -0000 Received: from nw@codon.com by helix with qmail-scanner-0.96 (. Clean. Processed in 0.051929 secs); 02 Aug 2001 21:13:39 -0000 Received: from weasel.local.iboats.com (HELO weasel) (64.78.130.80) by codon.com with SMTP; 2 Aug 2001 21:13:39 -0000 Message-ID: <001901c11b96$3f07ba80$50824e40@iboats.com> From: "Steve Wolfe" To: "xfs-list" References: <200108021734.f72HYDo07108@jen.americas.sgi.com> <4.3.2.7.2.20010802224302.03e82e68@pop.xs4all.nl> Subject: Re: XFS fs size limit? Date: Thu, 2 Aug 2001 15:00:42 -0600 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 > >I assume you mean software RAID5, right? I've got a RAID50 array: 2 8-port > >3ware cards in hw raid5, then those two devices combined software raid0. I > >didn't bother to make the log on a separate device, but I could, if need be. > > That is silly. Just make a big raid0 of it. If for some reason one of the > 3ware cards takes a dump you WILL LOSE ALL YOUR DATA. (snip) > Which is exactly the reason to avoid the above mentioned configuration. If > one card dies you have just lost all your data. Personally, I'd bet on a drive or two going out before the controller. I haven't had any sort of drive controller (IDE/SCSI/RAID) go out in nearly a decade, but I've had plenty of drives go South on me. > Which was exactly what happend. They raid > controller (Ami megaraid) got upset after one disk died and they lost there > complete Mysql Database. Since this isn't the place, I won't point out the obvious flaws in their backup/recovery scheme. My experience with the MegaRAIDs has been that the cards do work fine, provided that you do everything exactly the way the card expects - which is sometimes complicated, sometimes difficult, and usually counter-intuitive. ; ) steve From owner-linux-xfs@oss.sgi.com Thu Aug 2 14:30:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72LUMn18645 for linux-xfs-outgoing; Thu, 2 Aug 2001 14:30:22 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72LUJV18619 for ; Thu, 2 Aug 2001 14:30:19 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA10282; Thu, 2 Aug 2001 23:30:15 +0200 (CEST) Message-Id: <4.3.2.7.2.20010802231931.03d33168@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Aug 2001 23:29:52 +0200 To: "Steve Wolfe" , "xfs-list" From: Seth Mos Subject: Re: XFS fs size limit? In-Reply-To: <001901c11b96$3f07ba80$50824e40@iboats.com> References: <200108021734.f72HYDo07108@jen.americas.sgi.com> <4.3.2.7.2.20010802224302.03e82e68@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:00 2-8-2001 -0600, Steve Wolfe wrote: > > >I assume you mean software RAID5, right? I've got a RAID50 array: 28-port > > >3ware cards in hw raid5, then those two devices combined softwareraid0. I > > >didn't bother to make the log on a separate device, but I could, > ifneed be. > > > > That is silly. Just make a big raid0 of it. If for some reason one ofthe > > 3ware cards takes a dump you WILL LOSE ALL YOUR DATA. > >(snip) > > > Which is exactly the reason to avoid the above mentioned configuration.If > > one card dies you have just lost all your data. > > Personally, I'd bet on a drive or two going out before the controller. >I haven't had any sort of drive controller (IDE/SCSI/RAID) go out in >nearly a decade, but I've had plenty of drives go South on me. I have seen lots of drives go bad too. But don't discount Murphy. You might just have a bad day and a firmware upgrade of your controller resets the raid set. Most people with more then one 3ware card will set it up in JBOD mode and then use it as a software raid5 with a external log. > > Which was exactly what happend. They raid > > controller (Ami megaraid) got upset after one disk died and they lost > therI > > complete Mysql Database. > > Since this isn't the place, I won't point out the obvious flaws in >their backup/recovery scheme. What's a backup? And recovery is for wimps ;) > My experience with the MegaRAIDs has been >that the cards do work fine, provided that you do everything exactly the >way the card expects - which is sometimes complicated, sometimes >difficult, and usually counter-intuitive. ; ) Yup. I have screwed up raid sets before on our servers too.(during testing and with backups). I just feel that my data would not be safe with the setup that you have provided. They even had bugs in the 3ware raid config which caused corruption in degraded mode. If that happens on your raid0 array or any array you are going to lose data. But I think that the chances of severe damage will grow in this raid0 setup. 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 Aug 2 14:51:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72LpTF22493 for linux-xfs-outgoing; Thu, 2 Aug 2001 14:51:29 -0700 Received: from smtp3.cern.ch (smtp3.cern.ch [137.138.131.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72LpQV22459 for ; Thu, 2 Aug 2001 14:51:26 -0700 Received: from lxplus039.cern.ch (IDENT:root@lxplus039.cern.ch [137.138.161.91]) by smtp3.cern.ch (8.11.5/8.11.5) with ESMTP id f72LpKo17972; Thu, 2 Aug 2001 23:51:20 +0200 (MET DST) Received: (from fuji@localhost) by lxplus039.cern.ch (8.9.3/8.9.3) id XAA04405; Thu, 2 Aug 2001 23:51:19 +0200 Date: Thu, 2 Aug 2001 23:51:19 +0200 From: KELEMEN Peter To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_force_shutdown with linux-2.4.6-xfs-07052001? Message-ID: <20010802235119.B2291@lxplus039.cern.ch> Reply-To: KELEMEN Peter References: <4.3.2.7.2.20010801093900.033a2008@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20010801093900.033a2008@pop.xs4all.nl> User-Agent: Mutt/1.3.19i Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20 X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-KeyID: 1024/45F83E45 1998/04/04 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en X-MIME-Autoconverted: from 8bit to quoted-printable by smtp3.cern.ch id f72LpKo17972 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f72LpRV22467 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk * Seth Mos (knuffie@xs4all.nl) [20010801 09:46]: > That is probably caused by an IO error. I see you are using lvm > which could be related. If an IO error occurs the filesystem > will shutdown to prevent more damage. Well. I checked the hard drive (read-only) in another machine, it reports no errors. S.M.A.R.T. is happy, no relocated sectors or raw read, seek or CRC errors. Nothing. > This error could be on the device (bad cluster on the disk) or > something in a software layer like md or lvm going wrong which > is seen by XFS as a hardware error. What is actually the lvm > device. Do you use md or any other software that might > interfere? IDE or scsi and what controller and system. How is > the lvm device constructed. EIDE, no UDMA. No MD at all, LVM is pretty straightforward, a lonely 20G disk sliced into two, sitting in an extended partition. A big partition is actually the only PV, carrying a VG with six LVs. No magic, this is supposed to be a workstation. Kernel is tracked CVS, compiled with egcs-1.1.2. No overclock. The thing hasn't happened since (knock on wood). Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Thu Aug 2 15:02:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72M2Wl24639 for linux-xfs-outgoing; Thu, 2 Aug 2001 15:02:32 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72M2TV24617 for ; Thu, 2 Aug 2001 15:02:29 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA14966; Fri, 3 Aug 2001 00:02:28 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA29137; Fri, 3 Aug 2001 00:02:27 +0200 (CEST) Date: Fri, 3 Aug 2001 00:02:27 +0200 (CEST) From: Seth Mos To: KELEMEN Peter cc: linux-xfs@oss.sgi.com Subject: Re: xfs_force_shutdown with linux-2.4.6-xfs-07052001? In-Reply-To: <20010802235119.B2291@lxplus039.cern.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2 Aug 2001, KELEMEN Peter wrote: > * Seth Mos (knuffie@xs4all.nl) [20010801 09:46]: > > > That is probably caused by an IO error. I see you are using lvm > > which could be related. If an IO error occurs the filesystem > > will shutdown to prevent more damage. > > Well. I checked the hard drive (read-only) in another machine, it > reports no errors. S.M.A.R.T. is happy, no relocated sectors or > raw read, seek or CRC errors. Nothing. That counters the hardware site. > > This error could be on the device (bad cluster on the disk) or > > something in a software layer like md or lvm going wrong which > > is seen by XFS as a hardware error. What is actually the lvm > > device. Do you use md or any other software that might > > interfere? IDE or scsi and what controller and system. How is > > the lvm device constructed. > > EIDE, no UDMA. No MD at all, LVM is pretty straightforward, a > lonely 20G disk sliced into two, sitting in an extended partition. > A big partition is actually the only PV, carrying a VG with six > LVs. No magic, this is supposed to be a workstation. Kernel is > tracked CVS, compiled with egcs-1.1.2. No overclock. That indeed seems very simple. The problem is that it is hard to debug since it will probably be extrmely hard to replicate. If you can find a way to reproduce this, let us know please. We'd love to squash XFS related bugs ;-) I have absolutely zipp experience with LVM so I can't comment on any problems on that front. > The thing hasn't happened since (knock on wood). Good luck then, you will need it for the next knock on wood. Cheers From owner-linux-xfs@oss.sgi.com Thu Aug 2 15:24:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72MObs28523 for linux-xfs-outgoing; Thu, 2 Aug 2001 15:24:37 -0700 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72MOYV28492 for ; Thu, 2 Aug 2001 15:24:34 -0700 Received: from [195.20.224.219] (helo=mrvdom03.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15SQtN-00058V-00; Fri, 3 Aug 2001 00:24:33 +0200 Received: from pd901e258.dip.t-dialin.net ([217.1.226.88] helo=kernelpanix.aura.of.mankind) by mrvdom03.schlund.de with esmtp (Exim 2.12 #2) id 15SQtM-0006NV-00; Fri, 3 Aug 2001 00:24:33 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f72Llui03836; Thu, 2 Aug 2001 23:47:56 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Thu, 2 Aug 2001 23:47:56 +0200 From: utz lehmann To: Eric Sandeen Cc: Simon Matter , linux-xfs@oss.sgi.com Subject: Re: FIX: World-writeable files repair script Message-ID: <20010802234756.A3803@s2y4n2c.de> References: <996778232.17558.9.camel@stout.americas.sgi.com> <3B69BC63.7F526832@ch.sauter-bc.com> <996785418.17555.20.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: <996785418.17555.20.camel@stout.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric Sandeen [sandeen@sgi.com] wrote: > Essentially by searching for files w/ 666, and dirs with 777, and taking > out the obvious ones (like game scores, etc...) Your RPM query trick is > nifty, but I actually found a few files with bad permissions which did > belong to RPMs... On an Unixsystem no 0777 dirs should exist. 1777 (drwxrwxrwt) are the right permissions. utz From owner-linux-xfs@oss.sgi.com Thu Aug 2 15:34:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72MYUS30328 for linux-xfs-outgoing; Thu, 2 Aug 2001 15:34:30 -0700 Received: from frodo.ezprohosting.com ([216.74.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72MYRV30308 for ; Thu, 2 Aug 2001 15:34:27 -0700 Received: from c922720-a.sttln1.wa.home.com ([65.0.77.21] helo=windows) by frodo.ezprohosting.com with smtp (Exim 3.20 #1) id 15SR28-0001Du-00 for linux-xfs@oss.sgi.com; Thu, 02 Aug 2001 18:33:36 -0400 Message-ID: <00ce01c11ba2$bcb5af80$020144c0@windows> From: "Eric Peters" To: Subject: default ACL? Date: Thu, 2 Aug 2001 15:30:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01C11B68.0E67B1B0" 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 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - frodo.ezprohosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - peters.org Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00CB_01C11B68.0E67B1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm basically just trying to be able and delegate a group of users rw = permission for a directory /www and all sub directories (or there would = be 5 global accounts and a couple accounts could only access certain sub = directories / etc) The mask has me fairly confused I must say, in that despite having = g::r-x:m::rwx, the directory has g+rwx I also want an easy way for it all to be inherited - as well as only = "directories" would be +x, where normal files wouldn't need the = executable bit set Are there any other utilities other than chacl for managing the ACLs? = Or perhaps a good set of sed scripts for "adding" to existing ACLs and = the like Thanks, Eric ------=_NextPart_000_00CB_01C11B68.0E67B1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm basically just trying to be able = and delegate a=20 group of users rw permission for a directory /www and all sub = directories (or=20 there would be 5 global accounts and a couple accounts could only access = certain=20 sub directories / etc)
 
The mask has me fairly confused I must = say, in that=20 despite having g::r-x:m::rwx, the directory has g+rwx
 
I also want an easy way for it all to = be inherited=20 - as well as only "directories" would be +x, where normal files wouldn't = need=20 the executable bit set
 
Are there any other utilities other = than chacl for=20 managing the ACLs?  Or perhaps a good set of sed scripts for = "adding" to=20 existing ACLs and the like
 
Thanks,
 
Eric
------=_NextPart_000_00CB_01C11B68.0E67B1B0-- From owner-linux-xfs@oss.sgi.com Thu Aug 2 15:56:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72MufI01747 for linux-xfs-outgoing; Thu, 2 Aug 2001 15:56:41 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72MudV01722 for ; Thu, 2 Aug 2001 15:56:39 -0700 Received: from [195.20.224.219] (helo=mrvdom03.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15SROP-0001eE-00 for linux-xfs@oss.sgi.com; Fri, 3 Aug 2001 00:56:37 +0200 Received: from pd901e258.dip.t-dialin.net ([217.1.226.88] helo=kernelpanix.aura.of.mankind) by mrvdom03.schlund.de with esmtp (Exim 2.12 #2) id 15SROP-0007Dc-00 for linux-xfs@oss.sgi.com; Fri, 3 Aug 2001 00:56:37 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f72MK4w04085 for linux-xfs@oss.sgi.com; Fri, 3 Aug 2001 00:20:04 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Fri, 3 Aug 2001 00:20:04 +0200 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: Strage values from FIBMAP on holes or after end of file Message-ID: <20010803002004.A4026@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 The FIBMAP ioctl on holes or after end of file gives the values -1 to 6. ext2 and reiserfs reurns 0. I thing this is the right value. The attached programm FIBMAPs the first 32 512byte blocks of a file. # echo hole >HOLE # echo hole | dd of=HOLE bs=4096 seek=2 # ./fib HOLE 0 [0]: 452112 1 [0]: 452113 2 [0]: 452114 3 [0]: 452115 4 [0]: 452116 5 [0]: 452117 6 [0]: 452118 7 [0]: 452119 8 [0]: -1 9 [0]: 0 10 [0]: 1 11 [0]: 2 12 [0]: 3 13 [0]: 4 14 [0]: 5 15 [0]: 6 16 [0]: 452104 17 [0]: 452105 18 [0]: 452106 19 [0]: 452107 20 [0]: 452108 21 [0]: 452109 22 [0]: 452110 23 [0]: 452111 24 [0]: -1 25 [0]: 0 26 [0]: 1 27 [0]: 2 28 [0]: 3 29 [0]: 4 30 [0]: 5 31 [0]: 6 Blocks 8 - 15 are the hole. Block 23 ist the last block of the file. utz From owner-linux-xfs@oss.sgi.com Thu Aug 2 15:58:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72Mwq802267 for linux-xfs-outgoing; Thu, 2 Aug 2001 15:58:52 -0700 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72MwnV02239 for ; Thu, 2 Aug 2001 15:58:49 -0700 Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15SRQX-0006vi-00 for linux-xfs@oss.sgi.com; Fri, 3 Aug 2001 00:58:49 +0200 Received: from pd901e258.dip.t-dialin.net ([217.1.226.88] helo=kernelpanix.aura.of.mankind) by mrvdom00.schlund.de with esmtp (Exim 2.12 #2) id 15SRQW-0003FN-00 for linux-xfs@oss.sgi.com; Fri, 3 Aug 2001 00:58:48 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f72MMFO04108 for linux-xfs@oss.sgi.com; Fri, 3 Aug 2001 00:22:15 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Fri, 3 Aug 2001 00:22:15 +0200 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: Re: Strage values from FIBMAP on holes or after end of file Message-ID: <20010803002215.A4099@s2y4n2c.de> References: <20010803002004.A4026@s2y4n2c.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010803002004.A4026@s2y4n2c.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Forgot the attachment. utz lehmann [xfs@s2y4n2c.de] wrote: > Hi > > The FIBMAP ioctl on holes or after end of file gives the values -1 to 6. > ext2 and reiserfs reurns 0. I thing this is the right value. > > The attached programm FIBMAPs the first 32 512byte blocks of a file. > > # echo hole >HOLE > # echo hole | dd of=HOLE bs=4096 seek=2 > # ./fib HOLE > 0 [0]: 452112 > 1 [0]: 452113 > 2 [0]: 452114 > 3 [0]: 452115 > 4 [0]: 452116 > 5 [0]: 452117 > 6 [0]: 452118 > 7 [0]: 452119 > 8 [0]: -1 > 9 [0]: 0 > 10 [0]: 1 > 11 [0]: 2 > 12 [0]: 3 > 13 [0]: 4 > 14 [0]: 5 > 15 [0]: 6 > 16 [0]: 452104 > 17 [0]: 452105 > 18 [0]: 452106 > 19 [0]: 452107 > 20 [0]: 452108 > 21 [0]: 452109 > 22 [0]: 452110 > 23 [0]: 452111 > 24 [0]: -1 > 25 [0]: 0 > 26 [0]: 1 > 27 [0]: 2 > 28 [0]: 3 > 29 [0]: 4 > 30 [0]: 5 > 31 [0]: 6 > > Blocks 8 - 15 are the hole. Block 23 ist the last block of the file. > > > utz --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fib.c" #include #include #include #include #include int main (int argc, char **argv) { int i, block, res, fd; fd = open(argv[1],O_RDONLY); if (fd < 0) {exit(1);} for(i=0;i<32;i++) { block=i; res=ioctl(fd, FIBMAP, &block); printf("%9d [%d]: %d\n", i, res, block); } } --sdtB3X0nJg68CQEu-- From owner-linux-xfs@oss.sgi.com Thu Aug 2 16:32:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72NWJ807701 for linux-xfs-outgoing; Thu, 2 Aug 2001 16:32:19 -0700 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72NWGV07675 for ; Thu, 2 Aug 2001 16:32:16 -0700 Received: from [195.20.224.208] (helo=mrvdom01.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15SRwt-0001qQ-00; Fri, 3 Aug 2001 01:32:15 +0200 Received: from pd901e258.dip.t-dialin.net ([217.1.226.88] helo=kernelpanix.aura.of.mankind) by mrvdom01.schlund.de with esmtp (Exim 2.12 #2) id 15SRws-0000Li-00; Fri, 3 Aug 2001 01:32:14 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f72Mtff04433; Fri, 3 Aug 2001 00:55:41 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Fri, 3 Aug 2001 00:55:41 +0200 From: utz lehmann To: "Gonyou, Austin" Cc: linux-xfs@oss.sgi.com Subject: Re: Strage values from FIBMAP on holes or after end of file Message-ID: <20010803005541.A4343@s2y4n2c.de> References: <85063BBE668FD411944400D0B744267A6435E7@AUSMAIL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <85063BBE668FD411944400D0B744267A6435E7@AUSMAIL> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk No. The HOLE file has 3 4K Blocks. The first contains "hole\n" and padded the rest to 4K with NUL chars. The second block is a hole, never written to it (seek=2). It reads like 4K NUL chars. The 3rd contains only "hole\n". Only the 1st and 3rd block are phsically on disk. The FIBMAP ioctl returns the physical blocks of the blockdevice for a fileblock. 1st fileblock: 452112 - 452119 on disk (512byte blocks for XFS) 2nd fileblock: not on disk 3rd fileblock: 452104 - 452111 on disk but i think the FIBMAP ioctl should return 0 as blocknumber for holes and after the end of the file. utz Gonyou, Austin [austin@coremetrics.com] wrote: > So does this mean that there are 8 blocks wasted for every file write? > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > > > -----Original Message----- > > From: utz lehmann [mailto:xfs@s2y4n2c.de] > > Sent: Thursday, August 02, 2001 5:20 PM > > To: linux-xfs@oss.sgi.com > > Subject: Strage values from FIBMAP on holes or after end of file > > > > > > Hi > > > > The FIBMAP ioctl on holes or after end of file gives the > > values -1 to 6. > > ext2 and reiserfs reurns 0. I thing this is the right value. > > > > The attached programm FIBMAPs the first 32 512byte blocks of a file. > > > > # echo hole >HOLE > > # echo hole | dd of=HOLE bs=4096 seek=2 > > # ./fib HOLE > > 0 [0]: 452112 > > 1 [0]: 452113 > > 2 [0]: 452114 > > 3 [0]: 452115 > > 4 [0]: 452116 > > 5 [0]: 452117 > > 6 [0]: 452118 > > 7 [0]: 452119 > > 8 [0]: -1 > > 9 [0]: 0 > > 10 [0]: 1 > > 11 [0]: 2 > > 12 [0]: 3 > > 13 [0]: 4 > > 14 [0]: 5 > > 15 [0]: 6 > > 16 [0]: 452104 > > 17 [0]: 452105 > > 18 [0]: 452106 > > 19 [0]: 452107 > > 20 [0]: 452108 > > 21 [0]: 452109 > > 22 [0]: 452110 > > 23 [0]: 452111 > > 24 [0]: -1 > > 25 [0]: 0 > > 26 [0]: 1 > > 27 [0]: 2 > > 28 [0]: 3 > > 29 [0]: 4 > > 30 [0]: 5 > > 31 [0]: 6 > > > > Blocks 8 - 15 are the hole. Block 23 ist the last block of the file. > > > > > > utz > > From owner-linux-xfs@oss.sgi.com Thu Aug 2 17:20:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f730KiK15976 for linux-xfs-outgoing; Thu, 2 Aug 2001 17:20:44 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f730KfV15944 for ; Thu, 2 Aug 2001 17:20:41 -0700 Received: (qmail 10833 invoked from network); 3 Aug 2001 00:20:37 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 3 Aug 2001 00:20:37 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: FIX: World-writeable files repair script In-reply-to: Your message of "02 Aug 2001 13:50:32 EST." <996778232.17558.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Aug 2001 10:20:35 +1000 Message-ID: <11005.996798035@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 02 Aug 2001 13:50:32 -0500, Eric Sandeen wrote: >Here's a script that should fix all the mis-permed files that may be >lurking out there... Sending this out now to get feedback before I >unleash it on the world at large. Add /lib/modules/*/modules.dep. If that file is world writable you have a local root exploit. Due to the kernel bug, this has occurred on Slackware installs. As part of that exploit, people reported that /var/log/wtmp and /var/run/utmp are also created with the wrong mask. Not exploitable AFAIK but you can hide tasks if utmp is world writable. From owner-linux-xfs@oss.sgi.com Thu Aug 2 17:50:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f730oQX20349 for linux-xfs-outgoing; Thu, 2 Aug 2001 17:50:26 -0700 Received: from intra.b.lab.net (IDENT:root@[212.84.244.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f730oNV20329 for ; Thu, 2 Aug 2001 17:50:23 -0700 Received: from b.lab.net (home.orang.org [212.40.160.205] (may be forged)) by intra.b.lab.net (8.9.3/8.8.7) with ESMTP id CAA01632 for ; Fri, 3 Aug 2001 02:50:20 +0200 Message-ID: <3B6A115D.F921045F@b.lab.net> Date: Fri, 03 Aug 2001 03:50:05 +0100 From: Thomax X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en, de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: pagebuf in kernel causes abnormal behavior Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ok. i tried it very hard. i installed XFS1.0 and XFS1.0.1 (CVS) and the system hangs/reboots in a file system stress tests (fs-bench). no metter if i stress test the xfs or the ext2, in the file creation part the system dies. i tried without pagebuf and xfs and everything work (only ext2 test, of cause). but if i just include pagebuf or pagebuf and xfs the system dies. brief hardwareprofile: 2 x Pentium III (Coppermine) 930.434MHz 768MB RAM Tyan Thunder LE, S2510U3NG 36GB IBM Model: DDYS-T36950N Rev: S93E with onboard symbios x1010 U160 SCSI no more further details, because i do this all remote. so, no oops or dumps. hope you will fix it soon. i'm out if there is no hint how to solve it. thanks for your work anyway. all the rest worked well. i like to have xfs on linux and so on. thomax From owner-linux-xfs@oss.sgi.com Thu Aug 2 19:07:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7327Ka30626 for linux-xfs-outgoing; Thu, 2 Aug 2001 19:07:20 -0700 Received: from zok.corp.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7327IV30607 for ; Thu, 2 Aug 2001 19:07:18 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f732CQm12445 for ; Thu, 2 Aug 2001 19:12:26 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA54017 for linux-xfs@oss.sgi.com; Fri, 3 Aug 2001 12:05:55 +1000 (EST) Date: Fri, 3 Aug 2001 12:05:55 +1000 (EST) From: Nathan Scott Message-Id: <200108030205.MAA54017@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ppc/attr Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Aug 2 19:05:04 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100121a cmd/attr/libattr/attr.c - 1.8 cmd/attr/VERSION - 1.9 cmd/attr/debian/changelog - 1.9 cmd/attr/doc/CHANGES - 1.10 - incorporate syscall bug fix for powerpc from Juer Lee. From owner-linux-xfs@oss.sgi.com Thu Aug 2 19:49:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f732nYt01623 for linux-xfs-outgoing; Thu, 2 Aug 2001 19:49:34 -0700 Received: from rj.corp.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f732nWV01602 for ; Thu, 2 Aug 2001 19:49:32 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f732rbU19060 for ; Thu, 2 Aug 2001 19:53:37 -0700 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 TAA94529; Thu, 2 Aug 2001 19:48:53 -0700 (PDT) Message-ID: <3B6A1060.D895B2F6@sgi.com> Date: Thu, 02 Aug 2001 21:45:52 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: FIX: World-writeable files repair script References: <11005.996798035@ocs3.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > Add /lib/modules/*/modules.dep. If that file is world writable you > have a local root exploit. Due to the kernel bug, this has occurred on > Slackware installs. As part of that exploit, people reported that > /var/log/wtmp and /var/run/utmp are also created with the wrong mask. > Not exploitable AFAIK but you can hide tasks if utmp is world writable. modules.dep comes from the Red Hat kernel RPMs, and it doesn't appear to be re-generated or modified during the install, so I think we're fine here. -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 Aug 2 20:52:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f733qww09276 for linux-xfs-outgoing; Thu, 2 Aug 2001 20:52:58 -0700 Received: from rj.corp.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f733qtV09257 for ; Thu, 2 Aug 2001 20:52:55 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by rj.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f733uxU20073 for ; Thu, 2 Aug 2001 20:57:00 -0700 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA17773; Fri, 3 Aug 2001 13:51:30 +1000 (EST) Date: Fri, 3 Aug 2001 13:51:30 +1000 From: Timothy Shimmin To: Eric Peters Cc: linux-xfs@oss.sgi.com Subject: Re: default ACL? Message-ID: <20010803135130.H62222@boing.melbourne.sgi.com> References: <00ce01c11ba2$bcb5af80$020144c0@windows> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <00ce01c11ba2$bcb5af80$020144c0@windows>; from eric@peters.org on Thu, Aug 02, 2001 at 03:30:27PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric: On Thu, Aug 02, 2001 at 03:30:27PM -0700, Eric Peters wrote: > I'm basically just trying to be able and delegate a group of users rw > permission for a directory /www and all sub directories (or there would > be 5 global accounts and a couple accounts could only access certain > sub directories / etc) > > The mask has me fairly confused I must say, in that despite having > g::r-x:m::rwx, the directory has g+rwx Yeah I find it weird myself. But it seems to be part of the standard. I emailed about this on June 12 to Sebastian Dransfeld. Below is what I wrote to Sebastian about the application of a directory default ACL when a file is created inside the directory: | When the access ACL for a file of a directory with a default ACL | is created, it's ACE permissions are set by _intersection_ of the | respective default ACEs permission bits and the mode bits of the | parameter to open/creat. | | So if the creat mode bits don't have the execute (x) bit set for user | and other (which will depend on the application you use which makes the | create/open call), then nor will the USER_OBJ ACEs and OTHER ACEs. | Which is what you (Sebastian) saw. | The GROUP_OBJ ACE is treated differently if a MASK ACE exists, as | is the case in your example above. If we have a MASK ACE (see 5.3.1.2), | then the GROUP_OBJ ACE is left alone, and the MASK ACE | is intersected with the group permission bits of the creat parameter. | The std group permissions bits on the file, however, are updated | accordingly. | If you did an "ls -l" on the file, then you would see that the | group permission bits match the MASK ACE permission bits (see 23.1.2) | that you see with "chacl -l". | (If there was no MASK ACE then the GROUP_OBJ ACE would be intersected | with the group permissions as expected). | | I hope I haven't confused you. | The standard can be equally confusing ;-) | | The withdrawn Posix ACL standard can be downloaded at: | http://wt.xpilot.org/posix.1e/download.html | | Andreas Gruenbacher's site has some useful info: | http://acl.bestbits.at > > I also want an easy way for it all to be inherited - as well as only > "directories" would be +x, where normal files wouldn't need the > executable bit set > > Are there any other utilities other than chacl for managing the ACLs? Nathan Scott will soon check in ported versions of Andreas' setfacl and getfacl ACL commands. (Currently, you'll need to preserve an ACE ordering in ACL specification for setfacl; however, I'll look into fixing this problem when the code is checked in). --Tim From owner-linux-xfs@oss.sgi.com Thu Aug 2 20:53:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f733rtv09516 for linux-xfs-outgoing; Thu, 2 Aug 2001 20:53:55 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f733rrV09497 for ; Thu, 2 Aug 2001 20:53:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id FAA549264 for ; Fri, 3 Aug 2001 05:53:34 +0200 (CEST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA14104; Fri, 3 Aug 2001 13:52:27 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: FIX: World-writeable files repair script In-reply-to: Your message of "Thu, 02 Aug 2001 21:45:52 EST." <3B6A1060.D895B2F6@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Aug 2001 13:52:27 +1000 Message-ID: <14982.996810747@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 02 Aug 2001 21:45:52 -0500, Eric Sandeen wrote: >Keith Owens wrote: > >> Add /lib/modules/*/modules.dep. If that file is world writable you >> have a local root exploit. Due to the kernel bug, this has occurred on >> Slackware installs. As part of that exploit, people reported that >> /var/log/wtmp and /var/run/utmp are also created with the wrong mask. >> Not exploitable AFAIK but you can hide tasks if utmp is world writable. > >modules.dep comes from the Red Hat kernel RPMs, and it doesn't appear to >be re-generated or modified during the install, so I think we're fine >here. Yes and no. If a user builds their own kernel and does not run depmod before rebooting and the kernel has the umask bug and the init scripts do not set umask then modules.dep is created with the wrong mode. Unfortunately some users managed to meet all the requirements :( The problem particularly affects cross compiles because depmod does not run in cross compile mode. From owner-linux-xfs@oss.sgi.com Thu Aug 2 22:45:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f735jct24094 for linux-xfs-outgoing; Thu, 2 Aug 2001 22:45:38 -0700 Received: from firsmail.shanshan.com.cn ([202.96.104.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f735jUV24037; Thu, 2 Aug 2001 22:45:31 -0700 Date: Thu, 2 Aug 2001 22:45:31 -0700 Message-Id: <200108030545.f735jUV24037@oss.sgi.com> Received: from all-life.com by firsmail.shanshan.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id QBNWVQ9Y; Fri, 3 Aug 2001 12:36:46 +0800 From: "toddra@4news.com" To: "4813@another.com" <4813@another.com> Subject: Get the word out about your business. Content-Type: text/plain; charset="us-ascii";format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Triple Your Business in 60 Days or Less !! Generate traffic to your website by the thousands!!! Have complete control on who receives your ad. Get thousands of Targeted visitors!!! Why it Works. Because you can deliver your message to millions of people for a fraction of the cost of conventional advertising. That's right it's less than a classified ad that would only reach a fraction of the audience. What we offer you. A complete turn-key operation for you. * Total Control- We can expose your product to hundreds of millions of people of your choosing. * Full Marketing Team - Our marketing team will help you create an effective marketing piece for your campaign . * FREE use of software - we will provide you with state of the art software specifcally designed to contact all the prospects you need. * 100% customer service and tech support - Your success is our success !! EASY As 1...2...3... It's easy to get started simply reply today and we will set you up with this fantastic system, specifically designed for "Your success on The Net" Call 702-252-4626 To Unsubscribe to this email list, please go to delete@eurosport.com and type "ELIMINATE" in the subject line. Thank you. From owner-linux-xfs@oss.sgi.com Thu Aug 2 23:02:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7362DX26975 for linux-xfs-outgoing; Thu, 2 Aug 2001 23:02:13 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7362AV26949 for ; Thu, 2 Aug 2001 23:02:10 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA10904; Fri, 3 Aug 2001 08:02:08 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA21663; Fri, 3 Aug 2001 08:02:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id CAA7157306; Fri, 3 Aug 2001 08:01:33 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 3A42B25835; Fri, 3 Aug 2001 08:01:33 +0200 (CEST) Message-ID: <3B6A3E3C.48DADE1A@ch.sauter-bc.com> Date: Fri, 03 Aug 2001 08:01:33 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Seth Mos Cc: yocum@fnal.gov, xfs-list Subject: Re: XFS fs size limit? References: <200108021734.f72HYDo07108@jen.americas.sgi.com> <4.3.2.7.2.20010802224302.03e82e68@pop.xs4all.nl> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos schrieb: > > At 13:05 2-8-2001 -0500, yocum@fnal.gov wrote: > >Steve, > > > >I assume you mean software RAID5, right? I've got a RAID50 array: 2 8-port > >3ware cards in hw raid5, then those two devices combined software raid0. I > >didn't bother to make the log on a separate device, but I could, if need be. > > That is silly. Just make a big raid0 of it. If for some reason one of the > 3ware cards takes a dump you WILL LOSE ALL YOUR DATA. I have seen this > mistake (if it is) before at www.tweakers.net where they configured the 4 > disk into a raid 01 instead of 10. If you want redundancy make a raid0 on > the 3ware disk and a raid1 of these 2 3ware cards. I don't agree with this. Or maybe I do. If a 3ware card fails then the raid0 over both cards will not start up and no changes are made to any of the two raid5 volumes. When replacing a dead 3ware card it should be able to run the existing disks and your raid0 will be okay with no data lost. If the RAID controller can not import an existing array, then you have lost your data (and should dump the controller to /dev/null). -Simon > > That is make 2 raid1 devices and then a raid0. If something happens to > either one of the raid1 array logical devices (not disk but software > failure) everything will be lost. Which was exactly what happend. They raid > controller (Ami megaraid) got upset after one disk died and they lost there > complete Mysql Database. > > > > this kernel revision is to use an external log device with raid5. You > > > must also make sure to use an inode size larger than the default with > > > a filesystem this big (mkfs ... -i size=512 ...). Without getting to > > > technical, this will stop your inode numbers from overflowing 32 bits. > > > > > > > > > > > Now there's rumors on l-k that the FS size might be limited by the > > > > signedness of something in the block layer, effectively limiting us > > to 1TB. > > > > > > We appear to have people working successfully beyond the 1Tbyte boundary, > > > the 1Tb limit may be specific to some device drivers which are not as > > > cleanly coded. > > > > > >I haven't been terribly happy with the 3ware drivers/cards in general, so > >we'll see. FWIW, I tried upgrading to their latest driver on an smp system > >and simply insmod-ing the newly compiled driver tickles the NMI watchdog > >which dumps me directly into kdb. Fun stuff. :-/ > > Which is exactly the reason to avoid the above mentioned configuration. If > one card dies you have just lost all your data. > > 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 Aug 3 00:21:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f737LWK29573 for linux-xfs-outgoing; Fri, 3 Aug 2001 00:21:32 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f737LTV29554 for ; Fri, 3 Aug 2001 00:21:29 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA03986 for ; Fri, 3 Aug 2001 00:21:13 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA22680 for linux-xfs@oss.sgi.com; Fri, 3 Aug 2001 17:20:09 +1000 (EST) Date: Fri, 3 Aug 2001 17:20:09 +1000 (EST) From: Nathan Scott Message-Id: <200108030720.RAA22680@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - correct FIBMAP handling of holes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Aug 3 00:18:53 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100127a linux/fs/xfs/linux/xfs_iops.c - 1.111 - For offsets within the hole of a holey file, VOP_BMAP will give bmap block numbers of -1. We were charging on and using this value in calculations which assumed a valid, positive block number. From owner-linux-xfs@oss.sgi.com Fri Aug 3 00:21:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f737Lv029660 for linux-xfs-outgoing; Fri, 3 Aug 2001 00:21:57 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f737LsV29638 for ; Fri, 3 Aug 2001 00:21:55 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id JAA566204 for ; Fri, 3 Aug 2001 09:21:36 +0200 (CEST) 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 RAA15211; Fri, 3 Aug 2001 17:20:27 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA48683; Fri, 3 Aug 2001 17:20:26 +1000 (AEST) Date: Fri, 3 Aug 2001 17:20:26 +1000 From: Nathan Scott To: utz lehmann Cc: "Gonyou, Austin" , linux-xfs@oss.sgi.com Subject: Re: Strage values from FIBMAP on holes or after end of file Message-ID: <20010803172026.A197783@wobbly.melbourne.sgi.com> References: <85063BBE668FD411944400D0B744267A6435E7@AUSMAIL> <20010803005541.A4343@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010803005541.A4343@s2y4n2c.de>; from xfs@s2y4n2c.de on Fri, Aug 03, 2001 at 12:55:41AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Utz, On Fri, Aug 03, 2001 at 12:55:41AM +0200, utz lehmann wrote: > ... > but i think the FIBMAP ioctl should return 0 as blocknumber for holes and > after the end of the file. > > > > Hi > > > > > > The FIBMAP ioctl on holes or after end of file gives the > > > values -1 to 6. > > > ext2 and reiserfs reurns 0. I thing this is the right value. > I have just checked in a fix, should appear in cvs shortly. Thanks for the detailed analysis & test program. Did you just discover this problem by inspection, or did it bite you in some other way? (was some other program using the FIBMAP ioctl and not working correctly with XFS?) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Aug 3 04:01:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73B10g07266 for linux-xfs-outgoing; Fri, 3 Aug 2001 04:01:00 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73B0tV07243 for ; Fri, 3 Aug 2001 04:00:56 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f73AhZ928921; Fri, 3 Aug 2001 12:43:35 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdsn7sNJ; Fri Aug 3 12:43:29 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f73AxN405350; Fri, 3 Aug 2001 12:59:23 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f73AxNB01597; Fri, 3 Aug 2001 12:59:23 +0200 Date: Fri, 3 Aug 2001 12:59:23 +0200 From: Utz Lehmann To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: Strage values from FIBMAP on holes or after end of file Message-ID: <20010803125923.A1227@de.tecosim.com> References: <85063BBE668FD411944400D0B744267A6435E7@AUSMAIL> <20010803005541.A4343@s2y4n2c.de> <20010803172026.A197783@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: <20010803172026.A197783@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Fri, Aug 03, 2001 at 05:20:26PM +1000 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Nathan Nathan Scott [nathans@sgi.com] wrote: > > > > The FIBMAP ioctl on holes or after end of file gives the > > > > values -1 to 6. > > > > ext2 and reiserfs reurns 0. I thing this is the right value. > > > > I have just checked in a fix, should appear in cvs shortly. > Thanks for the detailed analysis & test program. The fix works. Thanks. > > Did you just discover this problem by inspection, or did it > bite you in some other way? (was some other program using > the FIBMAP ioctl and not working correctly with XFS?) I found this with the fibmap program of Constantin Loizides fragmentation project. http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ Note: The current version of fibmap doesn't work with XFS well. I thing Constantin will release a fixed version soon. utz From owner-linux-xfs@oss.sgi.com Fri Aug 3 04:23:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73BNv807920 for linux-xfs-outgoing; Fri, 3 Aug 2001 04:23:57 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73BNtV07901 for ; Fri, 3 Aug 2001 04:23:55 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id EAA06631 for ; Fri, 3 Aug 2001 04:21:44 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA2613064; Fri, 3 Aug 2001 06:22:38 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA25604; Fri, 3 Aug 2001 06:22:38 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f73BN3I09027; Fri, 3 Aug 2001 06:23:03 -0500 Message-Id: <200108031123.f73BN3I09027@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Thomax cc: linux-xfs@oss.sgi.com Subject: Re: pagebuf in kernel causes abnormal behavior In-Reply-To: Message from Thomax of "Fri, 03 Aug 2001 03:50:05 BST." <3B6A115D.F921045F@b.lab.net> Date: Fri, 03 Aug 2001 06:23:03 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > ok. i tried it very hard. You will have to send us a pointer to the test program if we are to be able to do anything about this. If you are not using XFS then the pagebuf code is never called, in fact if you are using one of the released rpm based kernels then it is not even loaded into the kernel. Also you said you used the cvs tree, can you tell me which kernel level you tried. Thanks Steve > > i installed XFS1.0 and XFS1.0.1 (CVS) and the system hangs/reboots > in a file system stress tests (fs-bench). no metter if i stress > test the xfs or the ext2, in the file creation part the system dies. > i tried without pagebuf and xfs and everything work (only ext2 test, > of cause). but if i just include pagebuf or pagebuf and > xfs the system dies. > > brief hardwareprofile: > 2 x Pentium III (Coppermine) 930.434MHz > 768MB RAM > Tyan Thunder LE, S2510U3NG > 36GB IBM Model: DDYS-T36950N Rev: S93E > with onboard symbios x1010 U160 SCSI > > no more further details, because i do this all remote. so, no oops > or dumps. > > hope you will fix it soon. i'm out if there is no hint how to solve > it. > > thanks for your work anyway. all the rest worked well. i like to > have xfs on linux and so on. > > thomax From owner-linux-xfs@oss.sgi.com Fri Aug 3 04:57:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73BvIq08567 for linux-xfs-outgoing; Fri, 3 Aug 2001 04:57:18 -0700 Received: from mail.isg.de (foobar.isg.de [62.96.243.63]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73BvGV08546 for ; Fri, 3 Aug 2001 04:57:16 -0700 Received: from isg.de (wall2-outer.isg.de [62.96.243.126]) by mail.isg.de (Postfix) with ESMTP id 848F47548D7; Fri, 3 Aug 2001 13:57:12 +0200 (CEST) Message-ID: <3B6A9194.6C5B908F@isg.de> Date: Fri, 03 Aug 2001 13:57:08 +0200 From: Constantin Loizides Organization: Innovative Software AG X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Utz Lehmann Cc: xfs-list Subject: Re: Strage values from FIBMAP on holes or after end of file References: <85063BBE668FD411944400D0B744267A6435E7@AUSMAIL> <20010803005541.A4343@s2y4n2c.de> <20010803172026.A197783@wobbly.melbourne.sgi.com> <20010803125923.A1227@de.tecosim.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, thanx to Utz, I have rewritten the fibmap tool. You find it at http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/  >[...] > > Did you just discover this problem by inspection, or did it > > bite you in some other way? (was some other program using > > the FIBMAP ioctl and not working correctly with XFS?) > > I found this with the fibmap program of Constantin Loizides fragmentation > project. http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ > Note: The current version of fibmap doesn't work with XFS well. I thing > Constantin will release a fixed version soon. > Should work now on xfs, too. Also did some minor changes. Utz, could you test it on your patched system, please? (I still test for minus and zwro values for holes though...) Constantin From owner-linux-xfs@oss.sgi.com Fri Aug 3 05:09:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73C9wb08886 for linux-xfs-outgoing; Fri, 3 Aug 2001 05:09:58 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73C9rV08866 for ; Fri, 3 Aug 2001 05:09:54 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 2BB29C08365 for ; Fri, 3 Aug 2001 20:09:45 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id B3B4DC000B7 for ; Fri, 3 Aug 2001 20:09:43 +0800 (PHT) Date: Fri, 3 Aug 2001 20:09:43 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: Strage values from FIBMAP on holes or after end of file In-Reply-To: <3B6A9194.6C5B908F@isg.de> 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, 3 Aug 2001 at 13:57, Constantin Loizides wrote: > thanx to Utz, I have rewritten the fibmap tool. You find it at > http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ With the just checked-in fix for the FIBMAP issues, I wonder if you will get better performance for XFS using the latest CVS copy. Also, Alan Cox has just released ac4 which contains a lot of ReiserFS fixes. While I know it will be very difficult to have an XFS-patched ac kernel, you may be able to have two separate kernels that have otherwise similar configurations (save for ReiserFS and XFS support)? This will allow you to test the latest kernels with support for both filesystems. Just a thought. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Fri Aug 3 06:39:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73Ddgd09937 for linux-xfs-outgoing; Fri, 3 Aug 2001 06:39:42 -0700 Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73DdeV09917 for ; Fri, 3 Aug 2001 06:39:40 -0700 Received: by giants.mandrakesoft.com (Postfix, from userid 500) id 249B4C101; Fri, 3 Aug 2001 15:39:51 +0200 (CEST) To: Seth Mos Cc: Russell Cattelan , Knut J Bjuland , linux-xfs@oss.sgi.com Subject: Re: redhat linux 7.2 beta roswel. References: <3B69F041.90696624@online.no> <4.3.2.7.2.20010802225356.03e88a78@pop.xs4all.nl> From: Chmouel Boudjnah Date: 03 Aug 2001 15:39:51 +0200 In-Reply-To: <4.3.2.7.2.20010802225356.03e88a78@pop.xs4all.nl> (Seth Mos's message of "Thu, 02 Aug 2001 22:57:08 +0200") Message-ID: Lines: 6 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.104 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos writes: > Are there some Mandrake people monitoring the list? > I have seen one of the developers post to the list before. yes, i do i was just for a month vacation.... From owner-linux-xfs@oss.sgi.com Fri Aug 3 06:54:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73Dsit10374 for linux-xfs-outgoing; Fri, 3 Aug 2001 06:54:44 -0700 Received: from WWW.LKT.Uni-Erlangen.DE (www.lkt.uni-erlangen.de [131.188.28.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73DsfV10353 for ; Fri, 3 Aug 2001 06:54:41 -0700 Received: from abach.lkt.uni-erlangen.de (abach) [131.188.118.77] by WWW.LKT.Uni-Erlangen.DE with smtp (Exim 3.12 #1 (Debian)) id 15SfPK-0000tt-00; Fri, 03 Aug 2001 15:54:30 +0200 From: "Andreas Abach" To: "linux-xfs@oss.sgi.com" Date: Fri, 03 Aug 2001 15:55:10 +0200 Reply-To: "Andreas Abach" X-Mailer: PMMail 2000 Professional (2.10.2000) 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: xfs_force_shutdown with linux-2.4.6-xfs-07052001? Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 3 Aug 2001 00:02:27 +0200 (CEST), Seth Mos wrote: >On Thu, 2 Aug 2001, KELEMEN Peter wrote: > >> * Seth Mos (knuffie@xs4all.nl) [20010801 09:46]: >> >> > That is probably caused by an IO error. I see you are using lvm >> > which could be related. If an IO error occurs the filesystem >> > will shutdown to prevent more damage. >> >> Well. I checked the hard drive (read-only) in another machine, it >> reports no errors. S.M.A.R.T. is happy, no relocated sectors or >> raw read, seek or CRC errors. Nothing. > >That counters the hardware site. No, I don't believe this. I think it's an xfs problem. I've got similar problems. I copy about 120 GB of files to an xfs filesystem and get errors. When I change the filesystem type from xfs to ext2 on errors occur during copying. Andreas System: Debian/GNU Linux (unstable) on a PC equipped with a Pentium III-450 (Katmai), 192 M of RAM, and a RAID (easyRAID II) with 165 GB hooked to an Adaptec AIC-7881U SCSI host adapter. The kernel I'm using is 2.4.6 with XFS patch "linux-2.4.6-xfs-07052001" applied. Soon after I've written some gigs of data I'm seeing the following in /var/log/messages: Jul 31 14:06:43 server kernel: xfs_force_shutdown(sd(8,5),0x1) called from line 1013 of file xfs_trans.c. Return address = 0xcc8e71b3 Jul 31 14:06:43 server kernel: I/O Error Detected. Shutting down filesystem: sd (8,5) Jul 31 14:06:43 server kernel: Please umount the filesystem, and rectify the problem(s) > >> > This error could be on the device (bad cluster on the disk) or >> > something in a software layer like md or lvm going wrong which >> > is seen by XFS as a hardware error. What is actually the lvm >> > device. Do you use md or any other software that might >> > interfere? IDE or scsi and what controller and system. How is >> > the lvm device constructed. >> >> EIDE, no UDMA. No MD at all, LVM is pretty straightforward, a >> lonely 20G disk sliced into two, sitting in an extended partition. >> A big partition is actually the only PV, carrying a VG with six >> LVs. No magic, this is supposed to be a workstation. Kernel is >> tracked CVS, compiled with egcs-1.1.2. No overclock. > >That indeed seems very simple. The problem is that it is hard to debug >since it will probably be extrmely hard to replicate. If you can find a >way to reproduce this, let us know please. We'd love to squash XFS related >bugs ;-) > >I have absolutely zipp experience with LVM so I can't comment on any >problems on that front. > >> The thing hasn't happened since (knock on wood). > >Good luck then, you will need it for the next knock on wood. > >Cheers > > From owner-linux-xfs@oss.sgi.com Fri Aug 3 07:17:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73EHIX10947 for linux-xfs-outgoing; Fri, 3 Aug 2001 07:17:18 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73EHGV10928 for ; Fri, 3 Aug 2001 07:17:16 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 8872E1AB13 for ; Fri, 3 Aug 2001 10:17:15 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 945F16DF; Fri, 3 Aug 2001 10:17:14 -0400 (EDT) Date: Fri, 3 Aug 2001 10:17:14 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: fh_verify: permission failure (?) Message-ID: <20010803101714.A11323@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been getting a lot of these... fh_verify: dbench/NBSIMULD permission failure, acc=44, error=13 ...in my system logs lately. What do they mean? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Aug 3 07:27:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73ERBd11249 for linux-xfs-outgoing; Fri, 3 Aug 2001 07:27:11 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73ER8V11230 for ; Fri, 3 Aug 2001 07:27:09 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id QAA17290; Fri, 3 Aug 2001 16:27:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id QAA29807; Fri, 3 Aug 2001 16:27:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id DC32057306; Fri, 3 Aug 2001 16:26:21 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 6A15225835; Fri, 3 Aug 2001 16:26:18 +0200 (CEST) Message-ID: <3B6AB48A.DD4A4CBC@ch.sauter-bc.com> Date: Fri, 03 Aug 2001 16:26:18 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: fh_verify: permission failure (?) References: <20010803101714.A11323@dkp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Klaassen schrieb: > > I've been getting a lot of these... > > fh_verify: dbench/NBSIMULD permission failure, acc=44, error=13 It means you tried to access a file via NFS without having permission. -Simon > > ...in my system logs lately. > > What do they mean? > > Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Aug 3 07:32:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73EWbV11490 for linux-xfs-outgoing; Fri, 3 Aug 2001 07:32:37 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73EWaV11471 for ; Fri, 3 Aug 2001 07:32:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA03812 for ; Fri, 3 Aug 2001 07:32:23 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2614765; Fri, 3 Aug 2001 09:31:19 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA18560; Fri, 3 Aug 2001 09:31:19 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f73EVgF09948; Fri, 3 Aug 2001 09:31:43 -0500 Message-Id: <200108031431.f73EVgF09948@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: fh_verify: permission failure (?) In-Reply-To: Message from Andrew Klaassen of "Fri, 03 Aug 2001 10:17:14 EDT." <20010803101714.A11323@dkp.com> Date: Fri, 03 Aug 2001 09:31:42 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I've been getting a lot of these... > > fh_verify: dbench/NBSIMULD permission failure, acc=44, error=13 > > ...in my system logs lately. > > What do they mean? > > Andrew Klaassen These are NFS permissions failures from the NFS server, basically the client has attempted to access a file it cannot, what type of NFS clients do you have? Steve From owner-linux-xfs@oss.sgi.com Fri Aug 3 07:38:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73EcXI11665 for linux-xfs-outgoing; Fri, 3 Aug 2001 07:38:33 -0700 Received: from dermis.amis.com (dermis.amis.com [207.141.5.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73EcVV11646 for ; Fri, 3 Aug 2001 07:38:31 -0700 Received: from [172.16.89.23] by dermis.amis.com via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 3 Aug 2001 14:38:27 UT Received: from amis.com ([172.16.17.176]) by mx1.pc.amis.com (Lotus Domino Release 5.0.8) with ESMTP id 2001080308375377:460 ; Fri, 3 Aug 2001 08:37:53 -0600 Message-ID: <3B6AB761.A22361C6@amis.com> Date: Fri, 03 Aug 2001 08:38:25 -0600 From: Eric Whiting X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Klaassen CC: linux-xfs@oss.sgi.com Subject: Re: fh_verify: permission failure (?) References: <20010803101714.A11323@dkp.com> X-MIMETrack: Itemize by SMTP Server on mx1/amis(Release 5.0.8 |June 18, 2001) at 08/03/2001 08:37:53 AM, Serialize by Router on mx1/amis(Release 5.0.8 |June 18, 2001) at 08/03/2001 08:37:57 AM, Serialize complete at 08/03/2001 08:37:57 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are you running NFS? This is a message that NFSD reports when there are unix permission problems. eric Andrew Klaassen wrote: > > I've been getting a lot of these... > > fh_verify: dbench/NBSIMULD permission failure, acc=44, error=13 > > ...in my system logs lately. > > What do they mean? > > Andrew Klaassen -- __________________________________________________________________ Eric T. Whiting AMI Semiconductors From owner-linux-xfs@oss.sgi.com Fri Aug 3 07:52:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73Eqqi12053 for linux-xfs-outgoing; Fri, 3 Aug 2001 07:52:52 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73EqlV12033 for ; Fri, 3 Aug 2001 07:52:48 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA568567 for ; Fri, 3 Aug 2001 16:52:30 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2615243; Fri, 3 Aug 2001 09:51:27 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA18966; Fri, 3 Aug 2001 09:51:27 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f73EpoW09999; Fri, 3 Aug 2001 09:51:50 -0500 Message-Id: <200108031451.f73EpoW09999@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Andreas Abach" cc: "linux-xfs@oss.sgi.com" Subject: Re: xfs_force_shutdown with linux-2.4.6-xfs-07052001? In-Reply-To: Message from "Andreas Abach" of "Fri, 03 Aug 2001 15:55:10 +0200." Date: Fri, 03 Aug 2001 09:51:50 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > No, I don't believe this. I think it's an xfs problem. I've got similar probl > ems. > I copy about 120 GB of files to an xfs filesystem and get errors. When I chan > ge the filesystem type from xfs to ext2 on errors occur during copying. Can someone who is seeing this type of error please do the following: 1. Edit the function _xfs_force_shutdown() in fs/xfs/xfs_rw.c and add a call to BUG() at line 126. 2. Build a kernel with kdb enabled 3. when you hit the shutdown it will drop into the debugger, use the bt command to produce a stack trace and send us the output. There are about 18 calls to xfs_force_shutdown in the filesystem, they occur for a variety of reasons, some of which are I/O errors reported from the block layer, some of which are due to consistency check failures on metadata. If we get an I/O error reported then it probably really is one, if we get one of the other errors then it is possible it is a Linux bug, maybe in the endian conversion code. In Andreas case the shutdown happened because we attempted to cancel a transaction after it had been started and we had already dirtied metadata. In XFS this does not happen in normal operation, it only happens due to some other failure. In order to make progress I need to see more of what was going on, hence the request for help. Steve > > Andreas > > System: > Debian/GNU Linux (unstable) on a PC equipped with a Pentium III-450 > (Katmai), 192 M of RAM, and a RAID (easyRAID II) with 165 GB hooked to an > Adaptec AIC-7881U SCSI host adapter. The kernel I'm using is 2.4.6 with XFS > patch "linux-2.4.6-xfs-07052001" applied. > > Soon after I've written some gigs of data I'm seeing the following in > /var/log/messages: > > Jul 31 14:06:43 server kernel: xfs_force_shutdown(sd(8,5),0x1) called from li > ne > 1013 of file xfs_trans.c. Return address = 0xcc8e71b3 > Jul 31 14:06:43 server kernel: I/O Error Detected. Shutting down filesystem: > sd > (8,5) > Jul 31 14:06:43 server kernel: Please umount the filesystem, and rectify the > problem(s) > > > >> > This error could be on the device (bad cluster on the disk) or > >> > something in a software layer like md or lvm going wrong which > >> > is seen by XFS as a hardware error. What is actually the lvm > >> > device. Do you use md or any other software that might > >> > interfere? IDE or scsi and what controller and system. How is > >> > the lvm device constructed. > >> > >> EIDE, no UDMA. No MD at all, LVM is pretty straightforward, a > >> lonely 20G disk sliced into two, sitting in an extended partition. > >> A big partition is actually the only PV, carrying a VG with six > >> LVs. No magic, this is supposed to be a workstation. Kernel is > >> tracked CVS, compiled with egcs-1.1.2. No overclock. > > > >That indeed seems very simple. The problem is that it is hard to debug > >since it will probably be extrmely hard to replicate. If you can find a > >way to reproduce this, let us know please. We'd love to squash XFS related > >bugs ;-) > > > >I have absolutely zipp experience with LVM so I can't comment on any > >problems on that front. > > > >> The thing hasn't happened since (knock on wood). > > > >Good luck then, you will need it for the next knock on wood. > > > >Cheers > > > > > > From owner-linux-xfs@oss.sgi.com Fri Aug 3 07:57:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73Ev5k12203 for linux-xfs-outgoing; Fri, 3 Aug 2001 07:57:05 -0700 Received: from email2.wsicorp.com (email2.wsicorp.com [198.115.158.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73Ev2V12184 for ; Fri, 3 Aug 2001 07:57:03 -0700 Received: from wsicorp.com (atherne.wsicorp.com [147.81.84.101]) by email2.wsicorp.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PADWDWPV; Fri, 3 Aug 2001 10:56:23 -0400 Message-ID: <3B6ABC65.9050703@wsicorp.com> Date: Fri, 03 Aug 2001 10:59:49 -0400 From: Darrell Michaud Organization: WSI User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: fh_verify: permission failure (?) References: <200108031431.f73EVgF09948@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I see this same problem with our test XFS / NFS server. We're testing this setup: SMP Linux kernel 2.4.6pre5-xfs (from CVS), compiled with kgcc XFS volume on a software RAID 0 across two IBM 7200 75GB IDE disks shared via NFS NFS (mostly v2, some v3) Clients using Irix 6.5.9m on SGI O2's. We've seeing strange NFS behavior to any writeable exports. All clients can successfully mount the export filesystem and read from it. Not all clients can write to it, however, even though they all have identical access. Some clients get a "access denied: read only filesystem" message when they try to touch new files or make new directies. They get this message repeatedly. Sometimes unmounting the nfs share and reloading the server's nfsd fixes this problem, but not always. Different clients have this problem on different days. It's quite annoying. I was going to try either a different kernel version, or a simple scsi disk share (no software raid), and hope for better luck. There is another NFS server in house that uses a 2.2.19 Linux kernel and ext2, and it does not have this problem with the same clients. Steve Lord wrote: >>I've been getting a lot of these... >> >>fh_verify: dbench/NBSIMULD permission failure, acc=44, error=13 >> >>...in my system logs lately. >> >>What do they mean? >> >>Andrew Klaassen >> > > These are NFS permissions failures from the NFS server, basically the > client has attempted to access a file it cannot, what type of NFS clients > do you have? > > Steve > > > From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:05:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73F56M12429 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:05:06 -0700 Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73F53V12410 for ; Fri, 3 Aug 2001 08:05:03 -0700 Received: from [192.168.1.17] (router.vexcel.com [192.92.90.254]) by biobio.vexcel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA02051 for ; Fri, 3 Aug 2001 09:05:00 -0600 (MDT) Mime-Version: 1.0 X-Sender: brissing@mail.vexcel.com (Unverified) Message-Id: In-Reply-To: <14982.996810747@kao2.melbourne.sgi.com> References: <14982.996810747@kao2.melbourne.sgi.com> Date: Fri, 3 Aug 2001 09:04:07 -0600 To: linux-xfs@oss.sgi.com From: Dean Brissinger Subject: Re: FIX: World-writeable files repair script Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 1:52 PM +1000 8/3/01, Keith Owens wrote: >On Thu, 02 Aug 2001 21:45:52 -0500, >Eric Sandeen wrote: >>Keith Owens wrote: >> >>> Add /lib/modules/*/modules.dep. If that file is world writable you >>> have a local root exploit. Due to the kernel bug, this has occurred on >>> Slackware installs. As part of that exploit, people reported that >>> /var/log/wtmp and /var/run/utmp are also created with the wrong mask. >>> Not exploitable AFAIK but you can hide tasks if utmp is world writable. >> >>modules.dep comes from the Red Hat kernel RPMs, and it doesn't appear to >>be re-generated or modified during the install, so I think we're fine >>here. > >Yes and no. If a user builds their own kernel and does not run depmod >before rebooting and the kernel has the umask bug and the init scripts >do not set umask then modules.dep is created with the wrong mode. >Unfortunately some users managed to meet all the requirements :( The >problem particularly affects cross compiles because depmod does not run >in cross compile mode. Is it safe to run the 2.4.3 kernel in general? -- . . . . . . . . ooo . . . . ooo . . . . . . . . . . . . Dean Brissinger - Systems Administrator . . Direct: 303-583-0278 Main: 303-444-0094 . . Fax: 303-583-0246 http://www.vexcel.com/ . . . . . . . . . . oOOo . . A . . oOOo . . . . . . . . 0 0 '```` From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:15:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73FFui12690 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:15:56 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FFsV12671 for ; Fri, 3 Aug 2001 08:15:54 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f73FEmn23511; Fri, 3 Aug 2001 11:14:48 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Fri, 3 Aug 2001 11:14:47 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Darrell Michaud cc: Steve Lord , Subject: Re: fh_verify: permission failure (?) In-Reply-To: <3B6ABC65.9050703@wsicorp.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, 3 Aug 2001 at 10:59am, Darrell Michaud wrote > I see this same problem with our test XFS / NFS server. > And I see the same problem on two stock RH-7.1 (i.e. non XFS) NFS servers with Linux and IRIX clients. I have heard no complaints (well, about this anyway) from the users, though, so I haven't looked into fixing it. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:18:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73FIf712829 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:18:41 -0700 Received: from merlin.giref.ulaval.ca (postfix@merlin.giref.ulaval.ca [132.203.7.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FIeV12810 for ; Fri, 3 Aug 2001 08:18:40 -0700 Received: from roederer.giref.ulaval.ca (roederer.giref.ulaval.ca [132.203.7.24]) by merlin.giref.ulaval.ca (Postfix) with ESMTP id 09F20F374; Fri, 3 Aug 2001 11:18:32 -0400 (EDT) Date: Fri, 3 Aug 2001 11:18:32 -0400 (EDT) From: Luc Lalonde To: Joshua Baker-LePain Cc: Darrell Michaud , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: fh_verify: permission failure (?) 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 noticed these type of errors when I switched from NFSV2 to NFSV3. I searched for info and the general consensus was to ignore these messages. It's not giving me any problems to date. Ciao. On Fri, 3 Aug 2001, Joshua Baker-LePain wrote: > On Fri, 3 Aug 2001 at 10:59am, Darrell Michaud wrote > > > I see this same problem with our test XFS / NFS server. > > > And I see the same problem on two stock RH-7.1 (i.e. non XFS) NFS servers > with Linux and IRIX clients. I have heard no complaints (well, about this > anyway) from the users, though, so I haven't looked into fixing it. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University > > From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:20:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73FKu912954 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:20:56 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FKsV12935 for ; Fri, 3 Aug 2001 08:20:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA01504 for ; Fri, 3 Aug 2001 08:20:38 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2614170; Fri, 3 Aug 2001 10:19:37 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA84626; Fri, 3 Aug 2001 10:19:36 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f73FK0w10141; Fri, 3 Aug 2001 10:20:00 -0500 Message-Id: <200108031520.f73FK0w10141@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Joshua Baker-LePain cc: Darrell Michaud , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: fh_verify: permission failure (?) In-Reply-To: Message from Joshua Baker-LePain of "Fri, 03 Aug 2001 11:14:47 EDT." Date: Fri, 03 Aug 2001 10:20:00 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, 3 Aug 2001 at 10:59am, Darrell Michaud wrote > > > I see this same problem with our test XFS / NFS server. > > > And I see the same problem on two stock RH-7.1 (i.e. non XFS) NFS servers > with Linux and IRIX clients. I have heard no complaints (well, about this > anyway) from the users, though, so I haven't looked into fixing it. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University Define 'problem' here, the code is basically a debug printf which says that an nfs client attempted to access a file it did not have permission to access and is being rejected. If a user who really does have access to a file is rejected by this code then there is a real problem, otherwise it is just the kernel being chatty. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:25:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73FPMj13101 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:25:22 -0700 Received: from frodo.ezprohosting.com ([216.74.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FPJV13081 for ; Fri, 3 Aug 2001 08:25:19 -0700 Received: from c922720-a.sttln1.wa.home.com ([65.0.77.21] helo=windows) by frodo.ezprohosting.com with smtp (Exim 3.20 #1) id 15SgoI-0006o8-00; Fri, 03 Aug 2001 11:24:22 -0400 Message-ID: <002f01c11c2f$eb447f60$020144c0@windows> From: "Eric Peters" To: "Timothy Shimmin" Cc: References: <00ce01c11ba2$bcb5af80$020144c0@windows> <20010803135130.H62222@boing.melbourne.sgi.com> Subject: Re: default ACL? Date: Fri, 3 Aug 2001 08:21:04 -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 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - frodo.ezprohosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - peters.org Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, I think I understand the group (ORing? of the UMask and the ACL Mask) - the ACL Mask would have to be set rwx so that the u::rwx is possible right? The ACL Mask isn't *just* for group am I correct? The other "concern" I have is the "mangling" when creating files as well as directories - under this setup so long as I have a u::rwx (and hence need a m:rwx), all files that would get created would have a rwx (and now be "executables!") but I notice the mkdir's take on the same permissions as the "default file" mask I set up with the chacl -b is that right or is there two different default permissions? one for directories, one for files? I really do appreciate your time, Eric ----- Original Message ----- From: "Timothy Shimmin" To: "Eric Peters" Cc: Sent: Thursday, August 02, 2001 8:51 PM Subject: Re: default ACL? > Hi Eric: > > On Thu, Aug 02, 2001 at 03:30:27PM -0700, Eric Peters wrote: > > I'm basically just trying to be able and delegate a group of users rw > > permission for a directory /www and all sub directories (or there would > > be 5 global accounts and a couple accounts could only access certain > > sub directories / etc) > > > > The mask has me fairly confused I must say, in that despite having > > g::r-x:m::rwx, the directory has g+rwx > > Yeah I find it weird myself. > But it seems to be part of the standard. > I emailed about this on June 12 to Sebastian Dransfeld. > Below is what I wrote to Sebastian about the application of a directory > default ACL when a file is created inside the directory: > | When the access ACL for a file of a directory with a default ACL > | is created, it's ACE permissions are set by _intersection_ of the > | respective default ACEs permission bits and the mode bits of the > | parameter to open/creat. > | > | So if the creat mode bits don't have the execute (x) bit set for user > | and other (which will depend on the application you use which makes the > | create/open call), then nor will the USER_OBJ ACEs and OTHER ACEs. > | Which is what you (Sebastian) saw. > | The GROUP_OBJ ACE is treated differently if a MASK ACE exists, as > | is the case in your example above. If we have a MASK ACE (see 5.3.1.2), > | then the GROUP_OBJ ACE is left alone, and the MASK ACE > | is intersected with the group permission bits of the creat parameter. > | The std group permissions bits on the file, however, are updated > | accordingly. > | If you did an "ls -l" on the file, then you would see that the > | group permission bits match the MASK ACE permission bits (see 23.1.2) > | that you see with "chacl -l". > | (If there was no MASK ACE then the GROUP_OBJ ACE would be intersected > | with the group permissions as expected). > | > | I hope I haven't confused you. > | The standard can be equally confusing ;-) > | > | The withdrawn Posix ACL standard can be downloaded at: > | http://wt.xpilot.org/posix.1e/download.html > | > | Andreas Gruenbacher's site has some useful info: > | http://acl.bestbits.at > > > > > > I also want an easy way for it all to be inherited - as well as only > > "directories" would be +x, where normal files wouldn't need the > > executable bit set > > > > Are there any other utilities other than chacl for managing the ACLs? > Nathan Scott will soon check in ported versions of Andreas' > setfacl and getfacl ACL commands. > (Currently, you'll need to preserve an ACE ordering in ACL specification > for setfacl; > however, I'll look into fixing this problem when the code is checked in). > > --Tim > > From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:30:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73FUWt13380 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:30:32 -0700 Received: from zok.corp.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FUUV13361 for ; Fri, 3 Aug 2001 08:30:30 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f73FZam30571 for ; Fri, 3 Aug 2001 08:35:36 -0700 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 KAA2617160 for ; Fri, 3 Aug 2001 10:29:04 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA39360 for ; Fri, 3 Aug 2001 10:29:04 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f73FTRr10365; Fri, 3 Aug 2001 10:29:27 -0500 Message-Id: <200108031529.f73FTRr10365@jen.americas.sgi.com> Date: Fri, 3 Aug 2001 10:29:27 -0500 Subject: TAKE - fix frag command in xfs_db Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Aug 3 08:28:29 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100144a cmd/xfsprogs/db/frag.c - 1.3 - Fix endian conversion problem in frag command - we were byte flipping the inode type twice, resulting in unrecognized inodes and most of them getting skipped. From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:35:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73FZVX13632 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:35:31 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FZUV13613 for ; Fri, 3 Aug 2001 08:35:30 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f73FYQu23549; Fri, 3 Aug 2001 11:34:26 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Fri, 3 Aug 2001 11:34:26 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Steve Lord cc: Darrell Michaud , Subject: Re: fh_verify: permission failure (?) In-Reply-To: <200108031520.f73FK0w10141@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 3 Aug 2001 at 10:20am, Steve Lord wrote > > On Fri, 3 Aug 2001 at 10:59am, Darrell Michaud wrote > > > > > I see this same problem with our test XFS / NFS server. > > > > > And I see the same problem on two stock RH-7.1 (i.e. non XFS) NFS servers > > with Linux and IRIX clients. I have heard no complaints (well, about this > > anyway) from the users, though, so I haven't looked into fixing it. > > > > Define 'problem' here, the code is basically a debug printf which says > that an nfs client attempted to access a file it did not have permission > to access and is being rejected. If a user who really does have access to > a file is rejected by this code then there is a real problem, otherwise > it is just the kernel being chatty. Ah, sorry -- I should have been clearer. I meant that I see the same *messages* on my non-XFS servers, but none of the users have claimed to be denied access to that to which they are entitled. Thus it really isn't a problem (or, it hasn't been for me), and it isn't XFS specific. > Steve -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:39:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73Fdo313798 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:39:50 -0700 Received: from homer.mkintl.com (cloven-ext.nks.net [216.139.204.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FdmV13768 for ; Fri, 3 Aug 2001 08:39:48 -0700 Received: from illusionary.com (two.nks.net [192.168.1.22]) by homer.mkintl.com (8.9.3/8.9.3) with ESMTP id LAA02281 for ; Fri, 3 Aug 2001 11:39:37 -0400 Message-ID: <3B6AC5B9.45136565@illusionary.com> Date: Fri, 03 Aug 2001 11:39:37 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: xfs-list Subject: Re: XFS fs size limit? References: <200108021734.f72HYDo07108@jen.americas.sgi.com> <4.3.2.7.2.20010802224302.03e82e68@pop.xs4all.nl> <4.3.2.7.2.20010802231931.03d33168@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some people said: > > > That is silly. Just make a big raid0 of it. If for some reason one ofthe > > > 3ware cards takes a dump you WILL LOSE ALL YOUR DATA. > > > Which is exactly the reason to avoid the above mentioned configuration.If > > > one card dies you have just lost all your data. > I have seen lots of drives go bad too. But don't discount Murphy. You might > just have a bad day and a firmware upgrade of your controller resets the > raid set. Most people with more then one 3ware card will set it up in JBOD > mode and then use it as a software raid5 with a external log. > I just feel that my data would not be safe with the setup that you have > provided. They even had bugs in the 3ware raid config which caused > corruption in degraded mode. If that happens on your raid0 array or any > array you are going to lose data. But I think that the chances of severe > damage will grow in this raid0 setup. Not to try to drag this conversation even more off-topic than it already is, but I'm finding this talk about the potential of 3ware cards or drives going out and losing big important RAID devices and etc really pretty funny, since IMNSHO, anyone trying to build production-level, mission-critical RAID volumes off of cheap-o IDE drives and what I consider a pretty nice, but really pretty low-level IDE RAID card is just asking for problems to begin with. The 3ware cards are nice if you have a bunch of IDE disks lying around and need space and like to be able to do hardware RAID, but if I were building a mission-critical datastore, I'd definitely be using high-end SCSI drives and a RAID controller I was *damn sure* was as bulletproof as I could get. So this discussion is making me chuckle. :) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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.eff.org/ http://www.opendvd.org/ http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:45:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73FjvR14092 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:45:57 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FjsV14073 for ; Fri, 3 Aug 2001 08:45:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA06311 for ; Fri, 3 Aug 2001 08:45:38 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2616744; Fri, 3 Aug 2001 10:44:36 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA66269; Fri, 3 Aug 2001 10:44:36 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f73FixI10433; Fri, 3 Aug 2001 10:44:59 -0500 Message-Id: <200108031544.f73FixI10433@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Constantin Loizides cc: Utz Lehmann , xfs-list Subject: Re: Strage values from FIBMAP on holes or after end of file In-Reply-To: Message from Constantin Loizides of "Fri, 03 Aug 2001 13:57:08 +0200." <3B6A9194.6C5B908F@isg.de> Date: Fri, 03 Aug 2001 10:44:59 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, > > thanx to Utz, > I have rewritten the fibmap tool. > You find it at > > http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ I just chased down a bug in the xfs_db program which makes its fragmentation command work correctly, should show up in the cvs tree within the hour. Once it does you will be able to do this: xfs_db -r /dev/sda3 xfs_db: frag actual 45069, ideal 44941, fragmentation factor 0.28% xfs_db: This works by walking all the internal structures on the disk looking at inode contents. Read the man page for options for only looking at specific inode types. One example would be, on the same filesystem: regular files: xfs_db: frag -f actual 43660, ideal 43652, fragmentation factor 0.02% and directories: xfs_db: frag -d actual 1409, ideal 1289, fragmentation factor 8.52% Check out the freesp command as well, it shows the distribution of filesystem free space. The end result is that the fibmap program is still going wrong somewhere. The new version with a fixed ioctl call for xfs gave me this for the same filesystem: Result for 48425 files 3044 dirs: Int: 0.873 Ext: 1.000 1.000 1.000 1.000 - 1.000 - Path 1.000 1.010 Mean Internal frag: 0.873 Mean External frag: 1.000 Mean Frag. Path 1.000 Hist for frag 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 1 29639 7198 4720 3038 1827 1131 445 269 93 32 24 6 2 1 48425 29639 7198 4720 3038 1827 1131 445 269 93 32 24 6 2 1 48425 Hist for frag path 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 1 29639 7198 4720 3038 1827 1131 445 268 91 31 24 6 2 1 48421 10 0 0 0 0 0 0 0 1 2 1 0 0 0 0 4 29639 7198 4720 3038 1827 1131 445 269 93 32 24 6 2 1 48425 Now, the xfs_db frag command is looking at the extent information for all files, and comparing it with the ideal case. So a file which has a physical hole in the middle has an ideal extent count of 2. If a directory or symlink fits in the inode it has no fragmentation it does not show up in the output, this probably explains the count differences in the output, there are 3044 directories in this filesystem, but only 1218 of them are using space outside the inode. Steve > >[...] > > > > Did you just discover this problem by inspection, or did it > > > bite you in some other way? (was some other program using > > > the FIBMAP ioctl and not working correctly with XFS?) > > > > I found this with the fibmap program of Constantin Loizides fragmentation > > project. http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ > > Note: The current version of fibmap doesn't work with XFS well. I thing > > Constantin will release a fixed version soon. > > > > Should work now on xfs, too. > Also did some minor changes. > > Utz, could you test it on your patched system, please? > (I still test for minus and zwro values for holes though...) > > Constantin From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:52:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73FqGZ14310 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:52:16 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FqFV14291 for ; Fri, 3 Aug 2001 08:52:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA12345 for ; Fri, 3 Aug 2001 08:52:01 -0700 (PDT) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2607798; Fri, 3 Aug 2001 10:50:52 -0500 (CDT) 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 KAA85564; Fri, 3 Aug 2001 10:50:52 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id KAA98334; Fri, 3 Aug 2001 10:50:51 -0500 (CDT) Message-Id: <200108031550.KAA98334@fsgi158.americas.sgi.com> Subject: Re: fh_verify: permission failure (?) To: jlb17@duke.edu (Joshua Baker-LePain) Date: Fri, 3 Aug 2001 10:50:50 -0500 (CDT) Cc: lord@sgi.com (Steve Lord), dmichaud@wsicorp.com (Darrell Michaud), linux-xfs@oss.sgi.com In-Reply-To: from "Joshua Baker-LePain" at Aug 03, 2001 11:34:26 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 > > On Fri, 3 Aug 2001 at 10:20am, Steve Lord wrote > > > > On Fri, 3 Aug 2001 at 10:59am, Darrell Michaud wrote > > > > > > > I see this same problem with our test XFS / NFS server. > > > > > > > And I see the same problem on two stock RH-7.1 (i.e. non XFS) NFS servers > > > with Linux and IRIX clients. I have heard no complaints (well, about this > > > anyway) from the users, though, so I haven't looked into fixing it. > > > > > > > Define 'problem' here, the code is basically a debug printf which says > > that an nfs client attempted to access a file it did not have permission > > to access and is being rejected. If a user who really does have access to > > a file is rejected by this code then there is a real problem, otherwise > > it is just the kernel being chatty. > > Ah, sorry -- I should have been clearer. I meant that I see the same > *messages* on my non-XFS servers, but none of the users have claimed to be > denied access to that to which they are entitled. Thus it really isn't a > problem (or, it hasn't been for me), and it isn't XFS specific. > I've seen these errors too. The only time it has been a real error is when using mmap because of known client-side credential problems with mmap. Tad From owner-linux-xfs@oss.sgi.com Fri Aug 3 08:58:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73FwRq14461 for linux-xfs-outgoing; Fri, 3 Aug 2001 08:58:27 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FwPV14442 for ; Fri, 3 Aug 2001 08:58:25 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 1FD141AB10 for ; Fri, 3 Aug 2001 11:58:25 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id BCE156DF; Fri, 3 Aug 2001 11:58:24 -0400 (EDT) Date: Fri, 3 Aug 2001 11:58:24 -0400 From: Andrew Klaassen To: xfs-list Subject: Re: XFS fs size limit? Message-ID: <20010803115824.C11323@dkp.com> Mail-Followup-To: xfs-list References: <200108021734.f72HYDo07108@jen.americas.sgi.com> <4.3.2.7.2.20010802224302.03e82e68@pop.xs4all.nl> <4.3.2.7.2.20010802231931.03d33168@pop.xs4all.nl> <3B6AC5B9.45136565@illusionary.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B6AC5B9.45136565@illusionary.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 03, 2001 at 11:39:37AM -0400, Derek Glidden wrote: > Not to try to drag this conversation even more off-topic than > it already is... It sounds like it'd be a perfect conversation for the linux-ide-arrays list... ;) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Aug 3 09:04:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73G4es14691 for linux-xfs-outgoing; Fri, 3 Aug 2001 09:04:40 -0700 Received: from mail.isg.de (foobar.isg.de [62.96.243.63]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73G4cV14672 for ; Fri, 3 Aug 2001 09:04:38 -0700 Received: from isg.de (wall2-outer.isg.de [62.96.243.126]) by mail.isg.de (Postfix) with ESMTP id 83903760BCA; Fri, 3 Aug 2001 18:04:32 +0200 (CEST) Message-ID: <3B6ACB8E.A99C548D@isg.de> Date: Fri, 03 Aug 2001 18:04:30 +0200 From: Constantin Loizides Organization: Innovative Software AG X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord Cc: xfs-list Subject: Re: Strage values from FIBMAP on holes or after end of file References: <200108031544.f73FixI10433@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve > > Result for 48425 files 3044 dirs: Int: 0.873 Ext: 1.000 1.000 1.000 1.000 - 1.000 - Path 1.000 1.010 > Mean Internal frag: 0.873 > Mean External frag: 1.000 > Mean Frag. Path 1.000 > Now, the xfs_db frag command is looking at the extent information for all > files, and comparing it with the ideal case. So a file which has a physical > hole in the middle has an ideal extent count of 2. If a directory or symlink > fits in the inode it has no fragmentation it does not show up in the output, > this probably explains the count differences in the output, there are 3044 > directories in this filesystem, but only 1218 of them are using space > outside the inode. > Actually fibmap is only working on regular files. (So the directories are just counted for fun.) Hardlinks are treated as regular files, symlinks are not followed. But you say, xfs_db frag found a fragment value of 0.02 % that is 0.9998 in my way of counting which is rounded to 1.000. I changed fibmaps final output to show 6 digits. Please, give it another try http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ Constantin From owner-linux-xfs@oss.sgi.com Fri Aug 3 09:08:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73G80q14857 for linux-xfs-outgoing; Fri, 3 Aug 2001 09:08:00 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73G7wV14838 for ; Fri, 3 Aug 2001 09:07:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA00857 for ; Fri, 3 Aug 2001 09:05:47 -0700 (PDT) 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 LAA2617872 for ; Fri, 3 Aug 2001 11:06:42 -0500 (CDT) 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 LAA58021 for ; Fri, 3 Aug 2001 11:06:42 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f73G48Z19838; Fri, 3 Aug 2001 11:04:08 -0500 Message-Id: <200108031604.f73G48Z19838@stout.americas.sgi.com> Date: Fri, 3 Aug 2001 11:04:08 -0500 From: Eric Sandeen To: linux-xfs@oss.sgi.com Subject: Security Update for 1.0.1 Installer Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you have installed, or plan to install, any systems using the XFS 1.0.1 installer, please read the following message. It was recently discovered that due to a bug* in the underlying Linux kernel, the permissions of several system configuration files created at install time are world-writeable, which poses a security risk. This bug is not XFS-related, and will exhibit itself on an ext2-only install from the XFS 1.0.1 iso as well. These permissions may be fixed by running the script at ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/fix-perms as root. An update disk has also been provided at ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/updates to be used on future installs. Please see the README at ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/updates/README for information on how to use this update disk. Thanks for your attention, and we apologize for any inconvenience this may have caused. Sincerely, The SGI XFS for Linux Team ----- *The default umask for kernel threads, including init, was incorrectly set to 000. Stock Red Hat init scripts set umask to 022 at system startup, so it hides this bug. However, the anaconda installer does not do this, so files created during the install process have incorrect permissions. From owner-linux-xfs@oss.sgi.com Fri Aug 3 09:17:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73GHMO15175 for linux-xfs-outgoing; Fri, 3 Aug 2001 09:17:22 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73GHIV15155 for ; Fri, 3 Aug 2001 09:17:18 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA589517 for ; Fri, 3 Aug 2001 18:17:00 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2617818; Fri, 3 Aug 2001 11:15:59 -0500 (CDT) 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 LAA21480; Fri, 3 Aug 2001 11:15:58 -0500 (CDT) Subject: Re: FIX: World-writeable files repair script From: Eric Sandeen To: Dean Brissinger Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <14982.996810747@kao2.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 03 Aug 2001 11:13:24 -0500 Message-Id: <996855205.17555.32.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 03 Aug 2001 09:04:07 -0600, Dean Brissinger wrote: > Is it safe to run the 2.4.3 kernel in general? I won't pretend to be a security expert, but I think that as long as the umask is set at boot time the problem will be masked. -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 Aug 3 09:30:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73GU6C15446 for linux-xfs-outgoing; Fri, 3 Aug 2001 09:30:06 -0700 Received: from rj.corp.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73GU2V15427 for ; Fri, 3 Aug 2001 09:30:02 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f73GY8D02694 for ; Fri, 3 Aug 2001 09:34:09 -0700 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 LAA2609973; Fri, 3 Aug 2001 11:28:38 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA99524; Fri, 3 Aug 2001 11:28:38 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f73GT1k10663; Fri, 3 Aug 2001 11:29:01 -0500 Message-Id: <200108031629.f73GT1k10663@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Constantin Loizides cc: Steve Lord , xfs-list Subject: Re: Strage values from FIBMAP on holes or after end of file In-Reply-To: Message from Constantin Loizides of "Fri, 03 Aug 2001 18:04:30 +0200." <3B6ACB8E.A99C548D@isg.de> Date: Fri, 03 Aug 2001 11:29:01 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi Steve > Actually fibmap is only working on regular files. (So the directories > are just > counted for fun.) Hardlinks are treated as regular files, symlinks are > not followed. > > But you say, xfs_db frag found a fragment value of 0.02 % that is 0.9998 > in my way of counting > which is rounded to 1.000. I changed fibmaps final output to show 6 > digits. > Please, give it another try > http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ Hmm, I think you changed the -v output, not the summary, I made my own change and got this output: Result for 48425 files 3044 dirs: Int: 0.873321 Ext: 1.000000 1.000000 1.000000 1.000000 - 1.000162 - Path 1.000162 1.010155 Mean Internal frag: 0.873321 Mean External frag: 1.000000 Mean Frag. Path 1.000162 If I read your web page correctly, internal fragmentation is basically saying that if your filesystem uses a fixed size unit of space to place files in and your files are not all a multiple of that size then you will get internal fragmentation. So basically if I had a 4K block filesystem and all my files were 2K long I would have an internal fragmentation of 50%. This is a measure of space efficiency of the filesystem, not really fragmentation. Only filesystems which support tail packing, or use a really small block size will be able to get a really low number here when you use small files. Is this a correct interpretation? Steve p.s. I have an xfs filesystem which has existed for probably a year or so now, it is where I do all my kernel builds, merges with linus's trees, rpm building etc. I also frequently have multiple operations on going in parallel. It currently looks like this: df /src Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda5 4194932 2439204 1755728 59% /src df -i /src Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hda5 4200896 113588 4087308 3% /src xfs_db: frag actual 109889, ideal 109553, fragmentation factor 0.31% xfs_db: freesp from to extents blocks pct 1 1 597 597 0.14 2 3 414 967 0.22 4 7 333 1762 0.40 8 15 279 3165 0.72 16 31 153 3458 0.79 32 63 148 6904 1.57 64 127 259 24360 5.55 128 255 290 52605 11.98 256 511 186 65816 14.99 512 1023 71 49383 11.25 1024 2047 14 19025 4.33 2048 4095 6 17071 3.89 4096 8191 8 50298 11.46 8192 16383 4 49448 11.27 16384 32767 1 21222 4.83 32768 65535 2 72851 16.60 ./fibmap /src Result for 106819 files 6584 dirs: Int: 0.891066 Ext: 0.999941 0.999942 0.999954 0.999954 - 1.347378 - Path 1.495712 2.525242 Mean Internal frag: 0.891066 Mean External frag: 0.999941 Mean Frag. Path 1.495712 > > Constantin From owner-linux-xfs@oss.sgi.com Fri Aug 3 10:24:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73HO2Z16252 for linux-xfs-outgoing; Fri, 3 Aug 2001 10:24:02 -0700 Received: from mail.isg.de (foobar.isg.de [62.96.243.63]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73HNvV16227 for ; Fri, 3 Aug 2001 10:23:57 -0700 Received: from isg.de (wall2-outer.isg.de [62.96.243.126]) by mail.isg.de (Postfix) with ESMTP id DE50F6EA828; Fri, 3 Aug 2001 19:23:56 +0200 (CEST) Message-ID: <3B6ADE29.835E1C5C@isg.de> Date: Fri, 03 Aug 2001 19:23:53 +0200 From: Constantin Loizides Organization: Innovative Software AG X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord Cc: xfs-list Subject: Re: Strage values from FIBMAP on holes or after end of file References: <200108031629.f73GT1k10663@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, > [...] > Hmm, I think you changed the -v output, not the summary, I made my own change > and got this output: Oh yes, how stupid I am *g* > > Result for 48425 files 3044 dirs: Int: 0.873321 Ext: 1.000000 1.000000 1.000000 1.000000 - 1.000162 - Path 1.000162 1.010155 > Mean Internal frag: 0.873321 > Mean External frag: 1.000000 > Mean Frag. Path 1.000162 > > If I read your web page correctly, internal fragmentation is basically > saying that if your filesystem uses a fixed size unit of space to place > files in and your files are not all a multiple of that size then you will > get internal fragmentation. Correct > So basically if I had a 4K block filesystem > and all my files were 2K long I would have an internal fragmentation > of 50%. This is a measure of space efficiency of the filesystem, not > really fragmentation. That's called internal fragmentation in literature. But you are right, it is not what you usually talk of when talking about (external) fragmentation > Only filesystems which support tail packing, or > use a really small block size will be able to get a really low number > here when you use small files. > > Is this a correct interpretation? Perfectly! Think also about fragments of UFS. Same thing. These systems try not to waste to much of space. > p.s. I have an xfs filesystem which has existed for probably a year or so > now, it is where I do all my kernel builds, merges with linus's trees, rpm > building etc. I also frequently have multiple operations on going in parallel. > It currently looks like this: > > df /src > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/hda5 4194932 2439204 1755728 59% /src > > df -i /src > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/hda5 4200896 113588 4087308 3% /src > > xfs_db: frag > actual 109889, ideal 109553, fragmentation factor 0.31% > xfs_db: freesp > from to extents blocks pct > 1 1 597 597 0.14 > 2 3 414 967 0.22 > 4 7 333 1762 0.40 > 8 15 279 3165 0.72 > 16 31 153 3458 0.79 > 32 63 148 6904 1.57 > 64 127 259 24360 5.55 > 128 255 290 52605 11.98 > 256 511 186 65816 14.99 > 512 1023 71 49383 11.25 > 1024 2047 14 19025 4.33 > 2048 4095 6 17071 3.89 > 4096 8191 8 50298 11.46 > 8192 16383 4 49448 11.27 > 16384 32767 1 21222 4.83 > 32768 65535 2 72851 16.60 > > ./fibmap /src > Result for 106819 files 6584 dirs: Int: 0.891066 Ext: 0.999941 0.999942 0.999954 0.999954 - 1.347378 - Path 1.495712 2.525242 > Mean Internal frag: 0.891066 > Mean External frag: 0.999941 > Mean Frag. Path 1.495712 I cant say much, as I dont know how xfs_db calculates these values. But I am wondering about the internal frag. Thought xfs only can handel 4K blocks? If your /src fs uses 4K blocks, then 0.89 e.g. 10 % is a very low value of internal fragmentation. If it uses 1K (as shown in the ooutput of df) then it is quite normal compared to a 1K ext2 system. Constantin From owner-linux-xfs@oss.sgi.com Fri Aug 3 10:32:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73HW0l16554 for linux-xfs-outgoing; Fri, 3 Aug 2001 10:32:00 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73HVvV16535 for ; Fri, 3 Aug 2001 10:31:57 -0700 Received: from marathon.brocade.com (marathon [192.168.198.53]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id KAA11102; Fri, 3 Aug 2001 10:31:46 -0700 (PDT) Received: from localhost (gerickso@localhost) by marathon.brocade.com (8.9.1b+Sun/8.9.3) with ESMTP id KAA26510; Fri, 3 Aug 2001 10:31:45 -0700 (PDT) X-Authentication-Warning: marathon.brocade.com: gerickso owned process doing -bs Date: Fri, 3 Aug 2001 10:31:44 -0700 (PDT) From: Grant Erickson X-X-Sender: Reply-To: Grant Erickson To: cc: Subject: PATCH: xfsprogs-1.3.1/configure.in - Cross Compilation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Below is a patch to allow the xfsprogs-1.3.1/configure script to work correctly (at least mostly correctly) when cross-compiling from sparc-sun-solaris to powerpc-linux-gnu. The idea and code is lifted, more or less, wholesale from e2fsprogs-1.22: --- xfsprogs-1.3.1/configure.in Thu Jul 12 11:54:37 2001 +++ xfsprogs/configure.in Fri Aug 3 10:18:47 2001 @@ -45,7 +45,7 @@ test -z "$DISTRIBUTION" || pkg_distribution="$DISTRIBUTION" AC_SUBST(pkg_distribution) -pkg_builder=`id -u -n`@`hostname -f` +pkg_builder=`id -u -n`@`hostname` test -z "$PACKAGE_BUILDER" || pkg_builder="$PACKAGE_BUILDER" AC_SUBST(pkg_builder) @@ -166,37 +166,21 @@ __psunsigned_t psuint; ], AC_DEFINE(HAVE___PSUNSIGNED_T) AC_MSG_RESULT(yes) , AC_MSG_RESULT(no)) - -dnl check sizeof long -AC_MSG_CHECKING([sizeof long]) -cat <conftest.c -#include -main() { printf("%d\n", sizeof(long)); } -End-of-File -(eval $ac_compile) 2>&5 -(eval $ac_link) 2>&5 -ans=`./conftest` -echo "./conftest -> \"$ans\"" >&5 -AC_MSG_RESULT($ans) -test $ans -eq 4 && AC_DEFINE(HAVE_32BIT_LONG) -test $ans -eq 8 && AC_DEFINE(HAVE_64BIT_LONG) -rm -f conftest conftest.* - -dnl check sizeof pointer -AC_MSG_CHECKING([sizeof pointer]) -cat <conftest.c -#include -main() { printf("%d\n", sizeof(char *)); } -End-of-File -(eval $ac_compile) 2>&5 -(eval $ac_link) 2>&5 -ans=`./conftest` -echo "./conftest -> \"$ans\"" >&5 -AC_MSG_RESULT($ans) -test $ans -eq 4 && AC_DEFINE(HAVE_32BIT_PTR) -test $ans -eq 8 && AC_DEFINE(HAVE_64BIT_PTR) -rm -f conftest conftest.* - +dnl +dnl Check type sizes +dnl +if test "$cross_compiling" = yes -a "$ac_cv_sizeof_long" = ""; then + # if cross-compiling, with no cached values, just assume something common. + ac_cv_sizeof_long=4 + ac_cv_sizeof_char_p=4 + AC_MSG_WARN([Cross-compiling; cannot check type sizes; assuming long=4 ponter=4]) +fi +AC_CHECK_SIZEOF(long) +AC_CHECK_SIZEOF(char *) +test $ac_cv_sizeof_long -eq 4 && AC_DEFINE(HAVE_32BIT_LONG) +test $ac_cv_sizeof_long -eq 8 && AC_DEFINE(HAVE_64BIT_LONG) +test $ac_cv_sizeof_char_p -eq 4 && AC_DEFINE(HAVE_32BIT_PTR) +test $ac_cv_sizeof_char_p -eq 8 && AC_DEFINE(HAVE_64BIT_PTR) dnl alternate root and usr prefixes test -z "$ROOT_PREFIX" && ROOT_PREFIX="" -- Grant Erickson Phone: (408) 487-8087 Brocade Communications Systems, Inc. Fax: (408) 392-1702 1745 Technology Drive San Jose, CA 95110 E-mail: gerickson@brocade.com From owner-linux-xfs@oss.sgi.com Fri Aug 3 10:42:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73HgXx16750 for linux-xfs-outgoing; Fri, 3 Aug 2001 10:42:33 -0700 Received: from rj.corp.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73HgVV16731 for ; Fri, 3 Aug 2001 10:42:31 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f73HkbD06469 for ; Fri, 3 Aug 2001 10:46:38 -0700 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 MAA2619965; Fri, 3 Aug 2001 12:41:06 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA94328; Fri, 3 Aug 2001 12:41:06 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f73HfS710966; Fri, 3 Aug 2001 12:41:28 -0500 Message-Id: <200108031741.f73HfS710966@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Constantin Loizides cc: xfs-list Subject: Re: Strage values from FIBMAP on holes or after end of file In-Reply-To: Message from Constantin Loizides of "Fri, 03 Aug 2001 19:23:53 +0200." <3B6ADE29.835E1C5C@isg.de> Date: Fri, 03 Aug 2001 12:41:28 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > p.s. I have an xfs filesystem which has existed for probably a year or so > > now, it is where I do all my kernel builds, merges with linus's trees, rpm > > building etc. I also frequently have multiple operations on going in parall > el. > > It currently looks like this: > > > > df /src > > Filesystem 1k-blocks Used Available Use% Mounted on > > /dev/hda5 4194932 2439204 1755728 59% /src > > > > df -i /src > > Filesystem Inodes IUsed IFree IUse% Mounted on > > /dev/hda5 4200896 113588 4087308 3% /src > > > > xfs_db: frag > > actual 109889, ideal 109553, fragmentation factor 0.31% > > xfs_db: freesp > > from to extents blocks pct > > 1 1 597 597 0.14 > > 2 3 414 967 0.22 > > 4 7 333 1762 0.40 > > 8 15 279 3165 0.72 > > 16 31 153 3458 0.79 > > 32 63 148 6904 1.57 > > 64 127 259 24360 5.55 > > 128 255 290 52605 11.98 > > 256 511 186 65816 14.99 > > 512 1023 71 49383 11.25 > > 1024 2047 14 19025 4.33 > > 2048 4095 6 17071 3.89 > > 4096 8191 8 50298 11.46 > > 8192 16383 4 49448 11.27 > > 16384 32767 1 21222 4.83 > > 32768 65535 2 72851 16.60 > > > > ./fibmap /src > > Result for 106819 files 6584 dirs: Int: 0.891066 Ext: 0.999941 0.999942 0.9 > 99954 0.999954 - 1.347378 - Path 1.495712 2.525242 > > Mean Internal frag: 0.891066 > > Mean External frag: 0.999941 > > Mean Frag. Path 1.495712 > I cant say much, as I dont know how xfs_db calculates these values. > > But I am wondering about the internal frag. Thought xfs only can handel > 4K blocks? > If your /src fs uses 4K blocks, then 0.89 e.g. 10 % is a very low value > of internal fragmentation. It is using 4K blocks, XFS is good at this stuff ;-). Actually, large files will tend to reduce the fragmentation, i.e. a 399K file which consumes 400K of disk space is not very fragmented by this measure, so really this is a function of file size distribution. > If it uses 1K (as shown in the ooutput of df) then it is quite normal > compared to a 1K ext2 system. Blocksize in df output is not a function of filesystem blocksize, it is always reported in 1K chunks. Also be careful of st_blksize reported by stat, it is the optimum size for doing I/O, not the filesystem block size (not that you are using this right now). Steve > > Constantin From owner-linux-xfs@oss.sgi.com Fri Aug 3 11:21:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73ILwp17474 for linux-xfs-outgoing; Fri, 3 Aug 2001 11:21:58 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73ILuV17455 for ; Fri, 3 Aug 2001 11:21:56 -0700 Received: from idcomm.com (IDENT:eg92bpXVZgK+JMqaiaONcTDIFVGFAnn7@x2-pip37.idcomm.com [209.60.72.48]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f73IRmP23307 for ; Fri, 3 Aug 2001 12:27:49 -0600 Message-ID: <3B6AEBD9.63F26EEE@idcomm.com> Date: Fri, 03 Aug 2001 12:22:17 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Security Update for 1.0.1 Installer References: <200108031604.f73G48Z19838@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: > > If you have installed, or plan to install, any systems using > the XFS 1.0.1 installer, please read the following message. > > It was recently discovered that due to a bug* in the underlying > Linux kernel, the permissions of several system configuration > files created at install time are world-writeable, which poses > a security risk. > > This bug is not XFS-related, and will exhibit itself on an > ext2-only install from the XFS 1.0.1 iso as well. I think I may have seen this at one point on the kernel dev list (or something related), but can't recall exactly. I'm curious if the kernel people know about this yet, or maybe have already fixed it for later kernels? D. Stimits, stimits@idcomm.com > > These permissions may be fixed by running the script at > > ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/fix-perms > > as root. > > An update disk has also been provided at > > ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/updates > > to be used on future installs. Please see the README at > > ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/installer/updates/README > > for information on how to use this update disk. > > Thanks for your attention, and we apologize for any inconvenience this > may have caused. > > Sincerely, > > The SGI XFS for Linux Team > > ----- > > *The default umask for kernel threads, including init, was incorrectly > set to 000. Stock Red Hat init scripts set umask to 022 at system > startup, so it hides this bug. However, the anaconda installer does > not do this, so files created during the install process have incorrect > permissions. From owner-linux-xfs@oss.sgi.com Fri Aug 3 11:35:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73IZci17775 for linux-xfs-outgoing; Fri, 3 Aug 2001 11:35:38 -0700 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 f73IZaV17756 for ; Fri, 3 Aug 2001 11:35:36 -0700 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 f73IelW02723 for ; Fri, 3 Aug 2001 11:40:47 -0700 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 NAA2618734; Fri, 3 Aug 2001 13:34:14 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA05772; Fri, 3 Aug 2001 13:34:14 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f73IYaX11073; Fri, 3 Aug 2001 13:34:36 -0500 Message-Id: <200108031834.f73IYaX11073@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stimits@idcomm.com cc: linux-xfs@oss.sgi.com Subject: Re: Security Update for 1.0.1 Installer In-Reply-To: Message from "D. Stimits" of "Fri, 03 Aug 2001 12:22:17 MDT." <3B6AEBD9.63F26EEE@idcomm.com> Date: Fri, 03 Aug 2001 13:34:36 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Eric Sandeen wrote: > > > > If you have installed, or plan to install, any systems using > > the XFS 1.0.1 installer, please read the following message. > > > > It was recently discovered that due to a bug* in the underlying > > Linux kernel, the permissions of several system configuration > > files created at install time are world-writeable, which poses > > a security risk. > > > > This bug is not XFS-related, and will exhibit itself on an > > ext2-only install from the XFS 1.0.1 iso as well. > > I think I may have seen this at one point on the kernel dev list (or > something related), but can't recall exactly. I'm curious if the kernel > people know about this yet, or maybe have already fixed it for later > kernels? I think it was fixed by around 2.4.7 Steve > > D. Stimits, stimits@idcomm.com > From owner-linux-xfs@oss.sgi.com Fri Aug 3 11:49:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73IntI18109 for linux-xfs-outgoing; Fri, 3 Aug 2001 11:49:55 -0700 Received: from ente.berdmann.de (p3EE0A9F1.dip.t-dialin.net [62.224.169.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73InlV18090 for ; Fri, 3 Aug 2001 11:49:49 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15Sk0t-00081e-00; Fri, 03 Aug 2001 20:49:35 +0200 Message-ID: <3B6AF23F.8A43C820@berdmann.de> Date: Fri, 03 Aug 2001 20:49:35 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: stimits@idcomm.com CC: linux-xfs@oss.sgi.com Subject: Re: Security Update for 1.0.1 Installer References: <200108031604.f73G48Z19838@stout.americas.sgi.com> <3B6AEBD9.63F26EEE@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I think I may have seen this at one point on the kernel dev list (or > something related), but can't recall exactly. I'm curious if the kernel > people know about this yet, or maybe have already fixed it for later > kernels? It was fixed by 2.4.7. From owner-linux-xfs@oss.sgi.com Fri Aug 3 11:52:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73IqI018310 for linux-xfs-outgoing; Fri, 3 Aug 2001 11:52:18 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73IqGV18291 for ; Fri, 3 Aug 2001 11:52:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA586234 for ; Fri, 3 Aug 2001 20:51:54 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2620107; Fri, 3 Aug 2001 13:50:52 -0500 (CDT) 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 NAA44974; Fri, 3 Aug 2001 13:50:52 -0500 (CDT) Subject: Re: Security Update for 1.0.1 Installer From: Eric Sandeen To: stimits@idcomm.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B6AEBD9.63F26EEE@idcomm.com> References: <200108031604.f73G48Z19838@stout.americas.sgi.com> <3B6AEBD9.63F26EEE@idcomm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 03 Aug 2001 13:48:16 -0500 Message-Id: <996864497.20383.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 03 Aug 2001 12:22:17 -0600, D. Stimits wrote: > I think I may have seen this at one point on the kernel dev list (or > something related), but can't recall exactly. I'm curious if the kernel > people know about this yet, or maybe have already fixed it for later > kernels? According to Keith, it was fixed in 2.4.7. -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 Aug 3 11:56:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73IuWD18540 for linux-xfs-outgoing; Fri, 3 Aug 2001 11:56:32 -0700 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 f73IuUV18521 for ; Fri, 3 Aug 2001 11:56:30 -0700 Received: from www.sigmastorage.com (128.241.173.170) by mail15a.boca15-verio.com (RS ver 1.0.60s) with SMTP id 0838251 for ; Fri, 3 Aug 2001 14:56:19 -0400 (EDT) Message-ID: <3B6AF30A.E007E454@sigmastorage.com> Date: Fri, 03 Aug 2001 11:52:58 -0700 From: Matt Ryan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2-june14 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: gcc versions 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 see this in the FAQ: "If you are using gcc 3.0 and it gives problems or does not compile, drop a note on the list with the oops and ksymoops output. We will be working on getting XFS fully functional with gcc 3.0. " does that mean the XFS team is planning on transitioning to 3.0 as the 'official' compiler in the near future? I ask because seeing something like this: "egcs-1.1.2 aka kgcc wont build 2.4.7 it seems." (from http://uwsg.iu.edu/hypermail/linux/kernel/0108.0/0309.html) makes me a little nervous. I don't really know what to make of that since I've compiled 2.4.7 + XFS with kgcc (as have everybody else I'm sure), but I wonder how much longer it'll be viable. Matt From owner-linux-xfs@oss.sgi.com Fri Aug 3 12:05:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73J55J18966 for linux-xfs-outgoing; Fri, 3 Aug 2001 12:05:05 -0700 Received: from imapserver2.fnal.gov (imapserver2.fnal.gov [131.225.9.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73J52V18947 for ; Fri, 3 Aug 2001 12:05:02 -0700 Received: from imapserver2.fnal.gov ([131.225.9.7]) by imapserver2.fnal.gov (Netscape Messaging Server 3.62) with SMTP id 327 for ; Fri, 3 Aug 2001 14:04:56 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserver2.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001080314045516880 for ; Fri, 03 Aug 2001 14:04:55 -0500 Message-ID: <3B6AF67D.6955AE0E@fnal.gov> Date: Fri, 03 Aug 2001 14:07:41 -0500 From: yocum@fnal.gov 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: XFS fs size limit? References: <200108021734.f72HYDo07108@jen.americas.sgi.com> <4.3.2.7.2.20010802224302.03e82e68@pop.xs4all.nl> <4.3.2.7.2.20010802231931.03d33168@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > At 15:00 2-8-2001 -0600, Steve Wolfe wrote: > > > >I assume you mean software RAID5, right? I've got a RAID50 array: 28-port > > > >3ware cards in hw raid5, then those two devices combined softwareraid0. I > > > >didn't bother to make the log on a separate device, but I could, > > ifneed be. > > > > > > That is silly. Just make a big raid0 of it. If for some reason one ofthe > > > 3ware cards takes a dump you WILL LOSE ALL YOUR DATA. ;-) > > > >(snip) > > > > > Which is exactly the reason to avoid the above mentioned configuration.If > > > one card dies you have just lost all your data. > > > > Personally, I'd bet on a drive or two going out before the controller. > >I haven't had any sort of drive controller (IDE/SCSI/RAID) go out in > >nearly a decade, but I've had plenty of drives go South on me. This is definitely a more likely senario. But, even in the event that we lose 50% of our data, we're still 100% screwed, so I might as well have the space/speed that I want/need. If I was really paranoid, I'd be putting my data on some fibre channel array or using drbd or something. I'm more interested in tons of space really, really cheap. > > I have seen lots of drives go bad too. But don't discount Murphy. You might > just have a bad day and a firmware upgrade of your controller resets the > raid set. Most people with more then one 3ware card will set it up in JBOD > mode and then use it as a software raid5 with a external log. > > > > Which was exactly what happend. They raid > > > controller (Ami megaraid) got upset after one disk died and they lost > > therI > > > complete Mysql Database. > > > > Since this isn't the place, I won't point out the obvious flaws in > >their backup/recovery scheme. > > What's a backup? And recovery is for wimps ;) File system? Who needs a file system? I edit inodes by hand! ;-) > I just feel that my data would not be safe with the setup that you have > provided. They even had bugs in the 3ware raid config which caused > corruption in degraded mode. If that happens on your raid0 array or any > array you are going to lose data. But I think that the chances of severe > damage will grow in this raid0 setup. FWIW, I got really good at reliably corrupting my data with the 3ware 6800 card and RAID5: just turn off a drive while it was writing. Bad things happened. I've been testing 3 7810 cards they lent to me a couple weeks ago, and I haven't had a problem yet (after ~10TB write/reads and ~12 simulated drive failures under a variety of high and low I/O and CPU duty cycles. 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 Fri Aug 3 15:14:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73MEHF32481 for linux-xfs-outgoing; Fri, 3 Aug 2001 15:14:17 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73MEFV32455 for ; Fri, 3 Aug 2001 15:14:15 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA00355; Sat, 4 Aug 2001 00:14:13 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA12230; Sat, 4 Aug 2001 00:14:13 +0200 (CEST) Date: Sat, 4 Aug 2001 00:14:13 +0200 (CEST) From: Seth Mos To: Derek Glidden cc: xfs-list Subject: Re: XFS fs size limit? In-Reply-To: <3B6AC5B9.45136565@illusionary.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, 3 Aug 2001, Derek Glidden wrote: > Some people said: > > Not to try to drag this conversation even more off-topic than it already > is, but I'm finding this talk about the potential of 3ware cards or > drives going out and losing big important RAID devices and etc really > pretty funny, That's good :-) > since IMNSHO, anyone trying to build production-level, > mission-critical RAID volumes off of cheap-o IDE drives and what I > consider a pretty nice, but really pretty low-level IDE RAID card is > just asking for problems to begin with. It's cheap, large, reliable, not fast and you can store lot's of MP3 on it. It's more a University thing or used in cheap nas appliances were it will do nice things since the 100Mbit onboard ethernet limits throughput anyways. moot point. > The 3ware cards are nice if you have a bunch of IDE disks lying around > and need space and like to be able to do hardware RAID, but if I were > building a mission-critical datastore, I'd definitely be using high-end > SCSI drives and a RAID controller I was *damn sure* was as bulletproof > as I could get. You get logistical problems going larger then about 16 disks. I have 1 production machine with software raid. Which is raid 1 to be able to keep going when one of the IDE disks in the server fails. Insert 100Mbit ethernet story again. If you want large you can hook 180GB baracudas on a hardware raid controller (dual or quad channel) and bump into the 2TB partition/filesystem limit of linux. Has anyone already bumped into that limit? > So this discussion is making me chuckle. :) Oh well, nothing better to do. We know how to dot it but this so much more fun. Streching the posibiliry's of the current available hardware. It's normal. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 3 15:21:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73ML7200790 for linux-xfs-outgoing; Fri, 3 Aug 2001 15:21:07 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73ML5V00771 for ; Fri, 3 Aug 2001 15:21:05 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA00988; Sat, 4 Aug 2001 00:21:04 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA12497; Sat, 4 Aug 2001 00:21:04 +0200 (CEST) Date: Sat, 4 Aug 2001 00:21:03 +0200 (CEST) From: Seth Mos To: Eric Sandeen cc: Dean Brissinger , linux-xfs@oss.sgi.com Subject: Re: FIX: World-writeable files repair script In-Reply-To: <996855205.17555.32.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 3 Aug 2001, Eric Sandeen wrote: > On 03 Aug 2001 09:04:07 -0600, Dean Brissinger wrote: > > > Is it safe to run the 2.4.3 kernel in general? > > I won't pretend to be a security expert, but I think that as long as the > umask is set at boot time the problem will be masked. Does this kernel have the netfilter patch applied for the related ftp sessions bug. which meant you could connect through the firewall if it also had a ftp port to talk to. This patch _is_ included in 2.4.4 and up. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 3 15:26:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73MQO301413 for linux-xfs-outgoing; Fri, 3 Aug 2001 15:26:24 -0700 Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73MQMV01388 for ; Fri, 3 Aug 2001 15:26:22 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.9.3/8.9.3) id AAA22048; Sat, 4 Aug 2001 00:26:13 +0200 Date: Sat, 4 Aug 2001 00:26:12 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Seth Mos Cc: Derek Glidden , xfs-list Subject: Re: XFS fs size limit? Message-ID: <20010804002612.U17875@vestdata.no> References: <3B6AC5B9.45136565@illusionary.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: ; from Seth Mos on Sat, Aug 04, 2001 at 12:14:13AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Aug 04, 2001 at 12:14:13AM +0200, Seth Mos wrote: > > The 3ware cards are nice if you have a bunch of IDE disks lying around > > and need space and like to be able to do hardware RAID, but if I were > > building a mission-critical datastore, I'd definitely be using high-end > > SCSI drives and a RAID controller I was *damn sure* was as bulletproof > > as I could get. > > You get logistical problems going larger then about 16 disks. I have 1 > production machine with software raid. Which is raid 1 to be able to keep > going when one of the IDE disks in the server fails. Insert 100Mbit > ethernet story again. > > If you want large you can hook 180GB baracudas on a hardware raid > controller (dual or quad channel) and bump into the 2TB > partition/filesystem limit of linux. > > Has anyone already bumped into that limit? Yes, we have. But this is getting awfully offtopic. -- Ragnar Kjorstad Big Storage From owner-linux-xfs@oss.sgi.com Fri Aug 3 15:32:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73MWB902064 for linux-xfs-outgoing; Fri, 3 Aug 2001 15:32:11 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73MW9V02045 for ; Fri, 3 Aug 2001 15:32:09 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA01872; Sat, 4 Aug 2001 00:32:08 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA12877; Sat, 4 Aug 2001 00:32:07 +0200 (CEST) Date: Sat, 4 Aug 2001 00:32:07 +0200 (CEST) From: Seth Mos To: yocum@fnal.gov cc: xfs-list Subject: Re: XFS fs size limit? In-Reply-To: <3B6AF67D.6955AE0E@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 3 Aug 2001 yocum@fnal.gov wrote: > Seth Mos wrote: > > yada yada. > File system? Who needs a file system? I edit inodes by hand! ;-) I've got 2 really big magnets and a pointy stick. > FWIW, I got really good at reliably corrupting my data with the 3ware 6800 > card and RAID5: just turn off a drive while it was writing. Write caching off thr IDE drive? > happened. I've been testing 3 7810 cards they lent to me a couple weeks > ago, and I haven't had a problem yet (after ~10TB write/reads and ~12 > simulated drive failures under a variety of high and low I/O and CPU duty > cycles. That's good to hear, but they won't be cheap in the netherlands. I have not owned a 3ware card ever, but I don't need them yet. I can still fit all the neccesary data on normal disks. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 3 15:38:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73McEH02692 for linux-xfs-outgoing; Fri, 3 Aug 2001 15:38:14 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73McCV02671 for ; Fri, 3 Aug 2001 15:38:12 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07255 for ; Fri, 3 Aug 2001 15:36:02 -0700 (PDT) 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 PAA11997; Fri, 3 Aug 2001 15:37:40 -0700 (PDT) Message-ID: <3B6B26A7.79AD1AE@sgi.com> Date: Fri, 03 Aug 2001 17:33:11 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Dean Brissinger , linux-xfs@oss.sgi.com Subject: Re: FIX: World-writeable files repair script References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > Does this kernel have the netfilter patch applied for the related ftp > sessions bug. which meant you could connect through the firewall if it > also had a ftp port to talk to. Not sure what to tell you about the Red Hat 2.4.3 kernel, I didn't sift through all of the hundreds of patches they apply... :) -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 Aug 3 16:04:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73N4av05158 for linux-xfs-outgoing; Fri, 3 Aug 2001 16:04:36 -0700 Received: from homer.mkintl.com (cloven-ext.nks.net [216.139.204.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73N4YV05125 for ; Fri, 3 Aug 2001 16:04:34 -0700 Received: from illusionary.com (two.nks.net [192.168.1.22]) by homer.mkintl.com (8.9.3/8.9.3) with ESMTP id TAA06562 for ; Fri, 3 Aug 2001 19:04:23 -0400 Message-ID: <3B6B2DF7.E996D728@illusionary.com> Date: Fri, 03 Aug 2001 19:04:23 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: xfs-list Subject: Re: XFS fs size limit? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > It's cheap, large, reliable, not fast and you can store lot's of MP3 > on it. It's more a University thing or used in cheap nas appliances were > it will do nice things since the 100Mbit onboard ethernet limits > throughput anyways. moot point. Oh hey, don't get me wrong, I think the 3ware cards are seriously hep. I've got big-time hardware envy over the ones we're playing with at work. (watch this nice transition...) I want one at home so I can rebuild my big file server (wait for it...) at home that uses LVM and XFS (and there you are) on a big 3ware RAID5 device with something like 4 80GB IDE drives. I figure going that route gets me *some* measure of reliability and still winds up being cheaper for the whole setup than just one really nice SCSI RAID controller. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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.eff.org/ http://www.opendvd.org/ http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ From owner-linux-xfs@oss.sgi.com Fri Aug 3 18:10:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f741APn15821 for linux-xfs-outgoing; Fri, 3 Aug 2001 18:10:25 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f741ANV15796 for ; Fri, 3 Aug 2001 18:10:23 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA08182 for ; Fri, 3 Aug 2001 18:09:57 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA15058 for linux-xfs@oss.sgi.com; Sat, 4 Aug 2001 11:08:54 +1000 (EST) Date: Sat, 4 Aug 2001 11:08:54 +1000 (EST) From: Nathan Scott Message-Id: <200108040108.LAA15058@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - configure Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Aug 3 18:07:30 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100198a cmd/acl/configure.in - 1.8 cmd/attr/configure.in - 1.7 cmd/dmapi/configure.in - 1.11 cmd/xfsdump/configure.in - 1.14 cmd/xfstests/configure.in - 1.11 - don't use -f to "hostname", its not portable. cmd/xfsprogs/configure.in - 1.10 - don't use -f to "hostname"; rework logic for checking sizeof long/ptr so that cross compiles work correctly. cmd/xfsprogs/doc/CHANGES - 1.31 cmd/xfsprogs/debian/changelog - 1.22 - update with changes since 1.3.3. cmd/xfsprogs/VERSION - 1.25 - bump the revision number to 4. From owner-linux-xfs@oss.sgi.com Fri Aug 3 18:11:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f741BBf16025 for linux-xfs-outgoing; Fri, 3 Aug 2001 18:11:11 -0700 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 f741B9V15995 for ; Fri, 3 Aug 2001 18:11:09 -0700 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 f741FCS17831 for ; Fri, 3 Aug 2001 18:15:12 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19319; Sat, 4 Aug 2001 11:09:42 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA00347; Sat, 4 Aug 2001 11:09:40 +1000 (AEST) Date: Sat, 4 Aug 2001 11:09:40 +1000 From: Nathan Scott To: Grant Erickson Cc: linux-xfs@oss.sgi.com Subject: Re: PATCH: xfsprogs-1.3.1/configure.in - Cross Compilation Message-ID: <20010804110940.A265207@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gerickso@brocade.com on Fri, Aug 03, 2001 at 10:31:44AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Fri, Aug 03, 2001 at 10:31:44AM -0700, Grant Erickson wrote: > Below is a patch to allow the xfsprogs-1.3.1/configure script to work > correctly (at least mostly correctly) when cross-compiling ... Thanks for the patch - I tried it out with a local build and it works just fine, but produces these warnings: $ autoconf --version Autoconf version 2.13 $ autoconf $ ./configure configure.in:187: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:188: warning: AC_TRY_RUN called without default to allow cross compiling ./configure loading cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes ...[snip]... Which is from here in your patch: > +AC_CHECK_SIZEOF(long) > +AC_CHECK_SIZEOF(char *) I've made a couple of adjustments to work around this, and checked the changes in - let me know if it still works as you expected. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Aug 3 20:11:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f743BeH30831 for linux-xfs-outgoing; Fri, 3 Aug 2001 20:11:40 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f743BaV30805 for ; Fri, 3 Aug 2001 20:11:36 -0700 Received: (qmail 21418 invoked from network); 4 Aug 2001 03:11:26 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 4 Aug 2001 03:11:26 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Matt Ryan cc: linux-xfs@oss.sgi.com Subject: Re: gcc versions In-reply-to: Your message of "Fri, 03 Aug 2001 11:52:58 MST." <3B6AF30A.E007E454@sigmastorage.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Aug 2001 13:11:25 +1000 Message-ID: <25243.996894685@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 03 Aug 2001 11:52:58 -0700, Matt Ryan wrote: >I see this in the FAQ: > > "If you are using gcc 3.0 and it gives problems or does not compile, >drop a note on the list with the oops and ksymoops output. We will be >working on getting XFS fully functional with gcc 3.0. " > > >does that mean the XFS team is planning on transitioning to 3.0 as the >'official' compiler in the near future? I ask because seeing something >like this: > > "egcs-1.1.2 aka kgcc wont build 2.4.7 it seems." >(from http://uwsg.iu.edu/hypermail/linux/kernel/0108.0/0309.html) > >makes me a little nervous. That mail was incorrect, kgcc compiles 2.4.7 quite happily. There may have been one bit of code that failed on kgcc but it was rewritten. To answer the broader question, XFS will transition to gcc 3.0 at some time. But that will probably not occur before the main kernel is verified on gcc 3.0 so until Linus says that 3.0 is safe, stick to kgcc. OTOH I have to use gcc 3.0 for IA64 2.4.7, that needs bleeding edge compilers. From owner-linux-xfs@oss.sgi.com Fri Aug 3 23:45:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f746jvN26708 for linux-xfs-outgoing; Fri, 3 Aug 2001 23:45:57 -0700 Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f746jsV26686 for ; Fri, 3 Aug 2001 23:45:55 -0700 Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id IAA12435 for ; Sat, 4 Aug 2001 08:45:47 +0200 (MEST) Message-ID: <3B6B9A86.6000406@dumballah.tvnet.hu> Date: Sat, 04 Aug 2001 08:47:34 +0200 From: Sipos Ferenc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: redhat 7.2 beta Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Did anybody make an xfs enabled through network installable roswell distro? Paco From owner-linux-xfs@oss.sgi.com Sat Aug 4 01:12:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f748CaY04690 for linux-xfs-outgoing; Sat, 4 Aug 2001 01:12:36 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f748CWV04668 for ; Sat, 4 Aug 2001 01:12:32 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id KAA01430; Sat, 4 Aug 2001 10:12:23 +0200 (CEST) Message-Id: <4.3.2.7.2.20010804100619.03367ee0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 04 Aug 2001 10:11:59 +0200 To: Matt Ryan , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: gcc versions In-Reply-To: <3B6AF30A.E007E454@sigmastorage.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:52 3-8-2001 -0700, Matt Ryan wrote: >hi - > >I see this in the FAQ: > > "If you are using gcc 3.0 and it gives problems or does not compile, >drop a note on the list with the oops and ksymoops output. We will be >working on getting XFS fully functional with gcc 3.0. " > > >does that mean the XFS team is planning on transitioning to 3.0 as the >'official' compiler in the near future? I ask because seeing something >like this: No, we need testing (and lot's of it) to make sure that gcc 3 compiles kernel and xfs in specific right. If that happens < half a year from now I would be surprised. Don't get me wrong. XFS kernels work fine when compiled with gcc 3 but it has just not had enough testing to use it in production yet and a recommendation for others. > "egcs-1.1.2 aka kgcc wont build 2.4.7 it seems." >(from http://uwsg.iu.edu/hypermail/linux/kernel/0108.0/0309.html) > >makes me a little nervous. I don't really know what to make of that >since I've compiled 2.4.7 + XFS with kgcc (as have everybody else I'm >sure), but I wonder how much longer it'll be viable. It depends on the code used in the kernel. XFS has only been tested so far with egcs 1.1.2. That is because they started developing xfs on redhat 6.2, which ships with egcs 1.1.2 Surely there will be problems with stuff not compiling correctly but that other things start miscompiling when changing the compiler. It is just moving the problem around. >Matt -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Aug 4 01:16:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f748G7a05185 for linux-xfs-outgoing; Sat, 4 Aug 2001 01:16:07 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f748G5V05163 for ; Sat, 4 Aug 2001 01:16:05 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id KAA03620; Sat, 4 Aug 2001 10:15:59 +0200 (CEST) Message-Id: <4.3.2.7.2.20010804101353.03e73c78@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 04 Aug 2001 10:15:36 +0200 To: Sipos Ferenc , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: redhat 7.2 beta In-Reply-To: <3B6B9A86.6000406@dumballah.tvnet.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:47 4-8-2001 +0200, Sipos Ferenc wrote: >Hi! > >Did anybody make an xfs enabled through network installable roswell distro? We don't do beta installers. When 7.2 ships we will put a new XFS release and installer out. So a bit of patience. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Aug 4 02:00:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f74906Z10383 for linux-xfs-outgoing; Sat, 4 Aug 2001 02:00:06 -0700 Received: from thumper.technologeek.org (root@thumper.technologeek.org [62.4.21.145]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f74901V10336 for ; Sat, 4 Aug 2001 02:00:01 -0700 Received: from thumper.technologeek.org (julien@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id f748xrhP008475 for ; Sat, 4 Aug 2001 10:59:53 +0200 Received: (from julien@localhost) by thumper.technologeek.org (8.12.0.Beta16/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f748xqrp008470; Sat, 4 Aug 2001 10:59:52 +0200 X-Authentication-Warning: thumper.technologeek.org: julien set sender to jb@jblache.org using -f To: linux-xfs@oss.sgi.com Subject: oops with 2.4.7-xfs during find From: Julien BLACHE Date: 04 Aug 2001 10:59:32 +0200 Message-ID: <877kwki4jv.fsf@thumper.technologeek.org> Lines: 75 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I got a kernel oops this night while cron was running a find on my disks. I use a 2.4.7 kernel from the XFS CVS as of 20010722 14:54 (GMT). I don't use lvm, raid or anything, the kernel was compiled with gcc-2.96 from Debian unstable. The chipset is a Via KT133A. ksymoops output : kernel BUG at vmscan.c:395! invalid operand: 0000 CPU: 0 EIP: 0010:[reclaim_page+891/1008] EFLAGS: 00010286 eax: 0000001c ebx: c161deb8 ecx: df22a000 edx: de32b780 esi: d72bf724 edi: c161de9c ebp: 00000000 esp: df22bd4c ds: 0018 es: 0018 ss: 0018 Process find (pid: 3287, stackpage=df22b000) Stack: c029ccd0 c029cdee 0000018b c02f2794 c02f2900 00000001 00000000 c012b7cc c02f2794 00000000 c02f2908 00000000 000000f0 c012b8ed c02f28fc 00000000 00000001 00000001 000000f0 000000f0 c1887e6c 000000f0 00000001 c02f28fc Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 31 c0 0f b3 47 18 19 c0 85 c0 75 19 68 8c 01 Using defaults from ksymoops -t elf32-i386 -a i386 Trace; c012b7cc <__alloc_pages_limit+6c/90> Trace; c012b8ed <__alloc_pages+dd/280> Trace; c012b806 <_alloc_pages+16/20> Trace; c012ba9a <__get_free_pages+a/20> Trace; c012894c Trace; c0128ae9 Trace; c014413c Trace; c01443e6 Trace; c019dd47 Trace; c01b371c Trace; c01b7fa7 Trace; c01c1505 Trace; c013aad3 Trace; c013b191 Trace; c013a84d Trace; c013b78c <__user_walk+3c/60> Trace; c0138916 Trace; c0130d23 Trace; c0106e4b Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 0f 0b ud2a Code; 00000002 Before first symbol 2: 83 c4 0c add $0xc,%esp Code; 00000005 Before first symbol 5: 31 c0 xor %eax,%eax Code; 00000007 Before first symbol 7: 0f b3 47 18 btr %eax,0x18(%edi) Code; 0000000b Before first symbol b: 19 c0 sbb %eax,%eax Code; 0000000d Before first symbol d: 85 c0 test %eax,%eax Code; 0000000f Before first symbol f: 75 19 jne 2a <_EIP+0x2a> 0000002a Before first symbol Code; 00000011 Before first symbol 11: 68 8c 01 00 00 push $0x18c Hope this helps. Regards, -- Julien BLACHE. From owner-linux-xfs@oss.sgi.com Sat Aug 4 06:47:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f74Dlqv14938 for linux-xfs-outgoing; Sat, 4 Aug 2001 06:47:52 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f74DloV14916 for ; Sat, 4 Aug 2001 06:47:50 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA03530 for ; Sat, 4 Aug 2001 06:47:29 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id XAA23220; Sat, 4 Aug 2001 23:47:39 +1000 Date: Sat, 4 Aug 2001 23:47:39 +1000 From: Keith Owens Message-Id: <200108041347.XAA23220@sherman.melbourne.sgi.com> Subject: TAKE - Remove relative includes from kdb Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Relative includes (#include "../../scsi.h") are an abomination. They embed assumptions about the tree structure in the source code. If you want to include a file outside the normal path, use #include with -I $(TOPDIR)/drivers/scsi in the Makefile. Then source can be moved with just Makefile changes. Date: Sat Aug 4 06:43:36 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100215a linux/kdb/modules/kdbm_vm.c - 1.11 linux/kdb/modules/Makefile - 1.10 From owner-linux-xfs@oss.sgi.com Sat Aug 4 12:59:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f74JxSi12277 for linux-xfs-outgoing; Sat, 4 Aug 2001 12:59:28 -0700 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 f74JxLV12243 for ; Sat, 4 Aug 2001 12:59:22 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 4B7F7C08368 for ; Sun, 5 Aug 2001 03:58:54 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id C49EBC02807 for ; Sun, 5 Aug 2001 03:58:50 +0800 (PHT) Date: Sun, 5 Aug 2001 03:58:50 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: ACLs Revisited 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 everyone, I hope the developers will not mind my revisiting of ACL implementation on XFS. A little overview: the current system has an entire tree of data shared via a Samba server without ACLs, but handling its own "fine grained" permissions via the "valid users", "read list", and "write list" parameters defined per share. I am attempting to migrate this system so that there will be fine-grained permissions via XFS ACLs, to be shared via both Samba and NFS simultaneously. My initial thought was to create two groups per existing Samba share: share-ro, share-rw. This assumes that the shares are not world-readable and/or world-writable, but I will have to tackle that (these are rough thoughts). Then I can use ACLs to provide the read-only and read-write permissions for these two groups. On major drawback I noticed with this, though, is that changes to the groups are not implemented immediately. This can be bad in a number of situations. Skipping the groups altogether and listing the users one-by-one in the ACLs is a stricter way of implementing things. I do not know how this can be managed in the long-term, though. With pure Samba, I just had to read the smb.conf and make sure that the "ACLs" there were correct. A Samba reload immediately effected the changes. I was thinking of creating some script, that would store the ACLs for each share, so that it is this that can be checked periodically to make sure that the permissions are correct. When paranoid, this script (which contains the ACLs) could be run, which would then "synchronize" the actual ACLs with those stored on-script. I'm not quite sure how to attack this, though, and do not know if this is really how ACLs are supposed to be managed. I'm sure ACLs are not new to XFS, although both ACLs as well as XFS are relatively new to Linux. Maybe someone out there has done a similar medium-scale (I don't consider this setup large-scale) implementation of ACLs? I am completely in the dark as far as how this is done "the right way". As far as Samba and ACLs are concerned, I'm even more in the dark. I've read that with ACL support certain Windows-based ACL editting tools can be used. Are there any other benefits aside from this? These aren't directly XFS-related anymore, but I am hoping that someone on the list has done something like this and is willing to share some light with a newbie (as far as ACLs are concerned). Also I noticed that the recently-implemented recursion of chacl can't be compounded with say, '-b' to recursively set both default as well as file access permissions. I'm not complaining, though, as thanks to previous responders I've found out that I can use find and/or find + xargs to do the recursion work. Thanks in advance! --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sat Aug 4 22:34:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f755YD726480 for linux-xfs-outgoing; Sat, 4 Aug 2001 22:34:13 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f755Y7V26445 for ; Sat, 4 Aug 2001 22:34:08 -0700 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 HAA618767 for ; Sun, 5 Aug 2001 07:33:46 +0200 (CEST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA19759; Sun, 5 Aug 2001 15:34:01 +1000 Date: Sun, 5 Aug 2001 15:34:01 +1000 From: Keith Owens Message-Id: <200108050534.PAA19759@sherman.melbourne.sgi.com> Subject: TAKE - Sync XFS to 2.4.8-pre4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sync XFS to 2.4.8-pre4 Date: Sat Aug 4 22:32:15 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100218a linux/arch/ia64/kernel/sigframe.h - 1.1 linux/drivers/video/aty/mach64_gx.c - 1.1 linux/arch/ia64/kernel/irq_lsapic.c - 1.1 linux/drivers/video/aty/Makefile - 1.1 linux/drivers/video/aty/atyfb.h - 1.1 linux/drivers/video/aty/atyfb_base.c - 1.1 linux/drivers/video/aty/mach64.h - 1.1 linux/drivers/video/aty/mach64_accel.c - 1.1 linux/drivers/video/aty/mach64_ct.c - 1.1 linux/drivers/video/aty/mach64_cursor.c - 1.1 linux/arch/ia64/ia32/ia32_ldt.c - 1.1 linux/net/core/dev.c - 1.39 linux/mm/vmscan.c - 1.65 linux/mm/page_alloc.c - 1.48 linux/include/linux/sockios.h - 1.7 linux/include/linux/dcache.h - 1.19 linux/include/linux/blkdev.h - 1.34 linux/include/asm-i386/softirq.h - 1.12 linux/fs/inode.c - 1.46 linux/fs/dcache.c - 1.27 linux/fs/buffer.c - 1.74 linux/drivers/video/atyfb.c - 1.31 linux/drivers/video/aty.h - 1.8 linux/drivers/video/Makefile - 1.32 linux/drivers/video/Config.in - 1.27 linux/drivers/block/ll_rw_blk.c - 1.73 linux/Makefile - 1.109 linux/MAINTAINERS - 1.65 linux/Documentation/Configure.help - 1.92 linux/drivers/scsi/scsi_lib.c - 1.33 linux/arch/ia64/kernel/head.S - 1.8 linux/arch/ia64/kernel/gate.S - 1.7 linux/arch/ia64/kernel/fw-emu.c - 1.7 linux/arch/ia64/kernel/entry.h - 1.4 linux/arch/ia64/kernel/entry.S - 1.15 linux/arch/ia64/kernel/efi.c - 1.11 linux/arch/ia64/kernel/acpi.c - 1.9 linux/arch/ia64/kernel/Makefile - 1.10 linux/arch/ia64/ia32/sys_ia32.c - 1.16 linux/arch/ia64/ia32/ia32_support.c - 1.5 linux/arch/ia64/ia32/ia32_entry.S - 1.12 linux/arch/ia64/ia32/binfmt_elf32.c - 1.11 linux/arch/ia64/ia32/Makefile - 1.7 linux/arch/ia64/hp/hpsim_setup.c - 1.4 linux/arch/ia64/vmlinux.lds.S - 1.7 linux/arch/ia64/tools/print_offsets.c - 1.7 linux/arch/ia64/config.in - 1.18 linux/arch/ia64/boot/bootloader.c - 1.5 linux/arch/ia64/Makefile - 1.9 linux/arch/ia64/kernel/irq.c - 1.13 linux/arch/ia64/kernel/setup.c - 1.9 linux/arch/ia64/kernel/signal.c - 1.9 linux/arch/ia64/kernel/smp.c - 1.9 linux/arch/ia64/kernel/sys_ia64.c - 1.8 linux/arch/ia64/kernel/time.c - 1.10 linux/arch/ia64/kernel/traps.c - 1.10 linux/arch/ia64/kernel/unaligned.c - 1.8 linux/arch/ia64/kernel/unwind.c - 1.8 linux/arch/ia64/lib/Makefile - 1.8 linux/arch/ia64/kernel/ivt.S - 1.11 linux/arch/ia64/lib/checksum.c - 1.2 linux/arch/ia64/lib/clear_page.S - 1.4 linux/arch/ia64/lib/clear_user.S - 1.5 linux/arch/ia64/lib/copy_page.S - 1.5 linux/arch/ia64/lib/copy_user.S - 1.9 linux/arch/ia64/lib/csum_partial_copy.c - 1.3 linux/arch/ia64/kernel/pci.c - 1.7 linux/arch/ia64/lib/do_csum.S - 1.4 linux/arch/ia64/kernel/ptrace.c - 1.11 linux/arch/ia64/kernel/process.c - 1.9 linux/arch/ia64/kernel/perfmon.c - 1.7 linux/arch/ia64/mm/tlb.c - 1.8 linux/arch/ia64/kernel/mca.c - 1.7 linux/arch/ia64/mm/init.c - 1.10 linux/arch/ia64/mm/extable.c - 1.3 linux/arch/ia64/kernel/mca_asm.S - 1.7 linux/include/asm-ia64/sigcontext.h - 1.3 linux/include/asm-ia64/iosapic.h - 1.4 linux/include/asm-ia64/io.h - 1.7 linux/include/asm-ia64/ia32.h - 1.9 linux/include/asm-ia64/hardirq.h - 1.10 linux/include/asm-ia64/fpswa.h - 1.3 linux/include/asm-ia64/efi.h - 1.7 linux/include/asm-ia64/bitops.h - 1.6 linux/include/asm-ia64/acpi-ext.h - 1.5 linux/include/asm-ia64/a.out.h - 1.4 linux/include/asm-ia64/mca_asm.h - 1.4 linux/include/asm-ia64/smp.h - 1.8 linux/include/asm-ia64/sal.h - 1.7 linux/include/asm-ia64/processor.h - 1.12 linux/include/asm-ia64/pgtable.h - 1.12 linux/include/asm-ia64/pgalloc.h - 1.7 linux/include/asm-ia64/softirq.h - 1.5 linux/include/asm-ia64/offsets.h - 1.10 linux/include/asm-ia64/ptrace_offsets.h - 1.6 linux/include/asm-ia64/ptrace.h - 1.8 linux/include/asm-ia64/spinlock.h - 1.7 linux/include/asm-ia64/unistd.h - 1.12 linux/include/asm-ia64/signal.h - 1.2 linux/include/asm-ia64/unwind.h - 1.5 linux/include/asm-ia64/unaligned.h - 1.3 linux/include/asm-ia64/system.h - 1.9 linux/include/asm-ia64/string.h - 1.4 linux/include/asm-ia64/hw_irq.h - 1.6 linux/arch/ia64/kernel/irq_ia64.c - 1.9 linux/arch/ia64/kernel/smpboot.c - 1.4 linux/arch/ia64/kernel/minstate.h - 1.6 linux/arch/ia64/kernel/irq_sapic.c - 1.2 linux/arch/ia64/kernel/ia64_ksyms.c - 1.6 linux/arch/ia64/kernel/unwind_i.h - 1.3 linux/include/asm-ia64/acpikcfg.h - 1.4 linux/arch/ia64/kernel/iosapic.c - 1.3 linux/arch/ia64/lib/swiotlb.c - 1.3 linux/arch/ia64/sn/fprom/fw-emu.c - 1.3 linux/arch/ia64/sn/io/ml_SN_intr.c - 1.3 linux/include/linux/reiserfs_fs.h - 1.7 linux/arch/ia64/kernel/efivars.c - 1.2 linux/fs/partitions/ldm.h - 1.2 From owner-linux-xfs@oss.sgi.com Sun Aug 5 04:53:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f75Brf728615 for linux-xfs-outgoing; Sun, 5 Aug 2001 04:53:41 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f75BrdV28595 for ; Sun, 5 Aug 2001 04:53:39 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id EAA04519 for ; Sun, 5 Aug 2001 04:51:26 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id VAA20253; Sun, 5 Aug 2001 21:53:28 +1000 Date: Sun, 5 Aug 2001 21:53:28 +1000 From: Keith Owens Message-Id: <200108051153.VAA20253@sherman.melbourne.sgi.com> Subject: TAKE - kbuild 2.5 support for XFS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Add XFS specific files for kbuild 2.5 support to the XFS tree. This is not the full kbuild 2.5 code, just the XFS and KDB specific bits. 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.8-pre4-1.gz. 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 # zcat ~/kbuild-2.5-2.4.8-pre4-1.gz | 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: Sun Aug 5 03:50:40 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100219a linux/Makefile.in.append - 1.1 linux/arch/i386/kdb/Makefile.in - 1.1 linux/fs/Makefile.in.append - 1.1 linux/fs/pagebuf/Makefile.in - 1.1 linux/fs/xfs/Makefile.in - 1.1 linux/fs/xfs/dmapi/Makefile.in - 1.1 linux/fs/xfs/linux/Makefile.in - 1.1 linux/fs/xfs_support/Makefile.in - 1.1 linux/kdb/Makefile.in - 1.1 linux/kdb/modules/Makefile.in - 1.1 linux/kernel/Makefile.in.append - 1.1 From owner-linux-xfs@oss.sgi.com Sun Aug 5 05:57:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f75CvBZ01844 for linux-xfs-outgoing; Sun, 5 Aug 2001 05:57:11 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f75Cv8V01821 for ; Sun, 5 Aug 2001 05:57:09 -0700 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 OAA640729 for ; Sun, 5 Aug 2001 14:56:18 +0200 (CEST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id WAA28961; Sun, 5 Aug 2001 22:56:28 +1000 Date: Sun, 5 Aug 2001 22:56:28 +1000 From: Keith Owens Message-Id: <200108051256.WAA28961@sherman.melbourne.sgi.com> Subject: TAKE - Missing kbuild 2.5 file Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Missing kbuild 2.5 file Date: Sun Aug 5 05:55:19 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100220a linux/Makefile.in.prepend - 1.1 From owner-linux-xfs@oss.sgi.com Sun Aug 5 06:27:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f75DR2l03558 for linux-xfs-outgoing; Sun, 5 Aug 2001 06:27:02 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f75DQxV03539 for ; Sun, 5 Aug 2001 06:27:00 -0700 Received: (qmail 763 invoked from network); 5 Aug 2001 13:25:14 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Aug 2001 13:25:14 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: TAKE - kbuild 2.5 support for XFS In-reply-to: Your message of "Sun, 05 Aug 2001 21:53:28 +1000." <200108051153.VAA20253@sherman.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Aug 2001 23:25:13 +1000 Message-ID: <27286.997017913@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 5 Aug 2001 21:53:28 +1000, Keith Owens wrote: >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.8-pre4-1.gz. It was tested on a local copy of kbuild-2.5-2.4.8-pre4-1.gz but the version on the server is corrupt. I have deleted -1 from the server and uploaded -2, identical patch but -2 unzips correctly. From owner-linux-xfs@oss.sgi.com Sun Aug 5 19:49:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f762nwP21247 for linux-xfs-outgoing; Sun, 5 Aug 2001 19:49:58 -0700 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 f762nsV21228 for ; Sun, 5 Aug 2001 19:49:54 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f762tCW07185 for ; Sun, 5 Aug 2001 19:55:12 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA57077 for linux-xfs@oss.sgi.com; Mon, 6 Aug 2001 12:48:31 +1000 (EST) Date: Mon, 6 Aug 2001 12:48:31 +1000 (EST) From: Nathan Scott Message-Id: <200108060248.MAA57077@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - getfacl/setfacl Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 03, 2001 at 01:51:30PM +1000, Timothy Shimmin wrote: > > > > Are there any other utilities other than chacl for managing the ACLs? > > > Nathan Scott will soon check in ported versions of Andreas' > setfacl and getfacl ACL commands. > (Currently, you'll need to preserve an ACE ordering in ACL specification > for setfacl; > however, I'll look into fixing this problem when the > code is checked in). > Yes, that is the one remaining issue, AFAICT. Flushing my workarea backlog and handing this over to you - thanks Tim. Here's the CHANGES entry: - incorporated setfacl(1) and getfacl(1) tools, written by Andreas Gruenbacher - added the extra libacl routines needed in order for these tools to properly function - [this should ensure the two libacl implementations (ext2/xfs) don't drift apart in incompatible ways and will also provide similar ACL tools for both - a single userspace is still the longer-term goal, but will require a common system call API] - fixup some man page typos - rearrange headers to better separate user/kernel - failed syscall returns ENOSYS, no longer writes to stderr cheers. Date: Sun Aug 5 19:41:49 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100225a cmd/acl/facl/setfacl.c - 1.1 cmd/acl/man/man1/setfacl.1 - 1.1 cmd/acl/man/man1/getfacl.1 - 1.1 - add in Andreas Gruenbacher's ACL userspace tools, unchanged. cmd/acl/libacl/text.c - 1.1 - add in some additional routines to support getfacl/setfacl, and narrow the gap between the XFS and ext2 libacl implementations. cmd/acl/facl/Makefile - 1.1 - add in Andreas Gruenbacher's ACL userspace tools, unchanged. cmd/acl/libacl/libacl.c - 1.1 - add in some additional routines to support getfacl/setfacl, and narrow the gap between the XFS and ext2 libacl implementations. cmd/acl/include/libacl.h - 1.1 - install headers the same way the ext2/ACL project do. cmd/acl/facl/walk_tree.h - 1.1 cmd/acl/facl/walk_tree.c - 1.1 cmd/acl/facl/getfacl.c - 1.1 cmd/acl/facl/do_set.c - 1.1 cmd/acl/facl/sequence.c - 1.1 cmd/acl/facl/parse.c - 1.1 cmd/acl/facl/parse.h - 1.1 cmd/acl/facl/sequence.h - 1.1 cmd/acl/facl/user_group.h - 1.1 cmd/acl/facl/user_group.c - 1.1 cmd/acl/configure.in - 1.9 - add in Andreas Gruenbacher's ACL userspace tools, unchanged. cmd/acl/man/man5/acl.5 - 1.6 - one-line change for clarity. cmd/acl/libacl/Makefile - 1.3 - add in some additional routines to support getfacl/setfacl, and narrow the gap between the XFS and ext2 libacl implementations. cmd/acl/Makefile - 1.3 cmd/acl/README - 1.2 cmd/acl/VERSION - 1.12 cmd/acl/debian/changelog - 1.7 cmd/acl/build/rpm/acl.spec.in - 1.3 cmd/acl/doc/COPYING - 1.2 - add in Andreas Gruenbacher's ACL userspace tools, unchanged. cmd/acl/libacl/acl.c - 1.13 - mostly cosmetic cleanup to make this code consistent with itself (use same brakets, spacing, etc throughout). cmd/acl/debian/control - 1.4 cmd/acl/doc/CHANGES - 1.14 - add in Andreas Gruenbacher's ACL userspace tools, unchanged. cmd/acl/include/builddefs.in - 1.12 - install headers the same way the ext2/ACL project do. cmd/acl/include/acl.h - 1.7 - fix up to remove namespace pollution and XFS-specific macros, etc. cmd/acl/include/Makefile - 1.2 - install headers the same way the ext2/ACL project do. From owner-linux-xfs@oss.sgi.com Sun Aug 5 21:18:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f764Ikp23910 for linux-xfs-outgoing; Sun, 5 Aug 2001 21:18:46 -0700 Received: from laxmls03.socal.rr.com (laxmls03.socal.rr.com [24.30.163.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f764IhV23891 for ; Sun, 5 Aug 2001 21:18:43 -0700 Received: from GHARLANE (bak-66-74-126-199.bak.rr.com [66.74.126.199]) by laxmls03.socal.rr.com (8.11.4/8.11.3) with SMTP id f764IU604838 for ; Sun, 5 Aug 2001 21:18:31 -0700 (PDT) Message-Id: <200108060418.f764IU604838@laxmls03.socal.rr.com> From: sgarcia@bak.rr.com Date: Sun, 05 Aug 2001 21:16:15 -0400 To: linux-xfs@oss.sgi.com Subject: Problem with XFS 1.01 / RedHat 7.1 install X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.25/25 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm having some difficulty with a new install using XFS1.01 and RedHat 7.1. Everything seems to go along fine until it asks for the RedHat disc 1. I get a popup telling me "That's not the correct CDROM". I've put the CD into another machine and confirmed that it is disc1 of the RedHat 7.1 set. I've installed XFS 1.0 on several machines (including this one) with minimal problems. Is there a problem with the install disc for 1.01, or am I likely doing something wrong? I would have just tried to update my kernel, but I've toasted X on this thing, so rather than fool with that for days, I figured a fresh install might be just the ticket. Thanks! Steve Garcia -- ----------------------------------------------------------- Steve Garcia using MR/2 ICE #10133 with Warp 4 sgarcia@bak.rr.com ----------------------------------------------------------- * All true wisdom is found on T-shirts. From owner-linux-xfs@oss.sgi.com Sun Aug 5 21:55:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f764te525295 for linux-xfs-outgoing; Sun, 5 Aug 2001 21:55:40 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f764taV25269 for ; Sun, 5 Aug 2001 21:55:37 -0700 Received: (qmail 6606 invoked from network); 6 Aug 2001 04:55:34 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Aug 2001 04:55:34 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: sgarcia@bak.rr.com cc: linux-xfs@oss.sgi.com Subject: Re: Problem with XFS 1.01 / RedHat 7.1 install In-reply-to: Your message of "Sun, 05 Aug 2001 21:16:15 -0400." <200108060418.f764IU604838@laxmls03.socal.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Aug 2001 14:55:32 +1000 Message-ID: <572.997073732@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 05 Aug 2001 21:16:15 -0400, sgarcia@bak.rr.com wrote: >I'm having some difficulty with a new install using XFS1.01 and RedHat >7.1. Everything seems to go along fine until it asks for the RedHat disc >1. I get a popup telling me "That's not the correct CDROM". I've put the >CD into another machine and confirmed that it is disc1 of the RedHat 7.1 >set. Did you get the CD direct from Redhat or from a reseller like Dell? http://marc.theaimsgroup.com/?l=linux-xfs&m=99548665305622&w=2 might be useful. From owner-linux-xfs@oss.sgi.com Sun Aug 5 23:13:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f766Diu26660 for linux-xfs-outgoing; Sun, 5 Aug 2001 23:13:44 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f766DfV26641 for ; Sun, 5 Aug 2001 23:13:41 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 48D70C001FD; Mon, 6 Aug 2001 14:13:36 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id E8645C00AC6; Mon, 6 Aug 2001 14:13:34 +0800 (PHT) Date: Mon, 6 Aug 2001 14:13:34 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Cc: Linux 3Ware Support Subject: corrupt inode 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 everyone, Today's my "ghost in the machine" day. First one of the drives in my four-disk RAID5 fails. So far the three are okay so I'm surviving. I'm using a 3ware Escalade 6400 controller with: o Montior version ME6X 1.01.00.028 o Firmware version FE6X 1.02.03.053 o BIOS version BE6X 1.07.01.015 AFAIK this doesn't have that RAID5 degraded problem. I'm using Linux kernel 2.4.7 with XFS. I got the following error: Aug 6 14:05:18 gusi kernel: cmn_err level 4 Filesystem "sd(8,11)": corrupt inode 21967679 (btree). Unmount and run xfs_repair. Aug 6 14:05:35 gusi kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Aug 6 14:05:35 gusi kernel: printing eip: Aug 6 14:05:35 gusi kernel: c01e7385 Aug 6 14:05:35 gusi kernel: *pde = 00000000 Aug 6 14:05:35 gusi kernel: Oops: 0000 Aug 6 14:05:35 gusi kernel: CPU: 0 Aug 6 14:05:35 gusi kernel: EIP: 0010:[xfs_iget+229/300] Aug 6 14:05:35 gusi kernel: EFLAGS: 00010246 Aug 6 14:05:35 gusi kernel: eax: 00000000 ebx: ffffffe8 ecx: c0341944 edx: c0347a40 Aug 6 14:05:35 gusi kernel: esi: c592d52c edi: df936800 ebp: 00000000 esp: d096dc1c Aug 6 14:05:35 gusi kernel: ds: 0018 es: 0018 ss: 0018 Aug 6 14:05:35 gusi kernel: Process bash (pid: 4924, stackpage=d096d000) Aug 6 14:05:35 gusi kernel: Stack: 00000005 d89ea63c 00000000 00000004 c01fc3fc df936800 00000000 014f333f Aug 6 14:05:35 gusi kernel: 00000000 00000000 d096dcf4 00000000 00000000 d89ea654 00000000 df936800 Aug 6 14:05:35 gusi kernel: 00000029 00000000 00000010 c18867c8 c7927960 c0201141 00000000 d89ea654 Aug 6 14:05:35 gusi kernel: Call Trace: [xfs_dir_lookup_int+292/656] [xfs_create+1389/2692] [linvfs_common_cr+287/556] [xfs_acl_iaccess+44/136] [tcp_transmit_skb+966/1292] [n_tty_receive_buf+3745/3804] [n_tty_receive_buf+3745/3804] Aug 6 14:05:35 gusi kernel: [tcp_v4_do_rcv+114/336] [schedule+606/916] [linvfs_create+24/28] [vfs_create+153/204] [open_namei+382/1488] [filp_open+59/92] [sys_open+56/184] [system_call+51/56] Aug 6 14:05:35 gusi kernel: Aug 6 14:05:35 gusi kernel: Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 d4 It's the middle of the day and everyone's working but I told them all to shut down. I'm sending this message then I'm unmounting and running xfs_repair. I've got my fingers crossed. I hope nothing will mess up. I hope to be able to get back to the list about this after. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sun Aug 5 23:36:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f766aCo27143 for linux-xfs-outgoing; Sun, 5 Aug 2001 23:36:12 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f766ZpV27124 for ; Sun, 5 Aug 2001 23:35:51 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 03DFFC08285 for ; Mon, 6 Aug 2001 14:35:47 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 1B5E7C00AC6 for ; Mon, 6 Aug 2001 14:35:44 +0800 (PHT) Date: Mon, 6 Aug 2001 14:35:44 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: corrupt inode In-Reply-To: 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 [WARNING: LONG MESSAGE] On Mon, 6 Aug 2001 at 14:13, Federico Sevilla III wrote: > Aug 6 14:05:18 gusi kernel: cmn_err level 4 Filesystem "sd(8,11)": > corrupt inode 21967679 (btree). Unmount and run xfs_repair. I tried unmounting /home but could not because of some hung up processes thanks to what caused this oops. So I restarted the computer (clean shutdown). It remounted /dev/sda11 read only as it could not unmount it. Then I booted with init=/bin/sh, ran devfs (fortunately or unfortunately I use it) so that my /dev gets populated, and ran xfs_repair. I ran it first with the "-n" flag and saw that it had a lot of output so I ran the real xfs_repair via nohup. Here are the contents of the nohup.out that resulted from scanning /dev/sda11 (my home partition): I include everything because I don't know what's of use and what's not of use. I will send a second message with some questions, comments, et al (read: I won't type anything after you see this quoted xfs_repair output): $ xfs_repair /dev/sda11 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 bad inode format in inode 21967648 bad magic number 0x764e on inode 21967649 bad version number 0x7 on inode 21967649 bad (negative) size -7926335343115108092 on inode 21967649 bad magic number 0x434e on inode 21967650 bad version number 0xb on inode 21967650 bad magic number 0x484e on inode 21967651 bad (negative) size -5836665117055380587 on inode 21967651 bad magic number 0xf04e on inode 21967652 bad version number 0x0 on inode 21967652 bad magic number 0x484c on inode 21967653 bad version number 0xffffffad on inode 21967653 bad magic number 0x434e on inode 21967654 bad version number 0xb on inode 21967654 bad magic number 0x414c on inode 21967655 bad version number 0xffffffcd on inode 21967655 bad inode format in inode 21967655 bad magic number 0x494f on inode 21967656 bad version number 0x9 on inode 21967656 bad inode format in inode 21967656 bad magic number 0x4f4e on inode 21967657 bad magic number 0x434e on inode 21967658 bad version number 0xb on inode 21967658 bad inode format in inode 21967659 bad magic number 0x484e on inode 21967660 bad (negative) size -360287970172858200 on inode 21967660 bad magic number 0xa34e on inode 21967661 bad version number 0x3e on inode 21967661 bad magic number 0x434e on inode 21967662 bad version number 0xb on inode 21967662 bad magic number 0x424f on inode 21967663 bad version number 0x0 on inode 21967663 bad magic number 0x414c on inode 21967664 bad version number 0x19 on inode 21967664 bad inode format in inode 21967664 bad version number 0x0 on inode 21967665 bad inode format in inode 21967665 bad magic number 0x434e on inode 21967666 bad version number 0xb on inode 21967666 bad magic number 0x494f on inode 21967667 bad version number 0x9 on inode 21967667 bad inode format in inode 21967668 bad magic number 0x764e on inode 21967669 bad version number 0x7 on inode 21967669 bad magic number 0x434e on inode 21967670 bad version number 0xb on inode 21967670 bad magic number 0x484e on inode 21967671 bad inode format in inode 21967671 bad magic number 0x1e4f on inode 21967672 bad version number 0x0 on inode 21967672 bad magic number 0x484c on inode 21967673 bad version number 0x49 on inode 21967673 bad magic number 0x434e on inode 21967674 bad version number 0xb on inode 21967674 bad magic number 0x414c on inode 21967675 bad version number 0x6b on inode 21967675 bad inode format in inode 21967675 bad magic number 0x494f on inode 21967676 bad version number 0x9 on inode 21967676 bad inode format in inode 21967676 bad magic number 0x4f4e on inode 21967677 bad inode format in inode 21967677 bad magic number 0x254c on inode 21967678 bad version number 0xb on inode 21967678 bad magic number 0x484e on inode 21967680 bad (negative) size -7421650710913085158 on inode 21967680 bad magic number 0xcf4f on inode 21967681 bad version number 0x3e on inode 21967681 bad magic number 0x9e4e on inode 21967682 bad version number 0xffffffc1 on inode 21967682 bad inode format in inode 21967682 bad magic number 0xe04f on inode 21967683 bad version number 0x0 on inode 21967683 bad magic number 0x414c on inode 21967684 bad version number 0xffffffb7 on inode 21967684 bad inode format in inode 21967684 bad version number 0x0 on inode 21967685 bad inode format in inode 21967685 bad magic number 0x4f4e on inode 21967686 bad inode format in inode 21967686 bad magic number 0x494f on inode 21967687 bad version number 0x9 on inode 21967687 bad inode format in inode 21967687 bad inode format in inode 21967688 bad magic number 0x764e on inode 21967689 bad version number 0x7 on inode 21967689 bad (negative) size -3890828602014427492 on inode 21967689 bad magic number 0x974f on inode 21967690 bad version number 0x3e on inode 21967690 bad magic number 0x484e on inode 21967691 bad (negative) size -1512927999802992086 on inode 21967691 bad magic number 0xbc4f on inode 21967692 bad version number 0x0 on inode 21967692 bad magic number 0x484c on inode 21967693 bad version number 0xffffffe5 on inode 21967693 bad version number 0x0 on inode 21967694 bad inode format in inode 21967694 bad magic number 0x414c on inode 21967695 bad version number 0x9 on inode 21967695 bad inode format in inode 21967695 bad magic number 0x494f on inode 21967696 bad version number 0x9 on inode 21967696 bad inode format in inode 21967696 bad magic number 0x4f4e on inode 21967697 bad magic number 0x764e on inode 21967698 bad version number 0x7 on inode 21967698 bad inode format in inode 21967699 bad magic number 0x484e on inode 21967700 bad inode format in inode 21967700 bad magic number 0x6b4c on inode 21967701 bad version number 0x3e on inode 21967701 bad magic number 0x484c on inode 21967702 bad version number 0x3d on inode 21967702 bad inode format in inode 21967702 bad magic number 0xe4c on inode 21967703 bad version number 0x0 on inode 21967703 bad magic number 0x414c on inode 21967704 bad version number 0x55 on inode 21967704 bad inode format in inode 21967704 bad version number 0x0 on inode 21967705 bad inode format in inode 21967705 bad magic number 0x4f4e on inode 21967706 bad inode format in inode 21967706 bad magic number 0x494f on inode 21967707 bad version number 0x9 on inode 21967707 bad inode format in inode 21967707 bad inode format in inode 21967708 bad magic number 0x764e on inode 21967709 bad version number 0x7 on inode 21967709 bad magic number 0x334c on inode 21967710 bad version number 0x3e on inode 21967710 bad (negative) size -2954286585542931353 on inode 21967710 bad magic number 0x484e on inode 21967711 bad (negative) size -8574290740543221774 on inode 21967711 bad inode format in inode 21967648 cleared inode 21967648 bad magic number 0x764e on inode 21967649, resetting magic number bad version number 0x7 on inode 21967649, resetting version number bad (negative) size -7926335343115108092 on inode 21967649 cleared inode 21967649 bad magic number 0x434e on inode 21967650, resetting magic number bad version number 0xb on inode 21967650, resetting version number bad non-zero extent size value 2734686208 for non-realtime inode 21967650,resetting to zero inode 21967650 - bad extent starting block number 1134971155970867, offset 129 bad data fork in inode 21967650 cleared inode 21967650 bad magic number 0x484e on inode 21967651, resetting magic number bad (negative) size -5836665117055380587 on inode 21967651 cleared inode 21967651 bad magic number 0xf04e on inode 21967652, resetting magic number bad version number 0x0 on inode 21967652, resetting version number bad non-zero extent size value 127557 for non-realtime inode 21967652,resetting to zero inode 21967652 - bad extent starting block number 2260595952155133, offset 8725724278063118 bad data fork in inode 21967652 cleared inode 21967652 bad magic number 0x484c on inode 21967653, resetting magic number bad version number 0xffffffad on inode 21967653, resetting version number bad non-zero extent size value 100709120 for non-realtime inode 21967653,resetting to zero bad attr fork offset 6 in inode 21967653, should be 15 cleared inode 21967653 bad magic number 0x434e on inode 21967654, resetting magic number bad version number 0xb on inode 21967654, resetting version number bad non-zero extent size value 90624 for non-realtime inode 21967654,resetting to zero inode 21967654 - bad extent starting block number 2260595908082175, offset 9570149208195086 bad data fork in inode 21967654 cleared inode 21967654 bad magic number 0x414c on inode 21967655, resetting magic number bad version number 0xffffffcd on inode 21967655, resetting version number bad inode format in inode 21967655 cleared inode 21967655 bad magic number 0x494f on inode 21967656, resetting magic number bad version number 0x9 on inode 21967656, resetting version number bad inode format in inode 21967656 cleared inode 21967656 bad magic number 0x4f4e on inode 21967657, resetting magic number bad non-zero extent size value 3523215360 for non-realtime inode 21967657,resetting to zero bad attr fork offset 211 in inode 21967657, should be 15 cleared inode 21967657 bad magic number 0x434e on inode 21967658, resetting magic number bad version number 0xb on inode 21967658, resetting version number bad non-zero extent size value 16784641 for non-realtime inode 21967658,resetting to zero bad attr fork offset 98 in inode 21967658, should be 15 cleared inode 21967658 bad inode format in inode 21967659 cleared inode 21967659 bad magic number 0x484e on inode 21967660, resetting magic number bad (negative) size -360287970172858200 on inode 21967660 cleared inode 21967660 bad magic number 0xa34e on inode 21967661, resetting magic number bad version number 0x3e on inode 21967661, resetting version number bad non-zero extent size value 16128 for non-realtime inode 21967661,resetting to zero inode 21967661 - bad extent starting block number 2269598287985167, offset 16325548651282432 bad data fork in inode 21967661 cleared inode 21967661 bad magic number 0x434e on inode 21967662, resetting magic number bad version number 0xb on inode 21967662, resetting version number bad non-zero extent size value 134352896 for non-realtime inode 21967662,resetting to zero bad attr fork offset 29 in inode 21967662, should be 15 cleared inode 21967662 bad magic number 0x424f on inode 21967663, resetting magic number bad version number 0x0 on inode 21967663, resetting version number bad non-zero extent size value 84736 for non-realtime inode 21967663,resetting to zero inode 21967663 - bad extent starting block number 2260595978590738, offset 2252349569531918 bad data fork in inode 21967663 cleared inode 21967663 bad magic number 0x414c on inode 21967664, resetting magic number bad version number 0x19 on inode 21967664, resetting version number bad inode format in inode 21967664 cleared inode 21967664 bad version number 0x0 on inode 21967665, resetting version number bad inode format in inode 21967665 cleared inode 21967665 bad magic number 0x434e on inode 21967666, resetting magic number bad version number 0xb on inode 21967666, resetting version number found inode 21967666 claiming to be a real-time file cleared inode 21967666 bad magic number 0x494f on inode 21967667, resetting magic number bad version number 0x9 on inode 21967667, resetting version number bad non-zero extent size value 16784641 for non-realtime inode 21967667,resetting to zero size of socket inode 21967667 != 0 (176531745888734 bytes) cleared inode 21967667 bad inode format in inode 21967668 cleared inode 21967668 bad magic number 0x764e on inode 21967669, resetting magic number bad version number 0x7 on inode 21967669, resetting version number bad non-zero extent size value 16909824 for non-realtime inode 21967669,resetting to zero bad attr fork offset 1 in inode 21967669, should be 15 cleared inode 21967669 bad magic number 0x434e on inode 21967670, resetting magic number bad version number 0xb on inode 21967670, resetting version number bad non-zero extent size value 1090584576 for non-realtime inode 21967670,resetting to zero bad attr fork offset 98 in inode 21967670, should be 15 cleared inode 21967670 bad magic number 0x484e on inode 21967671, resetting magic number bad inode format in inode 21967671 cleared inode 21967671 bad magic number 0x1e4f on inode 21967672, resetting magic number bad version number 0x0 on inode 21967672, resetting version number bad non-zero extent size value 78336 for non-realtime inode 21967672,resetting to zero inode 21967672 - bad extent starting block number 2260595908082233, offset 12948398684536846 bad data fork in inode 21967672 cleared inode 21967672 bad magic number 0x484c on inode 21967673, resetting magic number bad version number 0x49 on inode 21967673, resetting version number bad non-zero extent size value 100683521 for non-realtime inode 21967673,resetting to zero bad attr fork offset 6 in inode 21967673, should be 15 cleared inode 21967673 bad magic number 0x434e on inode 21967674, resetting magic number bad version number 0xb on inode 21967674, resetting version number bad non-zero extent size value 78336 for non-realtime inode 21967674,resetting to zero inode 21967674 - bad extent starting block number 2260595908083246, offset 13792823614668814 bad data fork in inode 21967674 cleared inode 21967674 bad magic number 0x414c on inode 21967675, resetting magic number bad version number 0x6b on inode 21967675, resetting version number bad inode format in inode 21967675 cleared inode 21967675 bad magic number 0x494f on inode 21967676, resetting magic number bad version number 0x9 on inode 21967676, resetting version number bad inode format in inode 21967676 cleared inode 21967676 bad magic number 0x4f4e on inode 21967677, resetting magic number bad inode format in inode 21967677 cleared inode 21967677 bad magic number 0x254c on inode 21967678, resetting magic number bad version number 0xb on inode 21967678, resetting version number bad non-zero extent size value 16784641 for non-realtime inode 21967678,resetting to zero bad attr fork offset 50 in inode 21967678, should be 15 cleared inode 21967678 bad non-zero extent size value 2365652992 for non-realtime inode 21967679,resetting to zero bad attr fork offset 160 in inode 21967679, should be 15 cleared inode 21967679 bad magic number 0x484e on inode 21967680, resetting magic number bad (negative) size -7421650710913085158 on inode 21967680 cleared inode 21967680 bad magic number 0xcf4f on inode 21967681, resetting magic number bad version number 0x3e on inode 21967681, resetting version number found inode 21967681 claiming to be a real-time file cleared inode 21967681 bad magic number 0x9e4e on inode 21967682, resetting magic number bad version number 0xffffffc1 on inode 21967682, resetting version number bad inode format in inode 21967682 cleared inode 21967682 bad magic number 0xe04f on inode 21967683, resetting magic number bad version number 0x0 on inode 21967683, resetting version number bad non-zero extent size value 65536 for non-realtime inode 21967683,resetting to zero inode 21967683 - bad extent starting block number 2260595994956373, offset 6474474220191758 bad data fork in inode 21967683 cleared inode 21967683 bad magic number 0x414c on inode 21967684, resetting magic number bad version number 0xffffffb7 on inode 21967684, resetting version number bad inode format in inode 21967684 cleared inode 21967684 bad version number 0x0 on inode 21967685, resetting version number bad inode format in inode 21967685 cleared inode 21967685 bad magic number 0x4f4e on inode 21967686, resetting magic number bad inode format in inode 21967686 cleared inode 21967686 bad magic number 0x494f on inode 21967687, resetting magic number bad version number 0x9 on inode 21967687, resetting version number bad inode format in inode 21967687 cleared inode 21967687 bad inode format in inode 21967688 cleared inode 21967688 bad magic number 0x764e on inode 21967689, resetting magic number bad version number 0x7 on inode 21967689, resetting version number bad (negative) size -3890828602014427492 on inode 21967689 cleared inode 21967689 bad magic number 0x974f on inode 21967690, resetting magic number bad version number 0x3e on inode 21967690, resetting version number bad non-zero extent size value 167774720 for non-realtime inode 21967690,resetting to zero bad attr fork offset 10 in inode 21967690, should be 15 cleared inode 21967690 bad magic number 0x484e on inode 21967691, resetting magic number bad (negative) size -1512927999802992086 on inode 21967691 cleared inode 21967691 bad magic number 0xbc4f on inode 21967692, resetting magic number bad version number 0x0 on inode 21967692, resetting version number found inode 21967692 claiming to be a real-time file cleared inode 21967692 bad magic number 0x484c on inode 21967693, resetting magic number bad version number 0xffffffe5 on inode 21967693, resetting version number bad non-zero extent size value 100723457 for non-realtime inode 21967693,resetting to zero bad attr fork offset 6 in inode 21967693, should be 15 cleared inode 21967693 bad version number 0x0 on inode 21967694, resetting version number bad inode format in inode 21967694 cleared inode 21967694 bad magic number 0x414c on inode 21967695, resetting magic number bad version number 0x9 on inode 21967695, resetting version number bad inode format in inode 21967695 cleared inode 21967695 bad magic number 0x494f on inode 21967696, resetting magic number bad version number 0x9 on inode 21967696, resetting version number bad inode format in inode 21967696 cleared inode 21967696 bad magic number 0x4f4e on inode 21967697, resetting magic number bad non-zero extent size value 167903232 for non-realtime inode 21967697,resetting to zero bad attr fork offset 11 in inode 21967697, should be 15 cleared inode 21967697 bad magic number 0x764e on inode 21967698, resetting magic number bad version number 0x7 on inode 21967698, resetting version number bad non-zero extent size value 167774720 for non-realtime inode 21967698,resetting to zero bad attr fork offset 10 in inode 21967698, should be 15 cleared inode 21967698 bad inode format in inode 21967699 cleared inode 21967699 bad magic number 0x484e on inode 21967700, resetting magic number bad inode format in inode 21967700 cleared inode 21967700 bad magic number 0x6b4c on inode 21967701, resetting magic number bad version number 0x3e on inode 21967701, resetting version number bad non-zero extent size value 16128 for non-realtime inode 21967701,resetting to zero inode 21967701 - bad extent starting block number 2269598183123920, offset 6193549001326592 bad data fork in inode 21967701 cleared inode 21967701 bad magic number 0x484c on inode 21967702, resetting magic number bad version number 0x3d on inode 21967702, resetting version number bad inode format in inode 21967702 cleared inode 21967702 bad magic number 0xe4c on inode 21967703, resetting magic number bad version number 0x0 on inode 21967703, resetting version number bad non-zero extent size value 84736 for non-realtime inode 21967703,resetting to zero inode 21967703 - bad extent starting block number 2260595908082372, offset 10697148626665486 bad data fork in inode 21967703 cleared inode 21967703 bad magic number 0x414c on inode 21967704, resetting magic number bad version number 0x55 on inode 21967704, resetting version number bad inode format in inode 21967704 cleared inode 21967704 bad version number 0x0 on inode 21967705, resetting version number bad inode format in inode 21967705 cleared inode 21967705 bad magic number 0x4f4e on inode 21967706, resetting magic number bad inode format in inode 21967706 cleared inode 21967706 bad magic number 0x494f on inode 21967707, resetting magic number bad version number 0x9 on inode 21967707, resetting version number bad inode format in inode 21967707 cleared inode 21967707 bad inode format in inode 21967708 cleared inode 21967708 bad magic number 0x764e on inode 21967709, resetting magic number bad version number 0x7 on inode 21967709, resetting version number bad non-zero extent size value 16909824 for non-realtime inode 21967709,resetting to zero bad attr fork offset 1 in inode 21967709, should be 15 cleared inode 21967709 bad magic number 0x334c on inode 21967710, resetting magic number bad version number 0x3e on inode 21967710, resetting version number bad (negative) size -2954286585542931353 on inode 21967710 cleared inode 21967710 bad magic number 0x484e on inode 21967711, resetting magic number bad (negative) size -8574290740543221774 on inode 21967711 cleared inode 21967711 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 entry "courierimapuiddb" in shortform directory 11909 references free inode 21967679 junking entry "courierimapuiddb" in directory inode 11909 - agno = 1 - agno = 2 - agno = 3 entry "MSHist012001072720010728" at block 1 offset 896 in directory inode 13186366 references free inode 21967649 clearing inode number in entry at offset 896... entry "996213125.18801_0.gusi,S=81858:2," at block 2 offset 1408 in directory inode 13344155 references free inode 21967684 clearing inode number in entry at offset 1408... entry "996213085.18763_0.gusi,S=82442:2,S" at block 2 offset 3952 in directory inode 13348648 references free inode 21967678 clearing inode number in entry at offset 3952... entry "996155655.10893_0.gusi,S=3803:2,S" at block 5 offset 736 in directory inode 13558420 references free inode 21967651 clearing inode number in entry at offset 736... entry "996215408.19287_0.gusi,S=4075:2,S" at block 5 offset 2320 in directory inode 13558420 references free inode 21967686 clearing inode number in entry at offset 2320... entry "996216360.19472_0.gusi,S=2911:2,S" at block 5 offset 2608 in directory inode 13558420 references free inode 21967688 clearing inode number in entry at offset 2608... entry "996229135.21425_0.gusi,S=3132:2,S" at block 5 offset 2800 in directory inode 13558420 references free inode 21967708 clearing inode number in entry at offset 2800... entry "996156927.11060_0.gusi,S=2839:2,S" at block 5 offset 2896 in directory inode 13558420 references free inode 21967655 clearing inode number in entry at offset 2896... entry "996221860.20775_0.gusi,S=5476:2,S" at block 5 offset 3136 in directory inode 13558420 references free inode 21967698 clearing inode number in entry at offset 3136... entry "996229554.21531_0.gusi,S=3246:2,S" at block 5 offset 3184 in directory inode 13558420 references free inode 21967710 clearing inode number in entry at offset 3184... entry "996163707.11687_0.gusi,S=3920:2,S" at block 5 offset 3664 in directory inode 13558420 references free inode 21967662 clearing inode number in entry at offset 3664... entry "996229774.21578_0.gusi,S=4922:2,S" at block 5 offset 4048 in directory inode 13558420 references free inode 21967711 clearing inode number in entry at offset 4048... entry "996168087.11920_0.gusi,S=4468:2,S" at block 6 offset 304 in directory inode 13558420 references free inode 21967666 clearing inode number in entry at offset 304... entry "996168004.11917_0.gusi,S=3369:2,S" at block 6 offset 400 in directory inode 13558420 references free inode 21967665 clearing inode number in entry at offset 400... entry "996280275.3572_0.gusi,S=3615:2,S" at block 6 offset 976 in directory inode 13558420 references free inode 21967687 clearing inode number in entry at offset 976... entry "996479051.9006_0.gusi,S=5046:2,S" at block 6 offset 1360 in directory inode 13558420 references free inode 21967674 clearing inode number in entry at offset 1360... entry "996164084.11790_0.gusi,S=3380:2,S" at block 13 offset 16 in directory inode 13607975 references free inode 21967663 clearing inode number in entry at offset 16... entry "996226707.21320_0.gusi,S=4731:2,S" at block 13 offset 112 in directory inode 13607975 references free inode 21967703 clearing inode number in entry at offset 112... entry "996213854.18968_0.gusi,S=3472:2,S" at block 13 offset 400 in directory inode 13607975 references free inode 21967683 clearing inode number in entry at offset 400... entry "996228394.21382_0.gusi,S=2531:2,S" at block 13 offset 736 in directory inode 13607975 references free inode 21967705 clearing inode number in entry at offset 736... entry "996221051.20613_0.gusi,S=2997:2,S" at block 13 offset 784 in directory inode 13607975 references free inode 21967695 clearing inode number in entry at offset 784... entry "996160956.11342_0.gusi,S=16445:2,S" at block 13 offset 832 in directory inode 13607975 references free inode 21967659 clearing inode number in entry at offset 832... entry "996217277.19737_0.gusi,S=6106:2,S" at block 13 offset 880 in directory inode 13607975 references free inode 21967689 clearing inode number in entry at offset 880... entry "996228749.21393_0.gusi,S=2412:2,S" at block 13 offset 928 in directory inode 13607975 references free inode 21967706 clearing inode number in entry at offset 928... entry "996229349.21476_0.gusi,S=4689:2,RS" at block 13 offset 1360 in directory inode 13607975 references free inode 21967709 clearing inode number in entry at offset 1360... entry "996222817.21051_0.gusi,S=2890:2,S" at block 13 offset 1648 in directory inode 13607975 references free inode 21967699 clearing inode number in entry at offset 1648... entry "996219250.20317_0.gusi,S=2706:2,S" at block 13 offset 1840 in directory inode 13607975 references free inode 21967692 clearing inode number in entry at offset 1840... entry "996225750.21290_0.gusi,S=4520:2,S" at block 13 offset 2128 in directory inode 13607975 references free inode 21967702 clearing inode number in entry at offset 2128... entry "996218342.19989_0.gusi,S=3013:2,S" at block 13 offset 2512 in directory inode 13607975 references free inode 21967690 clearing inode number in entry at offset 2512... entry "996209095.17543_0.gusi,S=2915:2,S" at block 13 offset 2704 in directory inode 13607975 references free inode 21967671 clearing inode number in entry at offset 2704... entry "996223715.21199_0.gusi,S=3428:2,S" at block 13 offset 2800 in directory inode 13607975 references free inode 21967700 clearing inode number in entry at offset 2800... entry "996210276.17670_0.gusi,S=2869:2,S" at block 13 offset 2896 in directory inode 13607975 references free inode 21967672 clearing inode number in entry at offset 2896... entry "996208359.17512_0.gusi,S=14330:2,S" at block 13 offset 2944 in directory inode 13607975 references free inode 21967670 clearing inode number in entry at offset 2944... entry "996214603.19009_0.gusi,S=3051:2,S" at block 13 offset 2992 in directory inode 13607975 references free inode 21967685 clearing inode number in entry at offset 2992... entry "996156077.10994_0.gusi,S=2629:2,S" at block 13 offset 3184 in directory inode 13607975 references free inode 21967652 clearing inode number in entry at offset 3184... entry "996156458.11033_0.gusi,S=3689:2,S" at block 13 offset 3232 in directory inode 13607975 references free inode 21967653 clearing inode number in entry at offset 3232... entry "996156818.11049_0.gusi,S=4316:2,S" at block 13 offset 3280 in directory inode 13607975 references free inode 21967654 clearing inode number in entry at offset 3280... entry "996207085.17465_0.gusi,S=2810:2,S" at block 13 offset 3328 in directory inode 13607975 references free inode 21967669 clearing inode number in entry at offset 3328... entry "996227605.21350_0.gusi,S=4008:2,S" at block 13 offset 3376 in directory inode 13607975 references free inode 21967704 clearing inode number in entry at offset 3376... entry "996205601.17321_0.gusi,S=4890:2,S" at block 13 offset 3424 in directory inode 13607975 references free inode 21967667 clearing inode number in entry at offset 3424... entry "996157329.11105_0.gusi,S=8077:2,S" at block 13 offset 3472 in directory inode 13607975 references free inode 21967656 clearing inode number in entry at offset 3472... entry "996158410.11186_0.gusi,S=15961:2,S" at block 13 offset 3520 in directory inode 13607975 references free inode 21967657 clearing inode number in entry at offset 3520... entry "996159255.11218_0.gusi,S=2769:2,S" at block 13 offset 3568 in directory inode 13607975 references free inode 21967658 clearing inode number in entry at offset 3568... entry "996163303.11666_0.gusi,S=4419:2,S" at block 13 offset 3616 in directory inode 13607975 references free inode 21967661 clearing inode number in entry at offset 3616... entry "996170022.11971_0.gusi,S=12385:2,S" at block 13 offset 3664 in directory inode 13607975 references free inode 21967668 clearing inode number in entry at offset 3664... entry "996180586.12438_0.gusi,S=3122:2,S" at block 13 offset 3760 in directory inode 13607975 references free inode 21967677 clearing inode number in entry at offset 3760... entry "996220128.20476_0.gusi,S=2689:2,S" at block 13 offset 3808 in directory inode 13607975 references free inode 21967693 clearing inode number in entry at offset 3808... entry "996162891.11631_0.gusi,S=3557:2,S" at block 13 offset 4000 in directory inode 13607975 references free inode 21967660 clearing inode number in entry at offset 4000... entry "996280715.3585_0.gusi,S=2775:2,S" at block 14 offset 784 in directory inode 13607975 references free inode 21967696 clearing inode number in entry at offset 784... entry "996280889.3598_0.gusi,S=3019:2,S" at block 14 offset 832 in directory inode 13607975 references free inode 21967701 clearing inode number in entry at offset 832... entry "996470542.6316_0.gusi,S=5754:2,S" at block 14 offset 3328 in directory inode 13607975 references free inode 21967650 clearing inode number in entry at offset 3328... entry "996281396.3720_0.gusi,S=3159:2,S" at block 0 offset 336 in directory inode 13934102 references free inode 21967680 clearing inode number in entry at offset 336... entry "996285866.4239_0.gusi,S=2475:2,RS" at block 0 offset 3888 in directory inode 13934470 references free inode 21967707 clearing inode number in entry at offset 3888... entry "996287078.4505_0.gusi,S=1890:2,S" at block 1 offset 2944 in directory inode 13934470 references free inode 21967691 clearing inode number in entry at offset 2944... entry "996202080.16696_0.gusi,S=1326:2,S" at block 1 offset 3280 in directory inode 13934470 references free inode 21967664 clearing inode number in entry at offset 3280... entry "996221505.20717_0.gusi,S=1795:2,S" at block 1 offset 3712 in directory inode 13934470 references free inode 21967697 clearing inode number in entry at offset 3712... entry "996201636.16548_0.gusi,S=1111:2,S" at block 1 offset 112 in directory inode 13935591 references free inode 21967676 clearing inode number in entry at offset 112... entry "996211618.18330_0.gusi,S=1105:2,S" at block 1 offset 160 in directory inode 13935591 references free inode 21967681 clearing inode number in entry at offset 160... entry "996292924.6223_0.gusi,S=2711:2,S" at block 1 offset 208 in directory inode 13935591 references free inode 21967673 clearing inode number in entry at offset 208... entry "996549282.1682_0.gusi,S=1193:2,S" at block 1 offset 304 in directory inode 13935591 references free inode 21967682 clearing inode number in entry at offset 304... - agno = 4 entry "courierimapuiddb" in shortform directory 17301812 references free inode 21967648 junking entry "courierimapuiddb" in directory inode 17301812 - agno = 5 entry "marissa@microsoft[2].txt" at block 0 offset 2984 in directory inode 21856753 references free inode 21967675 clearing inode number in entry at offset 2984... entry "offline.ppm" at block 0 offset 264 in directory inode 21931060 references free inode 21967694 clearing inode number in entry at offset 264... - agno = 6 - agno = 7 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 13935591 rebuilding directory inode 13934470 rebuilding directory inode 13934102 rebuilding directory inode 21856753 rebuilding directory inode 21931060 rebuilding directory inode 13558420 rebuilding directory inode 13607975 rebuilding directory inode 13186366 rebuilding directory inode 13348648 rebuilding directory inode 13344155 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... resetting inode 13186366 nlinks from 127 to 126 done -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sun Aug 5 23:42:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f766gwu27436 for linux-xfs-outgoing; Sun, 5 Aug 2001 23:42:58 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f766gtV27416 for ; Sun, 5 Aug 2001 23:42:55 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id IAA01685; Mon, 6 Aug 2001 08:42:39 +0200 (CEST) Message-Id: <4.3.2.7.2.20010806083700.03264608@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Aug 2001 08:42:14 +0200 To: Federico Sevilla III , Linux XFS Mailing List From: Seth Mos Subject: Re: corrupt inode Cc: Linux 3Ware Support In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:13 6-8-2001 +0800, Federico Sevilla III wrote: >Hi everyone, > >Today's my "ghost in the machine" day. > >First one of the drives in my four-disk RAID5 fails. So far the three are >okay so I'm surviving. I'm using a 3ware Escalade 6400 controller with: > > o Montior version ME6X 1.01.00.028 > o Firmware version FE6X 1.02.03.053 > o BIOS version BE6X 1.07.01.015 > >AFAIK this doesn't have that RAID5 degraded problem. I'm using Linux >kernel 2.4.7 with XFS. I got the following error: Someone else on the list could produce corruption when the power of the drive went and you had a raid5 volume. Although that was a 6800. I don't know if the person is lurking around on the list. Below is his mail. ----- FWIW, I got really good at reliably corrupting my data with the 3ware 6800 card and RAID5: just turn off a drive while it was writing. Bad things happened. I've been testing 3 7810 cards they lent to me a couple weeks ago, and I haven't had a problem yet (after ~10TB write/reads and ~12 simulated drive failures under a variety of high and low I/O and CPU duty cycles. Cheers, Dan -- Dan Yocum ---- He can be reached at yocum@fnal.gov >Aug 6 14:05:18 gusi kernel: cmn_err level 4 Filesystem "sd(8,11)": >corrupt inode 21967679 (btree). Unmount and run xfs_repair. You can see a oops comming when your file system shutsdown ;) >It's the middle of the day and everyone's working but I told them all to >shut down. I'm sending this message then I'm unmounting and running >xfs_repair. I've got my fingers crossed. I hope nothing will mess up. I >hope to be able to get back to the list about this after. Good Luck! > --> Jijo > >-- >Federico Sevilla III :: jijo@leathercollection.ph >Network Administrator :: The Leather Collection, Inc. >GnuPG Key: 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 Sun Aug 5 23:50:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f766owq27836 for linux-xfs-outgoing; Sun, 5 Aug 2001 23:50:58 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f766otV27817 for ; Sun, 5 Aug 2001 23:50:55 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 01C02C08285 for ; Mon, 6 Aug 2001 14:50:52 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 97B65C00AC6 for ; Mon, 6 Aug 2001 14:50:50 +0800 (PHT) Date: Mon, 6 Aug 2001 14:50:50 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: corrupt inode In-Reply-To: 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 The continuation, as promised: Most of the problematic files had something to do with Maildirs. I have a script that runs daily and checks the home directory usage. We don't have quotas but like to monitor home directory space consumption. My script e-mailled me this (and this is how I found out about the problem): On Mon, 6 Aug 2001 at 14:01, Cron Daemon wrote: > du: `/home/jay/Maildir/shared-folders/HylaFAX/Processed/cur/996213125.18801_0.gusi,S=81858:2,': No such file > or directory > du: `/home/jay/Maildir/.Sent Mail/cur/996213085.18763_0.gusi,S=82442:2,S': No such file or directory > du: `/home/jijo/documents-tlc/home-snoop/ellaine/.profile/History/History.IE5/MSHist012001072720010728': No > such file or directory > du: `/home/jijo/Maildir/.local PLUG/cur/996164084.11790_0.gusi,S=3380:2,S': No such file or directory > du: `/home/jijo/Maildir/.local PLUG/cur/996226707.21320_0.gusi,S=4731:2,S': No such file or directory And the list goes on and on and on with Maildir entries and some MSIE cache stuff. Thank God this is not our Samba data repository. Mail is critical but I can live with losses. I am using Linux kernel 2.4.7 that was made from a CVS snapshot dated 20010726. I have not yet upgraded the server's kernel to the latest CVS, although two of my Linux workstations are running 2.4.8-pre2. I'd rather not risk it further. I'm hoping there aren't any major issues with the CVS copy as of my snapshot date. This was running pretty smoothly until now. Maybe it has something to do with the 3ware controller? I hope not. Another observation: I cannot unmount any mounted XFS partition. None of them (I have five). I did an "lsof /home" and nothing was shown. What could be wrong? Some other things that may be related: o Debian unstable o devfsd_1.3.11-7 o xfsprogs_1.3.3-0 o nfs-kernel-server_0.3.2-2 Results of "df -i": Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda6 3421760 48686 3373074 2% / /dev/sda1 2000 22 1978 2% /boot /dev/sda8 2674752 15040 2659712 1% /var /dev/sda11 4996160 59015 4937145 2% /home /dev/sda10 56484480 49359 56435121 1% /opt/data /dev/sda9 20000832 452 20000380 1% /var/lib/postgres /dev/sda7 4294967295 0 4294967295 0% /var/spool/squid My fstab: /dev/sda6 / xfs rw,noatime,nodiratime,logbufs=8,biosize=16,osyncisdsync 0 0 /dev/sda1 /boot ext2 rw 0 2 /dev/sda8 /var xfs rw,noatime,nodiratime,logbufs=8,biosize=16 0 0 /dev/sda11 /home xfs rw,noatime,nodiratime,logbufs=8,biosize=16,osyncisdsync 0 0 /dev/sda10 /opt/data xfs rw,noatime,nodiratime,logbufs=8,biosize=16,osyncisdsync 0 0 /dev/sda9 /var/lib/postgres xfs rw,noatime,nodiratime,logbufs=8,biosize=16,osyncisdsync 0 0 /dev/sda7 /var/spool/squid reiserfs rw,noatime,nodiratime,notail 0 0 /dev/sda5 none swap sw 0 0 proc /proc proc defaults 0 0 All XFS partitions built with "-l size=32768b". --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Aug 6 00:08:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76781b28296 for linux-xfs-outgoing; Mon, 6 Aug 2001 00:08:01 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7677xV28274 for ; Mon, 6 Aug 2001 00:07:59 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id JAA09639; Mon, 6 Aug 2001 09:07:35 +0200 (CEST) Message-Id: <4.3.2.7.2.20010806090632.033d1138@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Aug 2001 09:07:10 +0200 To: Federico Sevilla III , Linux XFS Mailing List From: Seth Mos Subject: Re: corrupt inode 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 14:35 6-8-2001 +0800, Federico Sevilla III wrote: >[WARNING: LONG MESSAGE] > >On Mon, 6 Aug 2001 at 14:13, Federico Sevilla III wrote: > > Aug 6 14:05:18 gusi kernel: cmn_err level 4 Filesystem "sd(8,11)": > > corrupt inode 21967679 (btree). Unmount and run xfs_repair. We need Steve or one of the other Gurus. 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 Aug 6 00:12:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f767C7x28503 for linux-xfs-outgoing; Mon, 6 Aug 2001 00:12:07 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f767C5V28484 for ; Mon, 6 Aug 2001 00:12:05 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id JAA18868; Mon, 6 Aug 2001 09:11:54 +0200 (CEST) Message-Id: <4.3.2.7.2.20010806090719.0342a890@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Aug 2001 09:11:30 +0200 To: Federico Sevilla III , Linux XFS Mailing List From: Seth Mos Subject: Re: corrupt inode 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 14:50 6-8-2001 +0800, Federico Sevilla III wrote: >The continuation, as promised: >I am using Linux kernel 2.4.7 that was made from a CVS snapshot dated >20010726. I have not yet upgraded the server's kernel to the latest CVS, >although two of my Linux workstations are running 2.4.8-pre2. I'd rather >not risk it further. I'm hoping there aren't any major issues with the CVS >copy as of my snapshot date. This was running pretty smoothly until now. >Maybe it has something to do with the 3ware controller? I hope not. Some people are stille seeing odd behaviour every now and then with those cards. Because I don't have such a card I can't comment on it further. I am assuming you are running the card in hardware raid5 mode? 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 Aug 6 00:25:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f767P4K28711 for linux-xfs-outgoing; Mon, 6 Aug 2001 00:25:04 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f767P1V28692 for ; Mon, 6 Aug 2001 00:25:02 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 07EAEC08285 for ; Mon, 6 Aug 2001 15:25:00 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id AE9D8C00AC6 for ; Mon, 6 Aug 2001 15:24:58 +0800 (PHT) Date: Mon, 6 Aug 2001 15:24:58 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: corrupt inode In-Reply-To: <4.3.2.7.2.20010806090719.0342a890@pop.xs4all.nl> 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 Mon, 6 Aug 2001 at 09:11, Seth Mos wrote: > Some people are stille seeing odd behaviour every now and then with > those cards. Because I don't have such a card I can't comment on it > further. I am getting in touch with 3ware. Hopefully they can help me get a replacement 7410 for this 6400 at a lower cost or even free of charge. Unless of course they can fix the 6400. > I am assuming you are running the card in hardware raid5 mode? Yes, indeed. And sometimes I wish I just went RAID 10 with all this brouhaha. Unfortunately it's too late. I have all my data on this array. And it's our company's (we're just an SME in a third world country [Philippines]) everything server (data, database, web, e-mail). :( :( :( I will run "xfs_repair -n" on all my XFS partitions. Hopefully this will give my filesystems a clean bill of health. I'm also getting in touch with IBM Philippines to get that downed drive repaired. Grumble grumble ... --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Aug 6 01:09:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7689NR30064 for linux-xfs-outgoing; Mon, 6 Aug 2001 01:09:23 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7689KV30042 for ; Mon, 6 Aug 2001 01:09:20 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA12447; Mon, 6 Aug 2001 10:09:13 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id KAA15766; Mon, 6 Aug 2001 10:09:12 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 5A88957306; Mon, 6 Aug 2001 10:08:35 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id E3D4E25835; Mon, 6 Aug 2001 10:08:25 +0200 (CEST) Message-ID: <3B6E5079.D1E4EC61@ch.sauter-bc.com> Date: Mon, 06 Aug 2001 10:08:25 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Federico Sevilla III Cc: Linux XFS Mailing List , Linux 3Ware Support Subject: Re: corrupt inode References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III schrieb: > > Hi everyone, > > Today's my "ghost in the machine" day. > > First one of the drives in my four-disk RAID5 fails. So far the three are > okay so I'm surviving. I'm using a 3ware Escalade 6400 controller with: > > o Montior version ME6X 1.01.00.028 > o Firmware version FE6X 1.02.03.053 > o BIOS version BE6X 1.07.01.015 > > AFAIK this doesn't have that RAID5 degraded problem. I'm using Linux > kernel 2.4.7 with XFS. I got the following error: It's not easy to say something useful here but maybe this: don't panic now! It's my experience that in critical situations it's VERY important not to get nervous an mess things up. I'm just wondering whether your filesystem corruption is related to the disk crash. If yes, it means the 3ware controller did not do his job. So if it's like that I would not trust it anymore and I suggest NOT to replace the broken disk immediately. If you replace the disk and the 3ware doesn't start up correctly, you may loose all data. > > I tried unmounting /home but could not because of some hung up processes > thanks to what caused this oops. So I restarted the computer (clean > shutdown). It remounted /dev/sda11 read only as it could not unmount it. > Then I booted with init=/bin/sh, ran devfs (fortunately or unfortunately I > use it) so that my /dev gets populated, and ran xfs_repair. I ran it first > with the "-n" flag and saw that it had a lot of output so I ran the real > xfs_repair via nohup. Here are the contents of the nohup.out that resulted > from scanning /dev/sda11 (my home partition): I think your unmounting problem may be related to knfsd. I have a server running samba and knfsd for several HP/UX, Solaris, Linux and Windows clients and on this machine I have never been able to unmount /home. I went to single user, tried to find any files with lsof, removed all nfs related kernel modules but still could not unmount it. I'm just wondering what will happen if I have to shutdown it, it has 249 days uptime and it's a quit busy server on Mandrake 7.0 / 2.2.14 with ext2fs. -Simon > > --> Jijo > > -- > Federico Sevilla III :: jijo@leathercollection.ph > Network Administrator :: The Leather Collection, Inc. > GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Aug 6 01:29:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f768T1W30866 for linux-xfs-outgoing; Mon, 6 Aug 2001 01:29:01 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f768SuV30829 for ; Mon, 6 Aug 2001 01:28:56 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id A2042C08285 for ; Mon, 6 Aug 2001 16:28:40 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 484AEC00AC6 for ; Mon, 6 Aug 2001 16:28:39 +0800 (PHT) Date: Mon, 6 Aug 2001 16:28:39 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: corrupt inode In-Reply-To: <3B6E5079.D1E4EC61@ch.sauter-bc.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 On Mon, 6 Aug 2001 at 10:08, Simon Matter wrote: > It's not easy to say something useful here but maybe this: don't panic > now! It's my experience that in critical situations it's VERY > important not to get nervous an mess things up. Thank you for that slap in the face. I did my best not to panic. If I had let myself to get fully enmeshed in panic, I wouldn't have remembered to find a way to grab xfs_repair's output. ;> > I'm just wondering whether your filesystem corruption is related to > the disk crash. Yes. Seth sent a pretty interesting post by Dan Yocum about his tests on the 3ware controllers. When I read Seth's "reminder" message, I remember reading Dan's e-mail. It looks like the 3ware 6000 series with RAID5 will cause data corruption when a drive goes offline while a write is being performed. Dan hasn't noticed this in the 7000 series. Hopefully 3ware will replace my 6400 controller with the 7410. I don't know what they'll say about this, though. I'm still waiting for a response from them (all my diagnostic messages had them cc'd). I don't know if this is limited to XFS, though. > If yes, it means the 3ware controller did not do his job. So if it's > like that I would not trust it anymore and I suggest NOT to replace > the broken disk immediately. If you replace the disk and the 3ware > doesn't start up correctly, you may loose all data. I've had this drive go offline before. The controller flags a drive offline when it hits a bad sector. Rebuilding the array attempts to reuse the drive, hoping that this bad sector has been remapped by the drive. It looks like my IBM drive has reached its limit. I wanted to make sure it wasn't the 3ware controller or the cable, so I switched two drives around. The same drive that failed before on Port 2 failed now on Port 3. It's the drive. Subsequent rebuilds (i've tried a number of times) have failed even before the rebuild was done. When I get a replacement I'll run IBM's disk check on this just to see. > I think your unmounting problem may be related to knfsd. I have a > server running samba and knfsd for several HP/UX, Solaris, Linux and > Windows clients and on this machine I have never been able to unmount > /home. Ahh yes. I forgot to stop the nfs-kernel-server daemon. I'll try that later this afternoon (when everyone's out). :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Aug 6 07:47:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76Eler06829 for linux-xfs-outgoing; Mon, 6 Aug 2001 07:47:40 -0700 Received: from frodo.ezprohosting.com ([216.74.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76ElbV06807 for ; Mon, 6 Aug 2001 07:47:38 -0700 Received: from c922720-a.sttln1.wa.home.com ([65.0.77.21] helo=windows) by frodo.ezprohosting.com with smtp (Exim 3.20 #1) id 15TleY-0000Qm-00; Mon, 06 Aug 2001 10:46:46 -0400 Message-ID: <002c01c11e86$256065d0$020144c0@windows> From: "Eric Peters" To: "Nathan Scott" Cc: References: <200108060248.MAA57077@snort.melbourne.sgi.com> Subject: Re: TAKE - getfacl/setfacl Date: Mon, 6 Aug 2001 07:43:11 -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 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - frodo.ezprohosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - peters.org Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Nathan Scott" To: Sent: Sunday, August 05, 2001 7:48 PM Subject: TAKE - getfacl/setfacl > On Fri, Aug 03, 2001 at 01:51:30PM +1000, Timothy Shimmin wrote: > > > > > > Are there any other utilities other than chacl for managing the ACLs? > > > > > Nathan Scott will soon check in ported versions of Andreas' > > setfacl and getfacl ACL commands. > > (Currently, you'll need to preserve an ACE ordering in ACL specification > > for setfacl; > however, I'll look into fixing this problem when the > > code is checked in). > > At the risk of sounding ignorant, what's the ACE ordering ;) The only thing that comes to mind is a programming library ACE, but I have a feeling that is not the same reference. Thanks alot, Eric From owner-linux-xfs@oss.sgi.com Mon Aug 6 08:10:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76FAi509769 for linux-xfs-outgoing; Mon, 6 Aug 2001 08:10:44 -0700 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 f76FAgV09749 for ; Mon, 6 Aug 2001 08:10:42 -0700 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 f76FExS22117 for ; Mon, 6 Aug 2001 08:14:59 -0700 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 KAA2638792; Mon, 6 Aug 2001 10:09:21 -0500 (CDT) 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 KAA76113; Mon, 6 Aug 2001 10:09:20 -0500 (CDT) Subject: Re: Problem with XFS 1.01 / RedHat 7.1 install From: Eric Sandeen To: sgarcia@bak.rr.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <200108060418.f764IU604838@laxmls03.socal.rr.com> References: <200108060418.f764IU604838@laxmls03.socal.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 06 Aug 2001 10:06:18 -0500 Message-Id: <997110379.32554.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 05 Aug 2001 21:16:15 -0400, sgarcia@bak.rr.com wrote: > I'm having some difficulty with a new install using XFS1.01 and RedHat > 7.1. Everything seems to go along fine until it asks for the RedHat disc > 1. I get a popup telling me "That's not the correct CDROM". I've put the > CD into another machine and confirmed that it is disc1 of the RedHat 7.1 > set. Keith had the right idea, but the message he pointed you to was headed for a wrong solution... if you don't have a file called ".disc1-i386" in the root of your "Disc 1", with "986787650.210260" in that file, then you don't have an "official" Red Hat 7.1 disc. -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 Aug 6 17:31:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f770VFP02587 for linux-xfs-outgoing; Mon, 6 Aug 2001 17:31:15 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f770VDV02568 for ; Mon, 6 Aug 2001 17:31:13 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA01640 for ; Mon, 6 Aug 2001 17:30:58 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA78133; Tue, 7 Aug 2001 10:29:18 +1000 (EST) Date: Tue, 7 Aug 2001 10:29:18 +1000 From: Timothy Shimmin To: Eric Peters Cc: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: TAKE - getfacl/setfacl Message-ID: <20010807102917.C78571@boing.melbourne.sgi.com> References: <200108060248.MAA57077@snort.melbourne.sgi.com> <002c01c11e86$256065d0$020144c0@windows> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <002c01c11e86$256065d0$020144c0@windows>; from eric@peters.org on Mon, Aug 06, 2001 at 07:43:11AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, On Mon, Aug 06, 2001 at 07:43:11AM -0700, Eric Peters wrote: > > ----- Original Message ----- > From: "Nathan Scott" > To: > Sent: Sunday, August 05, 2001 7:48 PM > Subject: TAKE - getfacl/setfacl > > > > On Fri, Aug 03, 2001 at 01:51:30PM +1000, Timothy Shimmin wrote: > > > > > > > > Are there any other utilities other than chacl for managing the ACLs? > > > > > > > Nathan Scott will soon check in ported versions of Andreas' > > > setfacl and getfacl ACL commands. > > > (Currently, you'll need to preserve an ACE ordering in ACL specification > > > for setfacl; > however, I'll look into fixing this problem when the > > > code is checked in). > > > > > At the risk of sounding ignorant, what's the ACE ordering ;) The only thing > that comes to mind is a programming library ACE, but I have a feeling that > is not the same reference. > Sorry if my note was a bit cryptic. Andreas' code keeps the ACEs (Access Control List Entries) of an ACL in order sorted numerically by tag type (ACL_USER_OBJ, ACL_USER, ...). This makes the access check algorithm simpler and potentially quicker. The XFS ACL code do not keep the ACEs ordered - they are stored in the order in which they are given. Andreas' code, however, does _not_ require the ACEs to be ordered from the user - unsurprisingly, his code sorts them. However, in the port of setfacl and associated missing libacl functions, it appears that something has gone wrong because unless the ACEs are in the correct order when given as an argument to setfacl, it gives an error message. --Tim From owner-linux-xfs@oss.sgi.com Mon Aug 6 19:37:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f772bdA15580 for linux-xfs-outgoing; Mon, 6 Aug 2001 19:37:39 -0700 Received: from hotmail.com (f144.law7.hotmail.com [216.33.237.144]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f772bbV15545 for ; Mon, 6 Aug 2001 19:37:37 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 6 Aug 2001 19:37:32 -0700 Received: from 211.99.247.66 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 07 Aug 2001 02:37:32 GMT X-Originating-IP: [211.99.247.66] From: "Harrison Xing" To: linux-xfs@oss.sgi.com Subject: xfsdump bugs in 1.0.1 -- busy inodes after xfsdump Date: Tue, 07 Aug 2001 10:37:32 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Aug 2001 02:37:32.0236 (UTC) FILETIME=[E8A400C0:01C11EE9] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have the following problems when doing some simple operations as below using xfsdump. 1. Use one xfs partition, say /dev/hda10. Create some files on the xfs partition. 2. umount /dev/hda10 3. mount /dev/hda10 /mnt/xfs 4. use xfsdump to dump /mnt/xfs. No errors are reported. 5. umount /dev/hda10. The the kernel messages show " busy vp=0xc587dc9c ip=0xc45e69dc inum 131 count=1" And xfs becomes unusable. But if I don't unmount /dev/hda10 after I create the files(omit step 2 and 3) OR I do a lookup after I umount and mount xfs ( after step 3), then everything is fine. So I think certainly it's a bug in the kernel codes releated to xfsdump of xfs 1.0.1. Any ideas? Thanks. Best regards, Harrison _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-linux-xfs@oss.sgi.com Mon Aug 6 20:02:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7732nL18924 for linux-xfs-outgoing; Mon, 6 Aug 2001 20:02:49 -0700 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 f7732lV18904 for ; Mon, 6 Aug 2001 20:02:47 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f77388W20657 for ; Mon, 6 Aug 2001 20:08:08 -0700 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 UAA23115; Mon, 6 Aug 2001 20:02:09 -0700 (PDT) Message-ID: <3B6F5979.4944EE27@sgi.com> Date: Mon, 06 Aug 2001 21:59:05 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Harrison Xing CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump bugs in 1.0.1 -- busy inodes after xfsdump References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Harrison Xing wrote: > > Hi, > I have the following problems when doing some simple operations as > below using xfsdump. Ah, I'm trying to chase down a similar problem, but yours is a better (more narrow) test case... What version of 1.0.1 is this? (RH-2.4.3 or 2.4.5? RPM or patch? What compiler?) I've seen this after running the fsstress command, then running xfs_fsr, then unmount - and I also see the problem go away if I do lookups (ls -R) on the filesystem first. Anything you can tell me to help recreate the problem here would be much appreciated. 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 Aug 6 20:09:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7739BR19857 for linux-xfs-outgoing; Mon, 6 Aug 2001 20:09:11 -0700 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 f7739AV19838 for ; Mon, 6 Aug 2001 20:09:10 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f773EWW20806 for ; Mon, 6 Aug 2001 20:14:32 -0700 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 UAA68707; Mon, 6 Aug 2001 20:08:33 -0700 (PDT) Message-ID: <3B6F5AF9.A20C8620@sgi.com> Date: Mon, 06 Aug 2001 22:05:29 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Harrison Xing , linux-xfs@oss.sgi.com Subject: Re: xfsdump bugs in 1.0.1 -- busy inodes after xfsdump References: <3B6F5979.4944EE27@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: > Anything you can tell me to help recreate the problem here would be much > appreciated. Whoops, no more info needed, I just got it to blow up over here. :) Thanks for the detailed report! -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 7 03:49:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77AnFl03780 for linux-xfs-outgoing; Tue, 7 Aug 2001 03:49:15 -0700 Received: from mail.isg.de (foobar.isg.de [62.96.243.63]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77AnCV03758 for ; Tue, 7 Aug 2001 03:49:13 -0700 Received: from isg.de (wall2-outer.isg.de [62.96.243.126]) by mail.isg.de (Postfix) with ESMTP id F35D277135B; Tue, 7 Aug 2001 12:49:10 +0200 (CEST) Message-ID: <3B6FC7A3.FD713FFC@isg.de> Date: Tue, 07 Aug 2001 12:49:07 +0200 From: Constantin Loizides Organization: Innovative Software AG X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Utz Lehmann Cc: xfs-list Subject: Re: Fragmentation of Journaling FS References: <3B67D35E.64877CBF@isg.de> <20010801144322.C1132@de.tecosim.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Utz, >[..] > I made a quick and dirty test running this: > > while time cp -a /usr/src/linux/drivers/ /mnt/xxx-`date '+%s'`; do sync; \ > df | grep mnt; done > I tried your crude test on my machine with the 512 MB partition. It also shows smooth behaviour. That made me a bit nervous, so I played around with the configuration of the directory structure and gave agesystem another run: You find my results on the web http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/agesystem.html#gaugeveri It seems that the sharp performance drop is influenced by the directory hierachy I am using. Why is the best behaviour for the least directories (100x1 means 100 dirs)? I am also reproducing for the 4GB partition, but it will take some time. The 100x50 test is alread there, compare it with the 100x100 test you find at http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/agesystem.html#4part The results seem also be highly dependent on the directory structure. Will also test 100x10 and maybe 100x1 too. Constantin From owner-linux-xfs@oss.sgi.com Tue Aug 7 04:44:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77Bia409532 for linux-xfs-outgoing; Tue, 7 Aug 2001 04:44:36 -0700 Received: from kai.emphora.it.pl (qmailr@kai.emphora.it.pl [157.25.122.162]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77BiXV09513 for ; Tue, 7 Aug 2001 04:44:34 -0700 Received: (qmail 3837 invoked from network); 7 Aug 2001 11:44:28 -0000 Received: from localhost (HELO emphora.it.pl) (root@127.0.0.1) by localhost with SMTP; 7 Aug 2001 11:44:28 -0000 Message-ID: <3B6FD49C.B44E2F7E@emphora.it.pl> Date: Tue, 07 Aug 2001 13:44:28 +0200 From: Krzysztof Lichota Organization: Warsaw University, Faculty of Mathematics, Informatics and Mechanics X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: Polish, pl, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: configure.in problem for DMAPI test Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello! I have tried to compile tests for DMAPI (in cmd/xfstests/dmapi) and compilation failed due tu undefined dm_XXX symbols. I got the source for these tests from CVS. It turned out that configure script did not detect libhandle library properly (and in result libdm was also not detected). The problem is that in xfsprogs-devel-1.2.8-0.i386.rpm (and also xfsprogs-devel-1.2.0-0.i386.rpm) libhandle.a does not export symbol that is checked by configure (fssetdm_by_handle). The following test fails: AC_CHECK_LIB(handle,fssetdm_by_handle)) AC_CHECK_LIB(dm,dm_init_service) I managed to compile these tests by replacing "fssetdm_by_handle" with other symbol "path_to_fshandle". Probably I should use libhandle library from CVS, but these test don't depend on fssetdm_by_handle, so it could be changed so that older libhandle library could be used. Regards Krzysztof Lichota From owner-linux-xfs@oss.sgi.com Tue Aug 7 07:36:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77EavZ21626 for linux-xfs-outgoing; Tue, 7 Aug 2001 07:36:57 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77EatV21607 for ; Tue, 7 Aug 2001 07:36:55 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA07466 for ; Tue, 7 Aug 2001 07:34:48 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2647424 for ; Tue, 7 Aug 2001 09:35:37 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA19247 for ; Tue, 7 Aug 2001 09:35:37 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA25561; Tue, 7 Aug 2001 09:35:36 -0500 (CDT) Message-Id: <200108071435.JAA25561@slobber.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: configure.in problem for DMAPI test Date: Tue, 07 Aug 2001 09:35:36 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It looks like your xfsprogs package is too old. A new function, fssetdm_by_handle, was added to libhandle recently. It's used by the recent changes to xfsrestore, but nothing else is using it. Dean >From: Krzysztof Lichota >Hello! >I have tried to compile tests for DMAPI (in cmd/xfstests/dmapi) and >compilation failed due tu undefined dm_XXX symbols. >I got the source for these tests from CVS. > >It turned out that configure script did not detect libhandle library >properly (and in result libdm was also not detected). >The problem is that in xfsprogs-devel-1.2.8-0.i386.rpm (and also >xfsprogs-devel-1.2.0-0.i386.rpm) libhandle.a does not export symbol that >is checked by configure (fssetdm_by_handle). > >The following test fails: > >AC_CHECK_LIB(handle,fssetdm_by_handle)) >AC_CHECK_LIB(dm,dm_init_service) > >I managed to compile these tests by replacing "fssetdm_by_handle" with >other symbol "path_to_fshandle". Probably I should use libhandle library >from CVS, but these test don't depend on fssetdm_by_handle, so it could >be changed so that older libhandle library could be used. > >Regards > > Krzysztof Lichota > From owner-linux-xfs@oss.sgi.com Tue Aug 7 08:32:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77FWRu28878 for linux-xfs-outgoing; Tue, 7 Aug 2001 08:32:27 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77FWOV28852 for ; Tue, 7 Aug 2001 08:32:24 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 16B8EC08366; Tue, 7 Aug 2001 23:32:22 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id C1920C08362; Tue, 7 Aug 2001 23:32:20 +0800 (PHT) Received: from 202.163.192.10 ( [202.163.192.10]) as user jijo@localhost by horde.leathercollection.ph with HTTP; Tue, 7 Aug 2001 23:32:20 +0800 Message-ID: <997198340.3b700a04af5f8@horde.leathercollection.ph> Date: Tue, 7 Aug 2001 23:32:20 +0800 From: Federico Sevilla III To: Tom Tran Cc: linux-xfs@oss.sgi.com, linux@3ware.com Subject: Re: corrupt inode References: <70F2193152F7D411B53F00D0B79E84946A0B1C@cougar> In-Reply-To: <70F2193152F7D411B53F00D0B79E84946A0B1C@cougar> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs X-Originating-IP: 202.163.192.10 X-Organization: The Leather Collection, Inc. X-URL: http X-Admin-Contact: root@leather-collection.com X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Tom, (cc XFS mailing list) Quoting Tom Tran : > I am seeing that you have the latest 6.8 codeset. Yes. I upgraded when I found out about it. I found out about it when the kernel ChangeLog showed a 3ware drive upgrade. These normally come with firmware upgrades so after upgrading my kernel I flashed my controller. > 1. Were you using the old driver and firmware before upgrading to the > current software? No. I upgraded my kernel first to one which matched the currently latest driver (I forget if this was 2.4.6 or 2.4.7). > 2. What about the ext2 file system? I am seeing the xfs problems but could > not tell if ext2 also has problems or not. My only ext2 partition is my /boot and that doesn't get written to often. >From the report of Dan Yocum (maybe you can get in touch with him?) it looks like the 3ware Escalade 6000 controllers have difficulty with situations where a drive element of a RAID5 array goes offline while a write is in progress. These cause data corruptions at least in XFS (as I've experienced). My data corruption happened when one drive died, which was around 11:00am. I didn't notice the corruption until 2:00pm when a script did a "du -csm" on some directories in /home that were hit by this data corruption. E-mail, not so critical, thank God (although still not good). I still have three live drives and am running degraded mode now (so far no problems, I have my fingers crossed). I am rushing to get a replacement soon (I know, I should have had a spare). >From what Dan Yocum said it's only the 7000 series that can handle this "drive going offline while writing data" problem. I do not know if he did tests with ReiserFS and/or ext2. And while we're at it: JFS and ext3. Maybe you can attempt to run into these problems in your lab? I'm sure you have enough machines to get the various filesystems on them. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG key: From owner-linux-xfs@oss.sgi.com Tue Aug 7 08:37:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77FbrQ29748 for linux-xfs-outgoing; Tue, 7 Aug 2001 08:37:53 -0700 Received: from aserver-nt.audio_west (paxnetworks.com [63.202.121.162] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77FbqV29728 for ; Tue, 7 Aug 2001 08:37:52 -0700 Received: by paxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 08:40:05 -0700 Message-ID: <01B6B159F711D41194B2005004C2905C107628@paxnetworks.com> From: Larry Altneu To: "'linux-xfs@oss.sgi.com'" Subject: File corruption Date: Tue, 7 Aug 2001 08:40:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am experiencing a problem that results in corruption of the data for a freshly written file. It is very reproducible by creating and saving a file with vi and then pulling the plug on the system. When it comes back up, the file exists with the proper size but it contains all zeros. Any guidance would be appreciated. From owner-linux-xfs@oss.sgi.com Tue Aug 7 08:52:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77Fqxs31925 for linux-xfs-outgoing; Tue, 7 Aug 2001 08:52:59 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77FqrV31892 for ; Tue, 7 Aug 2001 08:52:56 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 7217EC0FFA5 for ; Tue, 7 Aug 2001 23:52:47 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 1D134C08362 for ; Tue, 7 Aug 2001 23:52:46 +0800 (PHT) Date: Tue, 7 Aug 2001 23:52:46 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: File corruption In-Reply-To: <01B6B159F711D41194B2005004C2905C107628@paxnetworks.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 On Tue, 7 Aug 2001 at 08:40, Larry Altneu wrote: > I am experiencing a problem that results in corruption of the data for > a freshly written file. It is very reproducible by creating and saving > a file with vi and then pulling the plug on the system. When it comes > back up, the file exists with the proper size but it contains all > zeros. Any guidance would be appreciated. Those zeroes are binary zeroes: the null character. I remember this was discussed before (you could search the archives, I do believe the XFS list is archived by marc.theaimsgroup.com). I cannot quite remember exactly what causes this, though. Maybe the gurus can reply when they're not so busy. Maybe we can add a FAQ entry for this? I think it's asked frequently enough. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Tue Aug 7 08:53:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77FrZ432047 for linux-xfs-outgoing; Tue, 7 Aug 2001 08:53:35 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77FrWV32025 for ; Tue, 7 Aug 2001 08:53:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA746971 for ; Tue, 7 Aug 2001 17:53:08 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2644520; Tue, 7 Aug 2001 10:52:08 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA60535; Tue, 7 Aug 2001 10:52:08 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f77FppH29377; Tue, 7 Aug 2001 10:51:51 -0500 Message-Id: <200108071551.f77FppH29377@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Larry Altneu cc: "'linux-xfs@oss.sgi.com'" Subject: Re: File corruption In-Reply-To: Message from Larry Altneu of "Tue, 07 Aug 2001 08:40:05 PDT." <01B6B159F711D41194B2005004C2905C107628@paxnetworks.com> Date: Tue, 07 Aug 2001 10:51:51 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I am experiencing a problem that results in corruption of the data for a > freshly written file. It is very reproducible by creating and saving a file > with vi and then pulling the plug on the system. When it comes back up, the > file exists with the proper size but it contains all zeros. Any guidance > would be appreciated. If it hurts don't do that! Basically this is normal behavior. XFS journals metadata updates, not data updates. After a crash you are supposed to get a consistent filesystem which looks like the state sometime shortly before the crash, NOT what the in memory image looked like the instant before the crash. Since XFS does not write data out to disk immediately unless you tell it to with fsync or an O_SYNC open (the same is true of other filesystems), you are looking at an inode which was flushed out to disk, but for which the data was never flushed to disk. You will find that the inode is not taking any disk space since all it has is a size, there are no disk blocks allocated for it yet. Steve From owner-linux-xfs@oss.sgi.com Tue Aug 7 08:55:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77FtCT32443 for linux-xfs-outgoing; Tue, 7 Aug 2001 08:55:12 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77FtAV32418 for ; Tue, 7 Aug 2001 08:55:11 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id RAA14991; Tue, 7 Aug 2001 17:54:56 +0200 (CEST) Message-Id: <4.3.2.7.2.20010807175219.03389ee8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 17:54:24 +0200 To: Larry Altneu , "'linux-xfs@oss.sgi.com'" From: Seth Mos Subject: Re: File corruption In-Reply-To: <01B6B159F711D41194B2005004C2905C107628@paxnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:40 7-8-2001 -0700, Larry Altneu wrote: >I am experiencing a problem that results in corruption of the data for a >freshly written file. It is very reproducible by creating and saving a file >with vi and then pulling the plug on the system. When it comes back up, the >file exists with the proper size but it contains all zeros. Any guidance >would be appreciated. Vi truncates the file and does not overwrite the file. This happens with all programs that truncate the file before writing to it. There was a thread about this behaviour a while ago (1-2 months). You might try searching that. 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 Aug 7 08:55:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77Fter32564 for linux-xfs-outgoing; Tue, 7 Aug 2001 08:55:40 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77FtbV32533 for ; Tue, 7 Aug 2001 08:55:37 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA732130 for ; Tue, 7 Aug 2001 17:55:06 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2641148; Tue, 7 Aug 2001 10:54:09 -0500 (CDT) 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 KAA55478; Tue, 7 Aug 2001 10:54:08 -0500 (CDT) Subject: Re: File corruption From: Eric Sandeen To: Larry Altneu Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <01B6B159F711D41194B2005004C2905C107628@paxnetworks.com> References: <01B6B159F711D41194B2005004C2905C107628@paxnetworks.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 07 Aug 2001 10:50:56 -0500 Message-Id: <997199457.3573.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 07 Aug 2001 08:40:05 -0700, Larry Altneu wrote: > I am experiencing a problem that results in corruption of the data for a > freshly written file. It is very reproducible by creating and saving a file > with vi and then pulling the plug on the system. Don't do that. :) > When it comes back up, the > file exists with the proper size but it contains all zeros. Any guidance > would be appreciated. As long as there is any form of write caching, writing to a file and immediately pulling the plug will result in lost data. The reason you see the zeros is that the metadata (i.e. file size) has made it to the transaction log, but the data itself has not made it to disk. When xfs is remounted, it replays the log - and you wind up with a file that has a size, but no data. So you get zeros. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 7 09:57:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77GvBf03252 for linux-xfs-outgoing; Tue, 7 Aug 2001 09:57:11 -0700 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 f77Gv9V03233 for ; Tue, 7 Aug 2001 09:57:09 -0700 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 GHPJ4Y00.HAA for ; Tue, 7 Aug 2001 12:58:10 -0400 Message-ID: <3B701DE4.1EDE3967@umbi.umd.edu> Date: Tue, 07 Aug 2001 12:57:08 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: unable to open initial console References: <200108071646.f77GkBn02632@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi folks, I'm having problems with systems upgraded from kernel-2.4.2-SGI_XFS_1.0 to kernel-2.4.3-SGI_XFS_1.0.1 that when I try to boot the new kernel, boot fails with the message, "unable to open initial console." I can still boot into the 2.4.2 kernel with no problems. I thought maybe the problem was due to devfs, because I think the devfs kernel message does not appear, but adding devfs=mount or devfs=nomount did not help. I have the same problem on a PIII and an SMP Pentium Pro system. Has anyone else encountered this problem? If so, did you find a solution? Thanks, -- "Jonathan F. Dill" (dill@umbi.umd.edu) CARB Systems and Network Administrator Home Page: http://www.umbi.umd.edu/~dill From owner-linux-xfs@oss.sgi.com Tue Aug 7 10:27:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77HRSE04779 for linux-xfs-outgoing; Tue, 7 Aug 2001 10:27:28 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77HRQV04760 for ; Tue, 7 Aug 2001 10:27:26 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA25329 for ; Tue, 7 Aug 2001 10:27:12 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2645995; Tue, 7 Aug 2001 12:26:10 -0500 (CDT) 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 MAA50816; Tue, 7 Aug 2001 12:26:09 -0500 (CDT) Subject: Re: unable to open initial console From: Eric Sandeen To: Jonathan Dill Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B701DE4.1EDE3967@umbi.umd.edu> References: <200108071646.f77GkBn02632@oss.sgi.com> <3B701DE4.1EDE3967@umbi.umd.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 07 Aug 2001 12:22:58 -0500 Message-Id: <997204978.1382.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 07 Aug 2001 12:57:08 -0400, Jonathan Dill wrote: > Hi folks, > > I'm having problems with systems upgraded from kernel-2.4.2-SGI_XFS_1.0 > to kernel-2.4.3-SGI_XFS_1.0.1 that when I try to boot the new kernel, > boot fails with the message, "unable to open initial console." I can > still boot into the 2.4.2 kernel with no problems. I thought maybe the > problem was due to devfs, because I think the devfs kernel message does > not appear, but adding devfs=mount or devfs=nomount did not help. Hm, perhaps this is devfs-related... devfs is completely gone from the 1.0.1 kernel, so "devfs=mount" won't do anything for you. Perhaps something about your on-disk /dev is wrong... If there's a way to re-install the dev RPM (or verify it) that might fix the problem. Can you boot 2.4.2 with "devfs=nomount"? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 7 10:44:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77HihU05216 for linux-xfs-outgoing; Tue, 7 Aug 2001 10:44:43 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77HifV05197 for ; Tue, 7 Aug 2001 10:44:41 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id TAA29533; Tue, 7 Aug 2001 19:44:39 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA18180; Tue, 7 Aug 2001 19:44:38 +0200 (CEST) Date: Tue, 7 Aug 2001 19:44:38 +0200 (CEST) From: Seth Mos To: Jonathan Dill cc: linux-xfs@oss.sgi.com Subject: Re: unable to open initial console In-Reply-To: <997204978.1382.1.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 7 Aug 2001, Eric Sandeen wrote: > On 07 Aug 2001 12:57:08 -0400, Jonathan Dill wrote: > > Hi folks, > > > > I'm having problems with systems upgraded from kernel-2.4.2-SGI_XFS_1.0 > > to kernel-2.4.3-SGI_XFS_1.0.1 that when I try to boot the new kernel, > > boot fails with the message, "unable to open initial console." I can > > still boot into the 2.4.2 kernel with no problems. I thought maybe the > > problem was due to devfs, because I think the devfs kernel message does > > not appear, but adding devfs=mount or devfs=nomount did not help. > > Hm, perhaps this is devfs-related... > > devfs is completely gone from the 1.0.1 kernel, so "devfs=mount" won't > do anything for you. > > Perhaps something about your on-disk /dev is wrong... If there's a way > to re-install the dev RPM (or verify it) that might fix the problem. > > Can you boot 2.4.2 with "devfs=nomount"? Someone else bumped into the exact same problem. You need to reinstall the devices rpm because it (obviously) didn't get installed on the 1.0 release installer. I am not completely sure it sure what the package is called like. From owner-linux-xfs@oss.sgi.com Tue Aug 7 10:54:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77Hs2p05506 for linux-xfs-outgoing; Tue, 7 Aug 2001 10:54:02 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77Hs1V05485 for ; Tue, 7 Aug 2001 10:54:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA06875 for ; Tue, 7 Aug 2001 10:51:54 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2651143; Tue, 7 Aug 2001 12:52:44 -0500 (CDT) 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 MAA67560; Tue, 7 Aug 2001 12:52:44 -0500 (CDT) Subject: Re: unable to open initial console From: Eric Sandeen To: Seth Mos Cc: Jonathan Dill , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 07 Aug 2001 12:49:32 -0500 Message-Id: <997206572.1279.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 07 Aug 2001 19:44:38 +0200, Seth Mos wrote: > Someone else bumped into the exact same problem. You need to reinstall the > devices rpm because it (obviously) didn't get installed on the 1.0 > release installer. I am not completely sure it sure what the package is > called like. Actually, the dev RPM (dev-.i386.rpm) should be installed even in 1.0, it's just not used. That's why you should be able to use "devfs=nomount" in a 1.0-installer-installed system, and still have things work. But re-installing the dev RPM is probably a good place to start w/ this problem. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 7 11:09:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77I9Av05844 for linux-xfs-outgoing; Tue, 7 Aug 2001 11:09:10 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77I97V05822 for ; Tue, 7 Aug 2001 11:09:07 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA14454; Tue, 7 Aug 2001 20:09:06 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id UAA19373; Tue, 7 Aug 2001 20:09:01 +0200 (CEST) Date: Tue, 7 Aug 2001 20:09:01 +0200 (CEST) From: Seth Mos To: Eric Sandeen cc: Jonathan Dill , linux-xfs@oss.sgi.com Subject: Re: unable to open initial console In-Reply-To: <997206572.1279.5.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 7 Aug 2001, Eric Sandeen wrote: > On 07 Aug 2001 19:44:38 +0200, Seth Mos wrote: > > > Someone else bumped into the exact same problem. You need to reinstall the > > devices rpm because it (obviously) didn't get installed on the 1.0 > > release installer. I am not completely sure it sure what the package is > > called like. > > Actually, the dev RPM (dev-.i386.rpm) should be installed even > in 1.0, it's just not used. That's why you should be able to use > "devfs=nomount" in a 1.0-installer-installed system, and still have > things work. Not if /dev/console is missing. I just saw the code from the kernel fly by on linux-mips where they were discussing a similar problem. If you cant open /dev/console this is the exact erorr message. Cheers Seth From owner-linux-xfs@oss.sgi.com Tue Aug 7 11:13:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77IDUv06015 for linux-xfs-outgoing; Tue, 7 Aug 2001 11:13:30 -0700 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 f77IDSV05996 for ; Tue, 7 Aug 2001 11:13:28 -0700 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 GHPMO500.5AE; Tue, 7 Aug 2001 14:14:29 -0400 Message-ID: <3B702FC6.EB924DB7@umbi.umd.edu> Date: Tue, 07 Aug 2001 14:13:26 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: unable to open initial console References: <997206572.1279.5.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 Thanks everyone for the quick responses. I can't boot the 2.4.2 kernel with devfs=nomount, so it looks like the devices is indeed the problem. However, reinstalling dev is turning out to be not so simple with devfs mounted on /dev--the install just hangs, as I suppose it is trying to install the inodes into the devfs. I think I'm going to have to try booting off the installation CD and try to fix the devices from the bash prompt on console 2. With luck, I might just need /dev/tty1 to get the system to at least boot up so I can fix it. Otherwise, if there is some way to make an archive of inodes, I might be able to make an archive of the inodes from another computer and restore the archive, then reboot and reinstall dev. Or I could try to install the dev RPM that way. Eric Sandeen wrote: > On 07 Aug 2001 19:44:38 +0200, Seth Mos wrote: > > > Someone else bumped into the exact same problem. You need to reinstall the > > devices rpm because it (obviously) didn't get installed on the 1.0 > > release installer. I am not completely sure it sure what the package is > > called like. > > Actually, the dev RPM (dev-.i386.rpm) should be installed even > in 1.0, it's just not used. That's why you should be able to use > "devfs=nomount" in a 1.0-installer-installed system, and still have > things work. > > But re-installing the dev RPM is probably a good place to start w/ this > problem. - "Jonathan F. Dill" (dill@umbi.umd.edu) CARB Systems and Network Administrator Home Page: http://www.umbi.umd.edu/~dill From owner-linux-xfs@oss.sgi.com Tue Aug 7 11:19:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77IJwp06230 for linux-xfs-outgoing; Tue, 7 Aug 2001 11:19:58 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77IJtV06209 for ; Tue, 7 Aug 2001 11:19:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA753355 for ; Tue, 7 Aug 2001 20:19:20 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2649663; Tue, 7 Aug 2001 13:18:23 -0500 (CDT) 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 NAA67761; Tue, 7 Aug 2001 13:18:23 -0500 (CDT) Subject: Re: unable to open initial console From: Eric Sandeen To: Jonathan Dill Cc: Seth Mos , linux-xfs@oss.sgi.com In-Reply-To: <3B702FC6.EB924DB7@umbi.umd.edu> References: <997206572.1279.5.camel@stout.americas.sgi.com> <3B702FC6.EB924DB7@umbi.umd.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 07 Aug 2001 13:15:12 -0500 Message-Id: <997208112.1282.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 07 Aug 2001 14:13:26 -0400, Jonathan Dill wrote: > I think I'm going to have to try > booting off the installation CD and try to fix the devices from the bash > prompt on console 2. If you type "linux rescue" at te CD prompt you'll get a shell with your system mounted under /mnt/sysimage, I believe. Hopefully a chroot to there will let you poke around. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 7 12:02:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77J2JW07000 for linux-xfs-outgoing; Tue, 7 Aug 2001 12:02:19 -0700 Received: from ente.berdmann.de (frnk-d5141a7d.dsl.mediaWays.net [213.20.26.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77J2DV06981 for ; Tue, 7 Aug 2001 12:02:13 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15UC79-0005HS-00; Tue, 07 Aug 2001 21:02:03 +0200 Message-ID: <3B703B2B.578368A2@berdmann.de> Date: Tue, 07 Aug 2001 21:02:03 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Timothy Shimmin CC: Linux XFS Mailing List Subject: Re: xfsrestore deletes files in cumulative restores (was: xfsdump/xfsrestore fails Zwicky's torture test) References: <3B3F5079.F1776C04@berdmann.de> <3B4838D0.5BAEDF4F@berdmann.de> <3B485058.9389834C@berdmann.de> <20010709155428.C11622@boing.melbourne.sgi.com> <3B597097.6CBEC94D@berdmann.de> <20010807145838.E78571@boing.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Timothy, thank you very much for your valuable input and your detailed discussion of xfsrestore's dump tree construction algorithm. I'd prefer to continue this issue on the list so others can learn from and contribute to, too. > > "No one cares if you can back up - only if you can recover." (W. Curtis > > Preston, Unix Backup & Recovery, O'Reilly, 1999, xiv) > I should have a look at this book. http://www.oreilly.com/catalog/unixbr/ I think I'll construct some testbeds, i.e. little filesystems with some hard links in it, do xfsdump, create some more links, do an incremental dump, create some more links, do an incremental dump of a higher level, create some more links... Regards, Bernie > > > > xfsrestore.debug.3 told me xfsrestore had deleted user/be/Sent/xy/290.: > > > > > > > > [...] > > > > /usr/sbin/xfsrestore: rename nondir user/be/Sent/xy/290. to > > > > orphanage/9074670.1 > > > > /usr/sbin/xfsrestore: unlink nondir orphanage/9074670.1 > > > > [...] > > > > /usr/sbin/xfsrestore: restoring user/be/Sent/xy/291. (9074676 0) > > > > /usr/sbin/xfsrestore: restoring regular file ino 9074676 > > > > user/be/Sent/xy/291. > > > > /usr/sbin/xfsrestore: truncating user/be/Sent/xy/291. from 0 to 775 > > > > /usr/sbin/xfsrestore: restore complete: 76 seconds elapsed > > > > > > > > What's going on here? I'm using xfsdump-1.0.9-0. > > > > > > It looks like that this is happening in the function > > > xfsdump/restore/tree.c/proc_hardlinks_cb(). > > > I'm not sure what this code is trying to do ! > > > However, I'll post a bug on this at SGI and > > > look into it further. > > > Thanks for the report. > > > > I just investigated it a little further. I did another cumulative > > restore of /var/spool/imap (based on level 0 on 2001-07-12). This time > > I'm using xfsdump-1.0.11-0. > > (/usr/sbin/amrestore -p $TAPE ente imap | /usr/sbin/xfsrestore -r -v > > trace - .) > xfsrestore.debug.0 > > (/usr/sbin/amrestore -p $TAPE ente imap | /usr/sbin/xfsrestore -r -v > > trace - .) > xfsrestore.debug.1 > > (/usr/sbin/amrestore -p $TAPE ente imap | /usr/sbin/xfsrestore -r -v > > trace - .) > xfsrestore.debug.2 > > (/usr/sbin/amrestore -p $TAPE ente imap | /usr/sbin/xfsrestore -r -v > > trace - .) > xfsrestore.debug.3 > > (/usr/sbin/amrestore -p $TAPE ente imap | /usr/sbin/xfsrestore -r -v > > trace - .) > xfsrestore.debug.4 > > > > One of the files missing after the complete restore is user/ap/in/52. > > xfsrestore told me it was deleted applying level 2: > > # grep user/ap/in/52. xfsrestore.debug.? > > xfsrestore.debug.0:/usr/sbin/xfsrestore: link user/ap/in/MKSports/21. to > > user/ap/in/52. (4504894 0) > > xfsrestore.debug.0:/usr/sbin/xfsrestore: linking user/ap/in/MKSports/21. > > to user/ap/in/52. > > xfsrestore.debug.2:/usr/sbin/xfsrestore: unlink user/ap/in/52. > > > > But it's still there in /var/spool/imap (where the dump was taken from): > > # ls -li /var/spool/imap/user/ap/in/52. > > 4504894 -rw------- 2 cyrus root 5464 Apr 13 14:12 > > /var/spool/imap/user/ap/in/52. > > > > So it has a hardlink to it. What's the other filename pointing to the > > inode 4504894? > > # find /var/spool/imap/user/ap -inum 4504894 -ls > > 4504894 8 -rw------- 2 cyrus root 5464 Apr 13 14:12 > > /var/spool/imap/user/ap/in/MKSports/21. > > 4504894 8 -rw------- 2 cyrus root 5464 Apr 13 14:12 > > /var/spool/imap/user/ap/in/52. > > > > In the restored tree, there's only user/ap/in/MKSports/21.: > > # ll user/ap/in/MKSports/21. > > -rw------- 1 cyrus root 5464 Apr 13 14:12 > > user/ap/in/MKSports/21. > > No other link to it. > > > > This file was restored in level 0, too: > > # grep user/ap/in/MKSports/21. xfsrestore.debug.? > > xfsrestore.debug.0:/usr/sbin/xfsrestore: restoring > > user/ap/in/MKSports/21. (4504894 0) > > xfsrestore.debug.0:/usr/sbin/xfsrestore: restoring regular file ino > > 4504894 user/ap/in/MKSports/21. > > xfsrestore.debug.0:/usr/sbin/xfsrestore: truncating > > user/ap/in/MKSports/21. from 0 to 5464 > > xfsrestore.debug.0:/usr/sbin/xfsrestore: link user/ap/in/MKSports/21. to > > user/ap/in/52. (4504894 0) > > xfsrestore.debug.0:/usr/sbin/xfsrestore: linking user/ap/in/MKSports/21. > > to user/ap/in/52. > > > > Ok, let's grep some more... > > # grep -n "unlink " /usr/src/linux-2.4-xfs/cmd/xfsdump/restore/* > > /usr/src/linux-2.4-xfs/cmd/xfsdump/restore/tree.c:1442: > > "unlink %s\n", > > (CVS checkout of this morning) > > > > This line is in the function noref_elim_recurse (line 1181 in tree.c) > > and there's a comment after the else in line 1330: > > /* determine if we can unlink this node. > > * if its not real, and not refed, simple. > > * if real and not refed and there is at least > > * one unreal refed node and no other real > > * nodes around, must put this one in orphanage > > * rather than unlinking it. > > */ > > So, what's an unreal node? And a node not referred to? > Good questions. > I wish I had good answers :) > I didn't write the code (twas written in '95 and the author has gone) > so I can only go by the code as well. > And this part of the code I am not familiar with. > > Looking at tree.c: > #define NF_REAL ( 1 << 0 ) > /* set when the corresponding file/dir has been created in > * the restore destination. > > #define NF_REFED ( 1 << 2 ) > /* indicates node is still referenced according to incremental/resumed > * dump. used to detect dirents no longer used. prior to restoring > * a dump session, this flag is cleared in all nodes. during the dirent > * restoral, it is set. it may also be set during the adjustment > * for referenced but undumped directories. NOTE: nodes in the > * orphanage NEVER have this flag set. > > And looking where NF_REAL is set (... |= NF_REAL) it seems to be when > (1) making the directories (mkdirs_recurse()), > (2) when restoring the file (tree_cb_links()) and > (3) when processing hardlinks (proc_hardlinks()). > All 3 things happen _after_ calling noref_elim_recurse(). > So it seems likely to me that at that point the entry is not considered > real (i.e. not restored yet). > > And looking where NF_REFED is set (... |= NF_REFED), > (1) when adding a directory entry (tree_addent()), > which exists in the entry tree already, > then we mark it as referenced. > ASIDE: A directory entry is expected to appear at least twice. > As the directory itself and as an entry in the parent directory. > So the 2nd time it appears it will be marked as referenced. > If the entry appears first and thus it doesn't have a parent yet, > it will be placed as a child of the orhpanage directory. > (2) when adding a non-directory entry (tree_addent()), > and the entry already exists (same name and parent), > then we mark it as referenced. > [I'm not sure how this happens - need to try examples] > (3) when adjusting for referenced but undumped dirs (tree_adjref()). > I think this is something to do with marking the entries of a > directory as referenced if the directory has not been dumped > and is referenced (i.e. has not changed and still exists). > > > Maybe this lost link user/ap/in/52. was not referred to in the level 0 > > dump? Who's doing the mess? xfsdump not referring to or telling > > xfsrestore of unreal nodes? Or does xfsrestore get things wrong? > I would say the problem lies in xfsrestore. > Xfsrestore is the one which builds a directory-entry tree from > the initial dump of directory entries. The nodes in this tree are > what have the NF_* flags set. > > Getting back to the problem.... > I'll have to continue this later, I need to get back to some > IRIX bugs. > > Later, > Tim. From owner-linux-xfs@oss.sgi.com Tue Aug 7 12:33:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77JXSf10745 for linux-xfs-outgoing; Tue, 7 Aug 2001 12:33:28 -0700 Received: from mail.levigo.de (mail.levigo.de [193.197.156.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77JXLV10711 for ; Tue, 7 Aug 2001 12:33:22 -0700 Received: from levigo.de (zoidberg.cogito.de [193.197.156.88]) by mail.levigo.de (Postfix) with ESMTP id B1CCF7E2F for ; Tue, 7 Aug 2001 21:32:08 +0200 (CEST) Message-ID: <3B704280.AF4A482F@levigo.de> Date: Tue, 07 Aug 2001 21:33:20 +0200 From: Klaus Rein Organization: levigo systems gmbh X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: strange nfs... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have a strange problem with xfs (kernel 2.4.7, cvs checkout from about July, 20th) and nfs (kernel nfs server). When the attached script is run against a nfs mounted xfs filesystem the size of the directory trees checked with du is not constant: # du -sk linux.* 142448 linux.orig 142448 linux.pass.0 142448 linux.pass.1 142448 linux.pass.2 142448 linux.pass.3 142448 linux.pass.4 142448 linux.pass.5 142448 linux.pass.6 142448 linux.pass.7 392036 linux.pass.8 701588 linux.pass.9 696992 linux.pass.10 695468 linux.pass.11 705772 linux.pass.12 703256 linux.pass.13 686964 linux.pass.14 709092 linux.pass.15 Comparing two directory trees shows: # du -sk linux.orig/* linux.pass.15/* 20 linux.orig/COPYING 76 linux.orig/CREDITS 12 linux.orig/CVS 5728 linux.orig/Documentation 36 linux.orig/MAINTAINERS 20 linux.orig/Makefile 16 linux.orig/README 4 linux.orig/REPORTING-BUGS 12 linux.orig/Rules.make 26668 linux.orig/arch 67252 linux.orig/drivers 14036 linux.orig/fs 20180 linux.orig/include 36 linux.orig/init 100 linux.orig/ipc 212 linux.orig/kdb 404 linux.orig/kernel 120 linux.orig/lib 420 linux.orig/mm 6632 linux.orig/net 460 linux.orig/scripts 64 linux.pass.15/COPYING 128 linux.pass.15/CREDITS 192 linux.pass.15/CVS 34244 linux.pass.15/Documentation 64 linux.pass.15/MAINTAINERS 64 linux.pass.15/Makefile 64 linux.pass.15/README 64 linux.pass.15/REPORTING-BUGS 64 linux.pass.15/Rules.make 171172 linux.pass.15/arch 215548 linux.pass.15/drivers 57084 linux.pass.15/fs 187856 linux.pass.15/include 320 linux.pass.15/init 576 linux.pass.15/ipc 1156 linux.pass.15/kdb 1988 linux.pass.15/kernel 900 linux.pass.15/lib 1604 linux.pass.15/mm 32600 linux.pass.15/net 3336 linux.pass.15/scripts But ls reports identical file sizes: # ls -ld linux.orig/* linux.pass.15/* drwxr-xr-x 18 2008 101 4096 Jul 10 17:16 linux.orig/arch -rw-r--r-- 1 2008 101 18633 Jun 9 04:44 linux.orig/COPYING -rw-r--r-- 1 2008 101 76191 Jul 5 08:13 linux.orig/CREDITS drwxr-xr-x 2 2008 101 48 Jul 19 16:16 linux.orig/CVS drwxr-xr-x 29 2008 101 4096 Jul 19 16:16 linux.orig/Documentation drwxr-xr-x 39 2008 101 4096 Jul 19 16:16 linux.orig/drivers drwxr-xr-x 44 2008 101 4096 Jul 19 16:16 linux.orig/fs drwxr-xr-x 25 2008 101 4096 Jul 10 17:34 linux.orig/include drwxr-xr-x 3 2008 101 45 Jul 10 17:34 linux.orig/init drwxr-xr-x 3 2008 101 93 Jul 10 17:34 linux.orig/ipc drwxr-xr-x 4 2008 101 4096 Jul 10 17:34 linux.orig/kdb drwxr-xr-x 3 2008 101 4096 Jul 19 16:16 linux.orig/kernel drwxr-xr-x 3 2008 101 4096 Jul 13 12:18 linux.orig/lib -rw-r--r-- 1 2008 101 35274 Jul 19 16:16 linux.orig/MAINTAINERS -rw-r--r-- 1 2008 101 17744 Jul 19 16:16 linux.orig/Makefile drwxr-xr-x 3 2008 101 4096 Jul 19 16:16 linux.orig/mm drwxr-xr-x 28 2008 101 4096 Jul 19 16:16 linux.orig/net -rw-r--r-- 1 2008 101 14491 Apr 2 19:13 linux.orig/README -rw-r--r-- 1 2008 101 2815 Mai 2 08:22 linux.orig/REPORTING-BUGS -rw-r--r-- 1 2008 101 8884 Apr 2 19:13 linux.orig/Rules.make drwxr-xr-x 6 2008 101 4096 Jul 10 17:35 linux.orig/scripts drwxr-xr-x 18 2008 101 4096 Jul 10 17:16 linux.pass.15/arch -rw-r--r-- 1 2008 101 18633 Jun 9 04:44 linux.pass.15/COPYING -rw-r--r-- 1 2008 101 76191 Jul 5 08:13 linux.pass.15/CREDITS drwxr-xr-x 2 2008 101 48 Jul 19 16:16 linux.pass.15/CVS drwxr-xr-x 29 2008 101 4096 Jul 19 16:16 linux.pass.15/Documentation drwxr-xr-x 39 2008 101 4096 Jul 19 16:16 linux.pass.15/drivers drwxr-xr-x 44 2008 101 4096 Jul 19 16:16 linux.pass.15/fs drwxr-xr-x 25 2008 101 4096 Jul 10 17:34 linux.pass.15/include drwxr-xr-x 3 2008 101 45 Jul 10 17:34 linux.pass.15/init drwxr-xr-x 3 2008 101 93 Jul 10 17:34 linux.pass.15/ipc drwxr-xr-x 4 2008 101 4096 Jul 10 17:34 linux.pass.15/kdb drwxr-xr-x 3 2008 101 4096 Jul 19 16:16 linux.pass.15/kernel drwxr-xr-x 3 2008 101 4096 Jul 13 12:18 linux.pass.15/lib -rw-r--r-- 1 2008 101 35274 Jul 19 16:16 linux.pass.15/MAINTAINERS -rw-r--r-- 1 2008 101 17744 Jul 19 16:16 linux.pass.15/Makefile drwxr-xr-x 3 2008 101 4096 Jul 19 16:16 linux.pass.15/mm drwxr-xr-x 28 2008 101 4096 Jul 19 16:16 linux.pass.15/net -rw-r--r-- 1 2008 101 14491 Apr 2 19:13 linux.pass.15/README -rw-r--r-- 1 2008 101 2815 Mai 2 08:22 linux.pass.15/REPORTING-BUGS -rw-r--r-- 1 2008 101 8884 Apr 2 19:13 linux.pass.15/Rules.make drwxr-xr-x 6 2008 101 4096 Jul 10 17:35 linux.pass.15/scripts And finally diff -r linux.orig linux.pass.15 does not find any differences. Both machines are PIII/800 with scsi disks and RedHat 7.1. The compiler is gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) which should to be ok (according to the comments in the makefile of the kernel tree). If it was only du reporting wrong values it would not bother me, but the reported space on the filesystem is really in use. Klaus. ----------8<--------------------8<--------------------8<---------- #!/bin/sh echo This is memtest.sh # This is where we will run the tests at TEST_DIR=/net/nfsserver/ # The location of the linux kernel source file we will be using SOURCE_FILE=/tmp/linux-2.4.7-xfs.tar.gz # How many passes to run of this test, higher numbers are better NR_PASSES=200 # How many passes to run simultaneously (in order to flush memory on # large memory machines). #NR_SIMULTANEOUS=30 NR_SIMULTANEOUS=15 cd $TEST_DIR echo TEST_DIR is $TEST_DIR echo # Remove any possible left over directories from a cancelled previous run echo `date`: rm -rf linux linux.orig linux.pass.* rm -fr linux linux.orig linux.pass.* # Unpack the one copy of the source tree that we will be comparing against echo `date`: unpacking linux.orig zcat $SOURCE_FILE | tar xf - mv linux linux.orig i=0 while [ "$i" -lt "$NR_PASSES" ]; do j=0 while [ "$j" -lt "$NR_SIMULTANEOUS" ]; do echo `date`: unpacking linux.pass.$j zcat $SOURCE_FILE | tar xf - mv linux linux.pass.$j j=`expr $j + 1` done j=0 while [ "$j" -lt "$NR_SIMULTANEOUS" ]; do echo `date`: diff -r linux.orig linux.pass.$j diff -r linux.orig linux.pass.$j | grep -v "Common subdirectories" echo `date`: rm -rf linux.pass.$j rm -fr linux.pass.$j j=`expr $j + 1` done echo `date`: pass $i of $NR_PASSES finished i=`expr $i + 1` done # Clean up after ourselves echo `date`: cleaning up rm -fr linux linux.orig linux.pass.* echo `date`: done From owner-linux-xfs@oss.sgi.com Tue Aug 7 12:34:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77JYxb11062 for linux-xfs-outgoing; Tue, 7 Aug 2001 12:34:59 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77JYvV11032 for ; Tue, 7 Aug 2001 12:34:57 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA03163; Tue, 7 Aug 2001 21:34:56 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA24080; Tue, 7 Aug 2001 21:34:56 +0200 (CEST) Date: Tue, 7 Aug 2001 21:34:56 +0200 (CEST) From: Seth Mos To: Jonathan Dill cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: unable to open initial console In-Reply-To: <3B702FC6.EB924DB7@umbi.umd.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 7 Aug 2001, Jonathan Dill wrote: > Thanks everyone for the quick responses. I can't boot the 2.4.2 kernel > with devfs=nomount, so it looks like the devices is indeed the problem. > However, reinstalling dev is turning out to be not so simple with devfs > mounted on /dev--the install just hangs, as I suppose it is trying to > install the inodes into the devfs. I think I'm going to have to try > booting off the installation CD and try to fix the devices from the bash > prompt on console 2. With luck, I might just need /dev/tty1 to get the > system to at least boot up so I can fix it. Otherwise, if there is some > way to make an archive of inodes, I might be able to make an archive of > the inodes from another computer and restore the archive, then reboot > and reinstall dev. Or I could try to install the dev RPM that way. Boot the installer with lunux rescue to get your xfs supported linux rescue environment. From owner-linux-xfs@oss.sgi.com Tue Aug 7 13:26:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77KQ2J18416 for linux-xfs-outgoing; Tue, 7 Aug 2001 13:26:02 -0700 Received: from imapserver2.fnal.gov (imapserver2.fnal.gov [131.225.9.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77KPxV18396 for ; Tue, 7 Aug 2001 13:25:59 -0700 Received: from imapserver2.fnal.gov ([131.225.9.7]) by imapserver2.fnal.gov (Netscape Messaging Server 3.62) with SMTP id 873 for ; Tue, 7 Aug 2001 15:25:58 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserver2.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001080715255732029 ; Tue, 07 Aug 2001 15:25:57 -0500 Message-ID: <3B704F8B.1252660B@fnal.gov> Date: Tue, 07 Aug 2001 15:28:59 -0500 From: yocum@fnal.gov 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: Federico Sevilla III CC: Tom Tran , linux-xfs@oss.sgi.com, linux@3ware.com Subject: Re: corrupt inode References: <70F2193152F7D411B53F00D0B79E84946A0B1C@cougar> <997198340.3b700a04af5f8@horde.leathercollection.ph> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jijo, Seth, Tom, I'm here! But I've been a little under the gun, so just got a chance to get to my xfs folder. I'm also seeing the inode weirdness that Jijo is seeing on XFS, and I think it's in the FS and not in the controller (you can relax, Tom ;). I'm having directories disappear and re-appear at random. It's quite interesting. Some directories are copies of other directories. Somehow the inode tables are getting *very* confused. (Tom: this is a completely different problem than the one I was having during my drive failures (simulated and real)). For instance, one dir that's supposed to have about 1000 files in it all of a sudden became empty, but trying to do an ls on it yielded a "file objs does not exist." The weird thing is, the dir 'objs' is 2 levels higher in the tree, as well as in a bunch of other directories parallel to this one. I finally punted and tried rm-ing it, which failed with the same error. I did the 'rm -rf ' a few times for good measure, and all of a sudden the contents of the directory came back. Here's the kernel dump in /var/log/messages (I think the first line says it all): Aug 7 13:28:59 sdssdp6 kernel: kernel BUG at inode.c:486! Aug 7 13:28:59 sdssdp6 kernel: invalid operand: 0000 Aug 7 13:28:59 sdssdp6 kernel: CPU: 0 Aug 7 13:28:59 sdssdp6 kernel: EIP: 0010:[clear_inode+51/292] Aug 7 13:28:59 sdssdp6 kernel: EIP: 0010:[] Aug 7 13:28:59 sdssdp6 kernel: EFLAGS: 00010292 Aug 7 13:28:59 sdssdp6 kernel: eax: 0000001b ebx: c7627d80 ecx: 00000002 edx: 00000002 Aug 7 13:28:59 sdssdp6 kernel: esi: e0a0d440 edi: dfb2d660 ebp: 00000000 esp: c884ff44 Aug 7 13:28:59 sdssdp6 kernel: ds: 0018 es: 0018 ss: 0018 Aug 7 13:28:59 sdssdp6 kernel: Process tcl (pid: 13828, stackpage=c884f000) Aug 7 13:28:59 sdssdp6 kernel: Stack: c02a4ee0 c02a4f7f 000001e6 c7627d80 c014e771 c7627d80 c085ae20 c7627d80 Aug 7 13:28:59 sdssdp6 kernel: e09ffffd c7627d80 c085ae20 c014bcea c085ae20 c7627d80 d6885ce0 dd89bf60 Aug 7 13:28:59 sdssdp6 kernel: c0136e75 c085ae20 c884e000 bffff010 400b7873 bffff108 c085ae20 c884ffa4 Aug 7 13:28:59 sdssdp6 kernel: Call Trace: [iput+349/364] [] [dput+234/340] [sys_chdir+253/304] [sys_read+191/200] [system_call+51/56] Aug 7 13:28:59 sdssdp6 kernel: Call Trace: [] [] [] [] [] [] Aug 7 13:28:59 sdssdp6 kernel: Aug 7 13:28:59 sdssdp6 kernel: Code: 0f 0b 83 c4 0c 8d 74 26 00 8b 83 f4 00 00 00 a8 10 75 26 68 Here's what I've got for hardware and software in this system: 2 7810 3ware cards Red Hat 7.1 kernel 2.4.5-SGI_XFS_1.0.1enterprise I've updated the XFS cmds thusly: acl-1.1.1-0.i386.rpm acl-devel-1.1.1-0.i386.rpm attr-1.1.2-0.i386.rpm attr-devel-1.1.2-0.i386.rpm dmapi-0.2.2-0.i386.rpm dmapi-devel-0.2.2-0.i386.rpm xfsprogs-1.3.3-0.i386.rpm xfsprogs-devel-1.3.3-0.i386.rpm 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 Tue Aug 7 14:03:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77L38C23721 for linux-xfs-outgoing; Tue, 7 Aug 2001 14:03:08 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77L35V23699 for ; Tue, 7 Aug 2001 14:03:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07461 for ; Tue, 7 Aug 2001 14:00:58 -0700 (PDT) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2650064; Tue, 7 Aug 2001 16:00:27 -0500 (CDT) 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 QAA96206; Tue, 7 Aug 2001 16:00:27 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id QAA15972; Tue, 7 Aug 2001 16:00:26 -0500 (CDT) Message-Id: <200108072100.QAA15972@fsgi158.americas.sgi.com> Subject: Re: corrupt inode To: yocum@fnal.gov Date: Tue, 7 Aug 2001 16:00:25 -0500 (CDT) Cc: jijo@leathercollection.ph (Federico Sevilla III), tom.tran@3ware.com (Tom Tran), linux-xfs@oss.sgi.com, linux@3ware.com In-Reply-To: <3B704F8B.1252660B@fnal.gov> from "yocum@fnal.gov" at Aug 07, 2001 03:28:59 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 Are you using NFS? This is a known bug when using NFS on 2.4.5. See http://www.cs.helsinki.fi/linux/linux-kernel/2001-21/0009.html for more info. Tad > > Here's the kernel dump in /var/log/messages (I think the first line says it > all): > > Aug 7 13:28:59 sdssdp6 kernel: kernel BUG at inode.c:486! > Aug 7 13:28:59 sdssdp6 kernel: invalid operand: 0000 > Aug 7 13:28:59 sdssdp6 kernel: CPU: 0 > Aug 7 13:28:59 sdssdp6 kernel: EIP: 0010:[clear_inode+51/292] > Aug 7 13:28:59 sdssdp6 kernel: EIP: 0010:[] > Aug 7 13:28:59 sdssdp6 kernel: EFLAGS: 00010292 > Aug 7 13:28:59 sdssdp6 kernel: eax: 0000001b ebx: c7627d80 ecx: > 00000002 edx: 00000002 > Aug 7 13:28:59 sdssdp6 kernel: esi: e0a0d440 edi: dfb2d660 ebp: > 00000000 esp: c884ff44 > Aug 7 13:28:59 sdssdp6 kernel: ds: 0018 es: 0018 ss: 0018 > Aug 7 13:28:59 sdssdp6 kernel: Process tcl (pid: 13828, stackpage=c884f000) > Aug 7 13:28:59 sdssdp6 kernel: Stack: c02a4ee0 c02a4f7f 000001e6 c7627d80 > c014e771 c7627d80 c085ae20 c7627d80 > Aug 7 13:28:59 sdssdp6 kernel: e09ffffd c7627d80 c085ae20 c014bcea > c085ae20 c7627d80 d6885ce0 dd89bf60 > Aug 7 13:28:59 sdssdp6 kernel: c0136e75 c085ae20 c884e000 bffff010 > 400b7873 bffff108 c085ae20 c884ffa4 > Aug 7 13:28:59 sdssdp6 kernel: Call Trace: [iput+349/364] [] > [dput+234/340] [sys_chdir+253/304] [sys_read+191/200] [system_call+51/56] > Aug 7 13:28:59 sdssdp6 kernel: Call Trace: [] [] > [] [] [] [] > Aug 7 13:28:59 sdssdp6 kernel: > Aug 7 13:28:59 sdssdp6 kernel: Code: 0f 0b 83 c4 0c 8d 74 26 00 8b 83 f4 00 > 00 00 a8 10 75 26 68 > > > Here's what I've got for hardware and software in this system: > > 2 7810 3ware cards > Red Hat 7.1 > kernel 2.4.5-SGI_XFS_1.0.1enterprise > > I've updated the XFS cmds thusly: > > acl-1.1.1-0.i386.rpm > acl-devel-1.1.1-0.i386.rpm > attr-1.1.2-0.i386.rpm > attr-devel-1.1.2-0.i386.rpm > dmapi-0.2.2-0.i386.rpm > dmapi-devel-0.2.2-0.i386.rpm > xfsprogs-1.3.3-0.i386.rpm > xfsprogs-devel-1.3.3-0.i386.rpm > > > 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 Tue Aug 7 14:28:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77LSVA26955 for linux-xfs-outgoing; Tue, 7 Aug 2001 14:28:31 -0700 Received: from cvo-exchange.cvo.roguewave.com (cvo-ext.roguewave.com [12.22.36.198]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77LSOV26932 for ; Tue, 7 Aug 2001 14:28:24 -0700 Received: by cvo-exchange.roguewave.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Aug 2001 14:28:14 -0700 Message-ID: From: Poul Petersen To: "'linux-xfs@oss.sgi.com'" Subject: Kernel Oops RedHat 7.1 kernel-2.4.5 xfx-1.0.1 Date: Tue, 7 Aug 2001 14:28:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As I mentioned in a previous post, I'm running RedHat 7.1 with the manually patched 2.4.5 kernel and xfs-1.0.1 on a dual PII (400) with 1 Gig of RAM. The XFS filesystems are located on a SAN RAID device accessed through a qlogic 2100 Fibre Channel card (using the qla2x00 module provided by Qlogic, ver 4.25). This system acts as a "gateway" by mounting the disks from the SAN and then exporting them to an array of hosts (Solaris, IRIX, Linux, AIX, etc) via NFS. So far, we have had a total of four system oops's. The first oops was "unprovoked". When we rebooted, the system generated the same oops ten minutes later. Then everything was OK. Two weeks later, we used xfs_growfs to grow one of the partitions which worked great (very cool). A few days later, the machine was accidentaly power cycled (human oops). During bootup, the system oops'd when trying to mount the XFS partition we had grown. That disk remains unmountable, and will oops any of the three machines we have on the SAN when mounted (we had a backup of the data and sufficient extra, so we just left this partition of death for testing). The fourth oops just occurred today when I tried to xfsdump a partition. I've included the ksymoops output for each of the oops's in order. Any ideas? Many thanks, -poul This was the "unprovoked" oops: Unable to handle kernel paging request at virtual address f8b65960 c025fe90 *pde = 37ddf067 Oops: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: f8b65940 ebx: 00000003 ecx: f8b65940 edx: f7da5980 esi: 000001bc edi: 0000002a ebp: c03b68ec esp: f5041ea4 ds: 0018 es: 0018 ss: 0018 Process insmod (pid: 1258, stackpage=f5041000) Stack: c0349800 00000000 00000000 f8a89700 c023bd90 00000000 00000004 00000001 00000001 00000000 c010ee5c 00000000 00000002 00000000 00000000 f7c60000 f5040000 00000282 00034063 00000282 00000000 c0336e14 f8a42000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 8b 40 20 85 c0 74 08 39 d0 0f 85 f1 ff ff ff 85 c0 75 27 8d >>EIP; c025fe90 <===== Trace; f8a89700 Trace; c023bd90 Trace; c010ee5c Trace; f8a42000 <[qla2x00]fw2200tp_code01+e78a/1397e> Trace; f8a4cd65 <[qla2x00]fw2300tp_code01+5b67/143aa> Trace; f8a89700 Trace; f8a42000 <[qla2x00]fw2200tp_code01+e78a/1397e> Trace; c01147f5 Trace; f8a42060 <[qla2x00]fw2200tp_code01+e7ea/1397e> Trace; c0106e0b Code; c025fe90 00000000 <_EIP>: Code; c025fe90 <===== 0: 8b 40 20 mov 0x20(%eax),%eax <===== Code; c025fe93 3: 85 c0 test %eax,%eax Code; c025fe95 5: 74 08 je f <_EIP+0xf> c025fe9f Code; c025fe97 7: 39 d0 cmp %edx,%eax Code; c025fe99 9: 0f 85 f1 ff ff ff jne 0 <_EIP> Code; c025fe9f f: 85 c0 test %eax,%eax Code; c025fea1 11: 75 27 jne 3a <_EIP+0x3a> c025feca Code; c025fea3 13: 8d 00 lea (%eax),%eax Here is the oops we received on bootup: Unable to handle kernel NULL pointer dereference at virtual address 0000009c c01f1e98 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: 00000074 ebx: 00000074 ecx: 00000004 edx: ffffffe8 esi: ffffffe8 edi: c01c88a9 ebp: f3f9a54c esp: f4ae5aac ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 682, stackpage=f4ae5000) Stack: 00000004 ffffffe8 c01c88a9 c01c8d94 00000074 00000288 ffffffe8 f3f9a560 c033bf20 c01c8de3 ffffffe8 00000004 c01c88a9 c01c88a9 ffffffe8 00000004 00000000 00000000 10130323 f7c5d800 f3d14e40 00000004 c01ddb16 f7c5d800 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f0 fe 4b 28 0f 88 1a f3 0c 00 8b 0b 85 c9 74 20 8d 7b 28 8d >>EIP; c01f1e98 <===== Trace; c01c88a9 Trace; c01c8d94 Trace; c01c8de3 Trace; c01c88a9 Trace; c01c88a9 Trace; c01ddb16 Trace; c01de60c Trace; c018e811 Trace; c01e317e Trace; c019c239 Trace; c01eb692 Trace; c019371d Trace; c019371d Trace; c027dd6e Trace; c02896c3 Trace; c02a1d1e Trace; c028a35b Trace; c02a21b1 Trace; c02a1cd0 Trace; c01eb858 Trace; c013e06d Trace; c016c740 Trace; c016aa24 Trace; c0171062 Trace; c0168671 Trace; c02b63c3 Trace; c0168489 Trace; c0105546 Trace; c0168290 Code; c01f1e98 00000000 <_EIP>: Code; c01f1e98 <===== 0: f0 fe 4b 28 lock decb 0x28(%ebx) <===== Code; c01f1e9c 4: 0f 88 1a f3 0c 00 js cf324 <_EIP+0xcf324> c02c11bc Code; c01f1ea2 a: 8b 0b mov (%ebx),%ecx Code; c01f1ea4 c: 85 c9 test %ecx,%ecx Code; c01f1ea6 e: 74 20 je 30 <_EIP+0x30> c01f1ec8 Code; c01f1ea8 10: 8d 7b 28 lea 0x28(%ebx),%edi Code; c01f1eab 13: 8d 00 lea (%eax),%eax This is the oops we get whenever we try to mount the partition we used xfs_growfs on: Unable to handle kernel NULL pointer dereference at virtual address 00000152 c01c88ab *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[xfs_iget+219/304] EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: ffffffe8 ecx: 00000000 edx: c033bf20 esi: ea284980 edi: c033bf20 ebp: ea28496c esp: ea2e7aa8 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 976, stackpage=ea2e7000) Stack: 00000000 00000000 00000000 18000000 00000000 f7f2c000 c01d4fbf f7f2c000 00000000 18000000 00000000 00000000 ea2e7b00 00000000 00000000 18000000 00000000 00000000 00000000 00000000 00000001 00000018 c01cf529 eb6700c0 Call Trace: [xlog_recover_process_iunlinks+319/608] [xfs_log_force+57/96] [xlog_recover_finish+51/128] [xfs_log_mount_finish+30/48] [xfs_mountfs+3445/3744] [xfs_readsb+143/224] [pagebuf_rele+49/128] Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 66 83 bb 6a 01 00 00 00 75 1a 0f b7 83 50 01 00 00 25 f7 ff >>EIP; c01c88ab <===== Trace; c01d4fbf Trace; c01cf529 Trace; c01d5953 Trace; c01cf70e Trace; c01d70a5 Trace; c01d5f8f Trace; c01d5fc2 Trace; c01df22b Trace; c01df442 Trace; c01df473 Trace; c01f02be Trace; c01575dc Trace; c0121700 Trace; c0157b72 Trace; c0146890 Trace; c01481d7 Trace; c0139e57 Trace; c0137923 Trace; c0137b20 Trace; c01386d6 Trace; c01384ec Trace; c01388f4 Trace; c0106e0b Code; c01c88ab 00000000 <_EIP>: Code; c01c88ab <===== 0: 66 83 bb 6a 01 00 00 cmpw $0x0,0x16a(%ebx) <===== Code; c01c88b2 7: 00 Code; c01c88b3 8: 75 1a jne 24 <_EIP+0x24> c01c88cf Code; c01c88b5 a: 0f b7 83 50 01 00 00 movzwl 0x150(%ebx),%eax Code; c01c88bc 11: 25 f7 ff 00 00 and $0xfff7,%eax And this is the oops we got with xfsdump: Unable to handle kernel NULL pointer dereference at virtual address 00000000 00000000 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[<00000000>] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: c0396360 ebx: e8b9dbe0 ecx: cd838240 edx: c0339a20 esi: e8b9dc60 edi: e8b9dbe0 ebp: e8b9dbe0 esp: ead03ed0 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 688, stackpage=ead03000) Stack: c0169fe4 cd838240 e8b9dc60 200074c3 00000000 c016a456 e8b9dbe0 f787a740 ffffff8c 00000000 200074c3 00000000 ead15604 ed857000 c016a831 e6e1ee00 200074c3 00000000 00000000 00000001 00000286 ead15614 11270000 ead15604 Call Trace: [] [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 00000000 Before first symbol Trace; c0169fe4 Trace; c016a456 Trace; c016a831 Trace; c0170957 Trace; c0168671 Trace; c02b63c3 Trace; c0168489 Trace; c0105546 Trace; c0168290 From owner-linux-xfs@oss.sgi.com Tue Aug 7 14:53:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77LrRB30630 for linux-xfs-outgoing; Tue, 7 Aug 2001 14:53:27 -0700 Received: from imapserver2.fnal.gov (imapserver2.fnal.gov [131.225.9.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77LrOV30603 for ; Tue, 7 Aug 2001 14:53:24 -0700 Received: from imapserver2.fnal.gov ([131.225.9.7]) by imapserver2.fnal.gov (Netscape Messaging Server 3.62) with SMTP id 764 for ; Tue, 7 Aug 2001 16:53:24 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserver2.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001080716532305396 ; Tue, 07 Aug 2001 16:53:23 -0500 Message-ID: <3B706409.FE070C20@fnal.gov> Date: Tue, 07 Aug 2001 16:56:25 -0500 From: yocum@fnal.gov 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: Tad Dolphay CC: jijo@leathercollection.ph, tom.tran@3ware.com, linux-xfs@oss.sgi.com, linux@3ware.com Subject: Re: corrupt inode References: <200108072100.QAA15972@fsgi158.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was just about to reply to my own message I see that you beat me to it. Yep, I'm using NFS. Does this problem go away with later kernel versions? Would this problem cause the flaky inode problem Jijo and I am seeing? Thanks, Dan Tad Dolphay wrote: > > Are you using NFS? This is a known bug when using NFS on 2.4.5. See > http://www.cs.helsinki.fi/linux/linux-kernel/2001-21/0009.html > for more info. > > Tad > > > > Here's the kernel dump in /var/log/messages (I think the first line says it > > all): > > > > Aug 7 13:28:59 sdssdp6 kernel: kernel BUG at inode.c:486! > > Aug 7 13:28:59 sdssdp6 kernel: invalid operand: 0000 > > Aug 7 13:28:59 sdssdp6 kernel: CPU: 0 > > Aug 7 13:28:59 sdssdp6 kernel: EIP: 0010:[clear_inode+51/292] > > Aug 7 13:28:59 sdssdp6 kernel: EIP: 0010:[] > > Aug 7 13:28:59 sdssdp6 kernel: EFLAGS: 00010292 > > Aug 7 13:28:59 sdssdp6 kernel: eax: 0000001b ebx: c7627d80 ecx: > > 00000002 edx: 00000002 > > Aug 7 13:28:59 sdssdp6 kernel: esi: e0a0d440 edi: dfb2d660 ebp: > > 00000000 esp: c884ff44 > > Aug 7 13:28:59 sdssdp6 kernel: ds: 0018 es: 0018 ss: 0018 > > Aug 7 13:28:59 sdssdp6 kernel: Process tcl (pid: 13828, stackpage=c884f000) > > Aug 7 13:28:59 sdssdp6 kernel: Stack: c02a4ee0 c02a4f7f 000001e6 c7627d80 > > c014e771 c7627d80 c085ae20 c7627d80 > > Aug 7 13:28:59 sdssdp6 kernel: e09ffffd c7627d80 c085ae20 c014bcea > > c085ae20 c7627d80 d6885ce0 dd89bf60 > > Aug 7 13:28:59 sdssdp6 kernel: c0136e75 c085ae20 c884e000 bffff010 > > 400b7873 bffff108 c085ae20 c884ffa4 > > Aug 7 13:28:59 sdssdp6 kernel: Call Trace: [iput+349/364] [] > > [dput+234/340] [sys_chdir+253/304] [sys_read+191/200] [system_call+51/56] > > Aug 7 13:28:59 sdssdp6 kernel: Call Trace: [] [] > > [] [] [] [] > > Aug 7 13:28:59 sdssdp6 kernel: > > Aug 7 13:28:59 sdssdp6 kernel: Code: 0f 0b 83 c4 0c 8d 74 26 00 8b 83 f4 00 > > 00 00 a8 10 75 26 68 > > > > > > Here's what I've got for hardware and software in this system: > > > > 2 7810 3ware cards > > Red Hat 7.1 > > kernel 2.4.5-SGI_XFS_1.0.1enterprise > > > > I've updated the XFS cmds thusly: > > > > acl-1.1.1-0.i386.rpm > > acl-devel-1.1.1-0.i386.rpm > > attr-1.1.2-0.i386.rpm > > attr-devel-1.1.2-0.i386.rpm > > dmapi-0.2.2-0.i386.rpm > > dmapi-devel-0.2.2-0.i386.rpm > > xfsprogs-1.3.3-0.i386.rpm > > xfsprogs-devel-1.3.3-0.i386.rpm > > > > > > Cheers, > > Dan > > > > > > > > > > -- > > Dan Yocum > > Sloan Digital Sky Survey, Fermilab 630.840.6509 > > yocum@fnal.gov, http://www.sdss.org > > SDSS. Mapping the Universe. > > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Tue Aug 7 15:16:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77MGJj01542 for linux-xfs-outgoing; Tue, 7 Aug 2001 15:16:19 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77MGGV01511 for ; Tue, 7 Aug 2001 15:16:16 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA09729; Wed, 8 Aug 2001 00:16:07 +0200 (CEST) Message-Id: <4.3.2.7.2.20010808000642.034ee0b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Aug 2001 00:15:40 +0200 To: Poul Petersen , "'linux-xfs@oss.sgi.com'" From: Seth Mos Subject: Re: Kernel Oops RedHat 7.1 kernel-2.4.5 xfx-1.0.1 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:28 7-8-2001 -0700, Poul Petersen wrote: > As I mentioned in a previous post, I'm running RedHat 7.1 with the >manually patched 2.4.5 kernel and xfs-1.0.1 on a dual PII (400) with 1 Gig >of RAM. The XFS filesystems are located on a SAN RAID device accessed >through a qlogic 2100 Fibre Channel card (using the qla2x00 module provided >by Qlogic, ver 4.25). This system acts as a "gateway" by mounting the disks >from the SAN and then exporting them to an array of hosts (Solaris, IRIX, >Linux, AIX, etc) via NFS. So far, we have had a total of four system oops's. > > > The first oops was "unprovoked". When we rebooted, the system >generated the same oops ten minutes later. Then everything was OK. Two weeks >later, we used xfs_growfs to grow one of the partitions which worked great >(very cool). A few days later, the machine was accidentaly power cycled >(human oops). During bootup, the system oops'd when trying to mount the XFS >partition we had grown. That disk remains unmountable, and will oops any of >the three machines we have on the SAN when mounted (we had a backup of the >data and sufficient extra, so we just left this partition of death for >testing). The fourth oops just occurred today when I tried to xfsdump a >partition. I've included the ksymoops output for each of the oops's in >order. May I suggest running xfs_repair after growing a fs. It think it sets some of the neccesary bits right that would otherwise hamper recovery. Although i doubt it shoold oops the box. The first comes from the qlogic driver as it seems, may be wrong about this one. Are there later drivers the that available? Do extensive stressing make the box oops? The second, I suspect you need a newer kernel with some NFS fixes. Try the CVS tree or the 2.4.7 patch that is one the ftp site. The third is probably related to the resize. I suggest running repair and trying again. The fourth is probably the nfsdeamon taking a dump in the pool again. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Aug 7 16:28:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77NS2Z11864 for linux-xfs-outgoing; Tue, 7 Aug 2001 16:28:02 -0700 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 f77NRxV11837 for ; Tue, 7 Aug 2001 16:28:00 -0700 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 19:27:23 -0400 Message-ID: <23D04BDBA646D411BDDD00D0B774B53902963CAF@SA-BWMAIL1> From: "Christian, Chip" To: "Linux XFS (E-mail)" Subject: kernel nfsd crash Date: Tue, 7 Aug 2001 19:27:22 -0400 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 All, I had the following occur at a client site. This is on 2.4.3-SGI_XFS_1.0.1 #1 SMP, i686, RedHat Linux 7.1. All exported filesystems are on XFS. Kernel was compiled with compat-egcs-6.2-1.1.2.14. Any clues as to possible causes? Any more info I should collect? Thanks. -Chip Aug 6 11:15:50 nas1 kernel: invalid operand: 0000 Aug 6 11:15:50 nas1 kernel: CPU: 0 Aug 6 11:15:50 nas1 kernel: EIP: 0010:[dput+23/368] Aug 6 11:15:50 nas1 kernel: EIP: 0010:[<80145017>] Aug 6 11:15:50 nas1 kernel: EFLAGS: 00010246 Aug 6 11:15:50 nas1 kernel: eax: 00000000 ebx: 8908a8a0 ecx: 8908a920 edx: 8908a8a0 Aug 6 11:15:50 nas1 kernel: esi: 8908a8a0 edi: 8908a920 ebp: 8908a920 esp: 8e0bbebc Aug 6 11:15:50 nas1 kernel: ds: 0018 es: 0018 ss: 0018 Aug 6 11:15:50 nas1 kernel: Process nfsd (pid: 24239, stackpage=8e0bb000) Aug 6 11:15:50 nas1 kernel: Stack: 00000007 8908a920 8908a8a0 8908a920 ffffffea 8908a8a0 80177ed8 8908a8a0 Aug 6 11:15:50 nas1 kernel: 00400080 00000000 80178276 8908a920 87dcb078 ffffff8c 00000000 00400080 Aug 6 11:15:50 nas1 kernel: 00000000 8efef004 8cade800 80178633 8e3a4400 00400080 00000000 00000000 Aug 6 11:15:50 nas1 kernel: Call Trace: [nfsd_findparent+248/256] [find_fh_dentry+566/896] [fh_verify+627/1200] [nfsd3_proc_getattr+151/176] [nfsd_dispatch+193/352] Aug 6 11:15:50 nas1 kernel: Call Trace: [<80177ed8>] [<80178276>] [<80178633>][<8017e627>] [<801764a1>] Aug 6 11:15:50 nas1 kernel: [svc_process+851/1248] [nfsd+505/800] [kernel_thread+38/48] [nfsd+0/800] Aug 6 11:15:50 nas1 kernel: [<80297ff3>] [<801762b9>] [<801055a6>] [<801760c0>] Aug 6 11:15:50 nas1 kernel: Aug 6 11:15:50 nas1 kernel: Code: 0f 0b 68 d8 14 30 80 53 e8 9c 64 15 00 5e 85c0 5a 0f 84 34 From owner-linux-xfs@oss.sgi.com Tue Aug 7 16:44:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77NirH14504 for linux-xfs-outgoing; Tue, 7 Aug 2001 16:44:53 -0700 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 f77NinV14484 for ; Tue, 7 Aug 2001 16:44:49 -0700 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 f77NoEW30137 for ; Tue, 7 Aug 2001 16:50:14 -0700 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 SAA2651760; Tue, 7 Aug 2001 18:43:28 -0500 (CDT) 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 SAA39860; Tue, 7 Aug 2001 18:43:27 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id SAA16606; Tue, 7 Aug 2001 18:43:27 -0500 (CDT) Message-Id: <200108072343.SAA16606@fsgi158.americas.sgi.com> Subject: Re: corrupt inode To: yocum@fnal.gov Date: Tue, 7 Aug 2001 18:43:26 -0500 (CDT) Cc: tbd@sgi.com (Tad Dolphay), jijo@leathercollection.ph, tom.tran@3ware.com, linux-xfs@oss.sgi.com, linux@3ware.com In-Reply-To: <3B706409.FE070C20@fnal.gov> from "yocum@fnal.gov" at Aug 07, 2001 04:56:25 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 was just about to reply to my own message I see that you beat me to it. > Yep, I'm using NFS. Does this problem go away with later kernel versions? I have only seen it on 2.4.5 but I have not done very extensive testing on later kernels so I don't know if it's fixed later. > Would this problem cause the flaky inode problem Jijo and I am seeing? > Don't know if it is related or not... Tad > Thanks, > Dan > > Tad Dolphay wrote: > > > > Are you using NFS? This is a known bug when using NFS on 2.4.5. See > > http://www.cs.helsinki.fi/linux/linux-kernel/2001-21/0009.html > > for more info. > > > > Tad > > > > > > Here's the kernel dump in /var/log/messages (I think the first line says it > > > all): > > > > > > Aug 7 13:28:59 sdssdp6 kernel: kernel BUG at inode.c:486! > > > Aug 7 13:28:59 sdssdp6 kernel: invalid operand: 0000 > > > Aug 7 13:28:59 sdssdp6 kernel: CPU: 0 > > > Aug 7 13:28:59 sdssdp6 kernel: EIP: 0010:[clear_inode+51/292] > > > Aug 7 13:28:59 sdssdp6 kernel: EIP: 0010:[] > > > Aug 7 13:28:59 sdssdp6 kernel: EFLAGS: 00010292 > > > Aug 7 13:28:59 sdssdp6 kernel: eax: 0000001b ebx: c7627d80 ecx: > > > 00000002 edx: 00000002 > > > Aug 7 13:28:59 sdssdp6 kernel: esi: e0a0d440 edi: dfb2d660 ebp: > > > 00000000 esp: c884ff44 > > > Aug 7 13:28:59 sdssdp6 kernel: ds: 0018 es: 0018 ss: 0018 > > > Aug 7 13:28:59 sdssdp6 kernel: Process tcl (pid: 13828, stackpage=c884f000) > > > Aug 7 13:28:59 sdssdp6 kernel: Stack: c02a4ee0 c02a4f7f 000001e6 c7627d80 > > > c014e771 c7627d80 c085ae20 c7627d80 > > > Aug 7 13:28:59 sdssdp6 kernel: e09ffffd c7627d80 c085ae20 c014bcea > > > c085ae20 c7627d80 d6885ce0 dd89bf60 > > > Aug 7 13:28:59 sdssdp6 kernel: c0136e75 c085ae20 c884e000 bffff010 > > > 400b7873 bffff108 c085ae20 c884ffa4 > > > Aug 7 13:28:59 sdssdp6 kernel: Call Trace: [iput+349/364] [] > > > [dput+234/340] [sys_chdir+253/304] [sys_read+191/200] [system_call+51/56] > > > Aug 7 13:28:59 sdssdp6 kernel: Call Trace: [] [] > > > [] [] [] [] > > > Aug 7 13:28:59 sdssdp6 kernel: > > > Aug 7 13:28:59 sdssdp6 kernel: Code: 0f 0b 83 c4 0c 8d 74 26 00 8b 83 f4 00 > > > 00 00 a8 10 75 26 68 > > > > > > > > > Here's what I've got for hardware and software in this system: > > > > > > 2 7810 3ware cards > > > Red Hat 7.1 > > > kernel 2.4.5-SGI_XFS_1.0.1enterprise > > > > > > I've updated the XFS cmds thusly: > > > > > > acl-1.1.1-0.i386.rpm > > > acl-devel-1.1.1-0.i386.rpm > > > attr-1.1.2-0.i386.rpm > > > attr-devel-1.1.2-0.i386.rpm > > > dmapi-0.2.2-0.i386.rpm > > > dmapi-devel-0.2.2-0.i386.rpm > > > xfsprogs-1.3.3-0.i386.rpm > > > xfsprogs-devel-1.3.3-0.i386.rpm > > > > > > > > > Cheers, > > > Dan > > > > > > > > > > > > > > > -- > > > Dan Yocum > > > Sloan Digital Sky Survey, Fermilab 630.840.6509 > > > yocum@fnal.gov, http://www.sdss.org > > > SDSS. Mapping the Universe. > > > > > > > -- > Dan Yocum > Sloan Digital Sky Survey, Fermilab 630.840.6509 > yocum@fnal.gov, http://www.sdss.org > SDSS. Mapping the Universe. > From owner-linux-xfs@oss.sgi.com Tue Aug 7 17:28:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f780SiS20756 for linux-xfs-outgoing; Tue, 7 Aug 2001 17:28:44 -0700 Received: from noth.n0th.org (root@c999639-a.carneg1.pa.home.com [24.180.243.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f780SfV20725 for ; Tue, 7 Aug 2001 17:28:42 -0700 Received: from warblade (warblade.n0th.org [10.1.1.2]) by noth.n0th.org (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id UAA22275 for ; Tue, 7 Aug 2001 20:28:39 -0400 Message-Id: <200108080028.UAA22275@noth.n0th.org> X-Authentication-Warning: noth.n0th.org: Host warblade.n0th.org [10.1.1.2] claimed to be warblade MIME-Version: 1.0 From: Jim Crilly To: linux-xfs@oss.sgi.com Reply-To: Jim Crilly Subject: PATCH: ACL and EA support on Alpha X-Mailer: CSCMail v1.7.9 Date: 07 Aug 2001 20:28:33 EDT Content-Type: multipart/mixed; boundary="----------=_997230514-414-0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format... ------------=_997230514-414-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Here is a small patch to expose the syscalls for ACL/EA manipulation on Alpha, it applied to CVS from about 8PM EST with only an offset in libacl/acl.c and the file looks fine to me after the patch. If anyone has any suggestions I'll be happy to test them, I'll also look into any problems but don't get your hopes up as I'm still pretty new to this =) Thanks, Jim -- Help protect your rights on-line. Join the Electronic Frontiers Foundation today: http://www.eff.org/join ----------------------------------------------------------------------- "If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money it values more, it will lose that, too." -W. Somerset Maugham ------------=_997230514-414-0 Content-Type: application/x-unknown; name="alpha-acl.patch" Content-Disposition: inline; filename="alpha-acl.patch" Content-Transfer-Encoding: base64 ZGlmZiAtVSAyIC1yIGxpbnV4LTIuNC14ZnMtYmFzZS9jbWQvYWNsL2xpYmFj bC9hY2wuYyBsaW51eC0yLjQteGZzL2NtZC9hY2wvbGliYWNsL2FjbC5jCi0t LSBsaW51eC0yLjQteGZzLWJhc2UvY21kL2FjbC9saWJhY2wvYWNsLmMJU3Vu IEp1bCAgMSAyMjozMToxNCAyMDAxCisrKyBsaW51eC0yLjQteGZzL2NtZC9h Y2wvbGliYWNsL2FjbC5jCU1vbiBKdWwgMzAgMTk6NDE6MTggMjAwMQpAQCAt MTE1OSw0ICsxMTU5LDEyIEBACiAjICAgIGRlZmluZSBTWVNfX2FjbF9zZXQJ MTI2MgogIyAgZW5kaWYKKyNlbGlmIF9fYWxwaGFfXworIyAgZGVmaW5lIEhB VkVfQUNMX1NZU0NBTEwgMQorIyAgaWZuZGVmIFNZU19fYWNsX2dldAorIyAg ICBkZWZpbmUgU1lTX19hY2xfZ2V0CTM3OQorIyAgZW5kaWYKKyMgIGlmbmRl ZiBTWVNfX2FjbF9zZXQKKyMgICAgZGVmaW5lIFNZU19fYWNsX3NldAkzODAK KyMgIGVuZGlmCiAjZWxzZQogIyAgZGVmaW5lIEhBVkVfQUNMX1NZU0NBTEwg MApkaWZmIC1VIDIgLXIgbGludXgtMi40LXhmcy1iYXNlL2NtZC9hdHRyL2xp YmF0dHIvYXR0ci5jIGxpbnV4LTIuNC14ZnMvY21kL2F0dHIvbGliYXR0ci9h dHRyLmMKLS0tIGxpbnV4LTIuNC14ZnMtYmFzZS9jbWQvYXR0ci9saWJhdHRy L2F0dHIuYwlUaHUgQXVnICAyIDIxOjA1OjA0IDIwMDEKKysrIGxpbnV4LTIu NC14ZnMvY21kL2F0dHIvbGliYXR0ci9hdHRyLmMJTW9uIEp1bCAzMCAwMjow OTo1MyAyMDAxCkBAIC0zMDQsNCArMzA0LDkgQEAKICMgICAgZGVmaW5lIFNZ U19fYXR0cmN0bCAgICAgICAxMjYwCiAjICBlbmRpZgorI2VsaWYgX19hbHBo YV9fCisjICBkZWZpbmUgSEFWRV9BQ0xfU1lTQ0FMTCAxCisjICBpZm5kZWYg U1lTX19hdHRyY3RsCisjICAgIGRlZmluZSBTWVNfX2F0dHJjdGwJMzc4Cisj ICBlbmRpZgogI2Vsc2UKICMgIGRlZmluZSBIQVZFX0FDTF9TWVNDQUxMIDAK ZGlmZiAtVSAyIC1yIGxpbnV4LTIuNC14ZnMtYmFzZS9saW51eC9hcmNoL2Fs cGhhL2tlcm5lbC9lbnRyeS5TIGxpbnV4LTIuNC14ZnMvbGludXgvYXJjaC9h bHBoYS9rZXJuZWwvZW50cnkuUwotLS0gbGludXgtMi40LXhmcy1iYXNlL2xp bnV4L2FyY2gvYWxwaGEva2VybmVsL2VudHJ5LlMJRnJpIEp1bCAyNyAxMzoz Nzo1MyAyMDAxCisrKyBsaW51eC0yLjQteGZzL2xpbnV4L2FyY2gvYWxwaGEv a2VybmVsL2VudHJ5LlMJTW9uIEp1bCAzMCAwMjowNToxNCAyMDAxCkBAIC0x MSw1ICsxMSw1IEBACiAjZGVmaW5lIFNJR0NITEQgMjAKIAotI2RlZmluZSBO Ul9TWVNDQUxMUyAzNzgKKyNkZWZpbmUgTlJfU1lTQ0FMTFMgMzgxCiAKIC8q CkBAIC0xMTQ2LDIgKzExNDYsNSBAQAogCS5xdWFkIHN5c19wY2ljb25maWdf aW9iYXNlCiAJLnF1YWQgc3lzX2dldGRlbnRzNjQKKwkucXVhZCBzeXNfYXR0 cmN0bAorCS5xdWFkIHN5c19hY2xfZ2V0CisJLnF1YWQgc3lzX2FjbF9zZXQK ------------=_997230514-414-0-- From owner-linux-xfs@oss.sgi.com Tue Aug 7 17:58:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f780wxD25318 for linux-xfs-outgoing; Tue, 7 Aug 2001 17:58:59 -0700 Received: from netapp.USlink.net (netapp.uslink.net [199.199.168.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f780wvV25287 for ; Tue, 7 Aug 2001 17:58:57 -0700 Received: from [192.168.0.100] (usr-pequot-170.uslink.net [204.221.87.170]) by netapp.USlink.net (Switch-2.0.6/Switch-2.0.1) with ESMTP id f780wtt04452 for ; Tue, 7 Aug 2001 19:58:55 -0500 (CDT) Subject: Kernel patches From: "Charles R. Tersteeg" To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 07 Aug 2001 19:59:03 -0500 Message-Id: <997232344.4784.1.camel@moonwolf.nomewood.lan> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk would i be out of line to request patches in rpm format? for those of us who do not have the processor power to build such a large object? my 2cents, thanks in advance if this is already done, chuck From owner-linux-xfs@oss.sgi.com Tue Aug 7 18:45:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f781jqf31310 for linux-xfs-outgoing; Tue, 7 Aug 2001 18:45:52 -0700 Received: from smtp5.andrew.cmu.edu (SMTP5.ANDREW.CMU.EDU [128.2.10.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f781joV31291 for ; Tue, 7 Aug 2001 18:45:50 -0700 Received: from [192.168.1.4] (cc540135-a.abdn1.md.home.com [24.13.122.109]) (user=djm2 mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f781jlgY022307 for ; Tue, 7 Aug 2001 21:45:47 -0400 Date: Tue, 07 Aug 2001 21:45:48 -0400 From: "Daniel J. Mastrian" To: linux-xfs@oss.sgi.com Subject: Default ACL execute permission inheritance Message-ID: <788335771.997220748@[192.168.1.4]> Originator-Info: login-token=Mulberry:01iIs9b+z1qqGa+cX1zwxtzBvruJwTv7b1AGvUvgs=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/2.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've searched through the Linux-XFS mailing list archives, searched through google, and even skimmed the IEEE Posix 1003.1e draft standard, and perhaps I'm just dense, but I haven't found a sufficient answer to this question about ACLs (in general...although in this case I am using XFS on Linux) I want the user and group who owns /foo to have rw- for all files, and rwx for all directories. I want user apache to have r-- for all files, and r-x for all directories. Everyone else should have --- (although I want to leave the option open to give a specific user write access later on, for example) So say I set /foo to have this default ACL... u::rwx,g::rwx,o::---,m::rwx,u:apache:r-x Now, if I create a directory /foo/bar, bar has an access ACL and a default ACL identical to /foo's default ACL. Correct, intended behavior, yay. However, if I 'touch somefile', I get a file access ACL that is not what I expected... u::rw-,g::rwx,o::---,m::rw-,u:apache:r-x I see two things wrong with this. (1) ACL_GROUP_OBJ has rwx perms. It should not be able to execute. I believe someone else on this list mentioned that this was part of the standard, although weird. If this is intended behavior, could someone please confirm it? (2) apache has r-x perms, and should also not have the execute bit set. Shouldn't the execute bit have been dropped by intersection with the rw-rw-rw- creation permissions? I'll admit, I've never used ACLs before in Linux (or Irix), but something seems broken here. That "something" is most likely me :), but I'd feel a lot better if someone could explain either what I'm doing wrong, or why this is the way it is. Thanks so much! ======================== Dan Mastrian djm2@andrew.cmu.edu ======================== From owner-linux-xfs@oss.sgi.com Tue Aug 7 23:00:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7860VF32632 for linux-xfs-outgoing; Tue, 7 Aug 2001 23:00:31 -0700 Received: from ente.berdmann.de (frnk-d5141a9b.dsl.mediaWays.net [213.20.26.155]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7860RV32600 for ; Tue, 7 Aug 2001 23:00:28 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15UMOC-0000Mb-00; Wed, 08 Aug 2001 08:00:20 +0200 Message-ID: <3B70D574.2C0B8DFF@berdmann.de> Date: Wed, 08 Aug 2001 08:00:20 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Poul Petersen CC: "'linux-xfs@oss.sgi.com'" Subject: Re: Kernel Oops RedHat 7.1 kernel-2.4.5 xfx-1.0.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > (human oops). During bootup, the system oops'd when trying to mount the XFS > partition we had grown. That disk remains unmountable, and will oops any of > the three machines we have on the SAN when mounted (we had a backup of the > data and sufficient extra, so we just left this partition of death for > testing). The fourth oops just occurred today when I tried to xfsdump a > partition. I've included the ksymoops output for each of the oops's in > order. I've seen this behaviour, too. The solution was to make sure the kernel did not try to mount any XFS filesystem in single user mode and to xfs_repair the filesystems. -------- Original Message -------- Subject: Re: xfsdump estimates sometimes fail Date: Sun, 29 Jul 2001 14:53:45 +0200 From: "Bernhard R. Erdmann" To: "amanda-users@amanda.org" CC: jrj@cc.purdue.edu, Linux XFS Mailing List References: <200107232132.QAA03943@gandalf.cc.purdue.edu> <3B5E6D9D.53541623@berdmann.de> > > >on a particular host (Linux 2.4.6-prexy-xfs, RH 7.1 + LVM + XFS, Amanda > > >2.4.2p2) sometimes sendsize fails to estimate sizes with xfsdump. > > I recognized kernel oopses in syslog when Amanda tried to backup this > host (maxdumps=3): [...] > Ok, I'll upgrade the kernel from 2.4.6-pre5-xfs to 2.4.7-xfs before any > further investigation... Boy, that was a story... - Upgraded to Kernel 2.4.7-xfs and rebooted. - Mounting of /var failed with OOPS (sorry, no copy) - Rebooted to single user mode - "xfs_repair /dev/vg1/var" ran forever (> 30 min) with no output. Instead, each RAID array on that Compaq ML 530 containing 13 hard disks was read sequentially (that's what the LED's suggested). - xfs_repair of other XFS filesystems showed that same behaviour - no interruption possible, had to power off to reboot - Commented out the XFS filesystems in /etc/fstab avoiding them to be mounted by RedHat's init scripts even in single user mode - / was still on ext2fs - Reboot (i.e., power off) - xfs_repair for the /var filesystem produced a very ugly output (sorry, no copy) - xfs_repair of other XFS filesystems was ok - After editing /etc/fstab again I rebooted and went back to normal operation Conclusions: - Under rare circumstances it is possible to crash the kernel by trying to mount a damaged XFS filesystem with no chance to further xfs_repair with that kernel Many thanks to John R. Jackson for his help how to drive Amanda's sendsize by hand. From owner-linux-xfs@oss.sgi.com Wed Aug 8 01:33:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f788XWt23146 for linux-xfs-outgoing; Wed, 8 Aug 2001 01:33:32 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f788XUV23119 for ; Wed, 8 Aug 2001 01:33:30 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f788WSc23724; Wed, 8 Aug 2001 10:32:28 +0200 Date: Wed, 8 Aug 2001 10:32:28 +0200 From: Christoph Hellwig To: Jim Crilly Cc: Richard Henderson , linux-xfs@oss.sgi.com Subject: Re: PATCH: ACL and EA support on Alpha Message-ID: <20010808103228.A21417@caldera.de> References: <200108080028.UAA22275@noth.n0th.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108080028.UAA22275@noth.n0th.org>; from noth@noth.is.eleet.ca on Tue, Aug 07, 2001 at 08:28:33PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Aug 07, 2001 at 08:28:33PM -0400, Jim Crilly wrote: > Here is a small patch to expose the syscalls for ACL/EA manipulation on Alpha, > it applied to CVS from about 8PM EST with only an offset in libacl/acl.c and > the file looks fine to me after the patch. If anyone has any suggestions I'll > be happy to test them, I'll also look into any problems but don't get your > hopes up as I'm still pretty new to this =) Please try coordinating Alpha syscalls with Richard Henderson and the rest of the alpha crew as they are in the same numberspace as the OSF/1 ones. Christoph -- Whip me. Beat me. Make me maintain AIX. From owner-linux-xfs@oss.sgi.com Wed Aug 8 03:01:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78A1mP02391 for linux-xfs-outgoing; Wed, 8 Aug 2001 03:01:48 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78A1kV02367 for ; Wed, 8 Aug 2001 03:01:46 -0700 Received: from conetux.conet.cz (conetux.conet.cz [194.213.232.146]) 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 DAA09234 for ; Wed, 8 Aug 2001 03:01:03 -0700 (PDT) mail_from (root@conetux.conet.cz) Received: from localhost (root@localhost) by conetux.conet.cz (8.11.0/8.11.0) with ESMTP id f75N2sc22255 for ; Mon, 6 Aug 2001 01:02:54 +0200 Date: Mon, 6 Aug 2001 01:02:53 +0200 (CEST) From: root To: linux-xfs@oss.sgi.com Subject: Future of XFS? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I'd like to ask what is planned for future of XFS for Linux (except bugfixing, bugfixing and fixing bug :)) - do you expect XFS to be part of official kernel? Does SGI want to continue to support this great project? Thanks, Libor From owner-linux-xfs@oss.sgi.com Wed Aug 8 03:29:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78ATjU04887 for linux-xfs-outgoing; Wed, 8 Aug 2001 03:29:45 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78ATgV04861 for ; Wed, 8 Aug 2001 03:29:42 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0962CC08366 for ; Wed, 8 Aug 2001 18:29:37 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id AF8F8C08362 for ; Wed, 8 Aug 2001 18:29:35 +0800 (PHT) Date: Wed, 8 Aug 2001 18:29:35 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: corrupt inode In-Reply-To: <3B706409.FE070C20@fnal.gov> 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 Tue, 7 Aug 2001 at 16:56, yocum@fnal.gov wrote: > I was just about to reply to my own message I see that you beat me to > it. Yep, I'm using NFS. Does this problem go away with later kernel > versions? Would this problem cause the flaky inode problem Jijo and I > am seeing? I am also using kernel NFS, _but_ I am not using 2.4.5. I'm using 2.4.7. Hmm ... --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Wed Aug 8 04:59:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78BxvE17840 for linux-xfs-outgoing; Wed, 8 Aug 2001 04:59:57 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78BxtV17815 for ; Wed, 8 Aug 2001 04:59:55 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id NAA16176; Wed, 8 Aug 2001 13:59:46 +0200 (CEST) Message-Id: <4.3.2.7.2.20010808135738.032fc9c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Aug 2001 13:59:19 +0200 To: root From: Seth Mos Subject: Re: Future of XFS? Cc: Linux XFS Mailing List 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 01:02 6-8-2001 +0200, you wrote: >Hello, >I'd like to ask what is planned for future of XFS for Linux (except >bugfixing, bugfixing and fixing bug :)) See the todo list on the site. > - do you expect XFS to be part >of official kernel? Read the FAQ. > Does SGI want to continue to support this great project? Yes. >Thanks, >Libor Please don't mail to lists under the root acounts. My email filters don't like it. I suggest using your own account. 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 Aug 8 05:03:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78C3Or18442 for linux-xfs-outgoing; Wed, 8 Aug 2001 05:03:24 -0700 Received: from fencepost.gnu.org (we-refuse-to-spy-on-our-users@fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78C3LV18420 for ; Wed, 8 Aug 2001 05:03:22 -0700 Received: from buytenh by fencepost.gnu.org with local (Exim 3.22 #1 (Debian)) id 15US3U-0000kq-00; Wed, 08 Aug 2001 08:03:20 -0400 Date: Wed, 8 Aug 2001 08:03:20 -0400 From: Lennert Buytenhek To: linux-xfs@oss.sgi.com Cc: desmit@math.leidenuniv.nl, feleus@math.leidenuniv.nl Subject: 2.4.7-xfs kernel BUG at dcache.c:345 Message-ID: <20010808080320.A28948@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (please CC, not on the list) Hi, Looks like dentries with ->d_count != 0 are escaping to the dentry_unused list.. (no idea whether this is xfs-specific, but all filesystems on this box are xfs so this would be the first place to seek help). Am willing to try patches. cheers, Lennert --- kernel BUG at dcache.c:345! invalid operand: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010296 eax: 0000001c ebx: c5bc6bf8 ecx: 00000000 edx: ffffffff esi: c5bc6be0 edi: c3c96400 ebp: 000001c5 esp: c12dff94 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=c12df000) Stack: c02a9102 c02a91be 00000159 00000057 000000c0 00000000 0008e000 c0141801 00000638 c0129a73 00000006 000000c0 000000c0 00000000 c12de000 c02a58f1 c12de239 c0129afe 000000c0 00000000 00010f00 c1255fbc c0105000 c010566f Call Trace: [] [] [] [] [] Code: 0f 0b 83 c4 0c 8d 46 10 8b 53 f8 8b 48 04 89 4a 04 89 11 89 >>EIP; c01414d1 <===== Trace; c0141801 Trace; c0129a73 Trace; c0129afe Trace; c0105000 <_stext+0/0> Trace; c010566f From owner-linux-xfs@oss.sgi.com Wed Aug 8 06:48:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Dm3400648 for linux-xfs-outgoing; Wed, 8 Aug 2001 06:48:03 -0700 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 f78DlxV00618 for ; Wed, 8 Aug 2001 06:48:00 -0700 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 09:47:20 -0400 Message-ID: <23D04BDBA646D411BDDD00D0B774B53902963CBD@SA-BWMAIL1> From: "Christian, Chip" To: "Linux XFS (E-mail)" Subject: RE: kernel nfsd crash Date: Wed, 8 Aug 2001 09:47:19 -0400 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 Forwarding my replies to myself over on the NFS list... Sorry to keep responding to myself... The code as it is right now will do this: dput(tdentry); pdentry = ERR_PTR(-EINVAL); if (!pdentry) {} dput(tdentry); return(pdentry); Is it somehow screwing us up to call dput() twice like that? -----Original Message----- From: Christian, Chip Sent: Tuesday, August 07, 2001 22:43 To: Christian, Chip; NFS list (E-mail) Subject: RE: [NFS] kernel nfsd crash I don't get an oops, but knfsd surely does stop. It's happened to two different servers now, as well. And, by the way, this patch has already been applied 2.4.3 by RedHat: http://uwsg.iu.edu/hypermail/linux/kernel/0105.1/0135.html --- nfsfh.c 2001/05/09 00:54:56 1.1 +++ nfsfh.c 2001/05/09 00:56:01 @@ -244,6 +244,10 @@ */ pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); d_drop(tdentry); /* we never want ".." hashed */ + if (!pdentry && tdentry->d_inode == NULL) { + dput(tdentry); + pdentry = ERR_PTR(-EINVAL); + } if (!pdentry) { /* I don't want to return a ".." dentry. * I would prefer to return an unconnected "IS_ROOT" dentry, -----Original Message----- From: Christian, Chip [mailto:chip.christian@storageapps.com] Sent: Tuesday, August 07, 2001 16:04 To: NFS list (E-mail) Subject: [NFS] kernel nfsd crash All, I had the following occur at a client site. This is on 2.4.3-SGI_XFS_1.0.1 #1 SMP, i686, RedHat Linux 7.1. Any clues as to possible causes? Any more info I should collect? Thanks. -Chip Aug 6 11:15:50 nas1 kernel: invalid operand: 0000 Aug 6 11:15:50 nas1 kernel: CPU: 0 Aug 6 11:15:50 nas1 kernel: EIP: 0010:[dput+23/368] Aug 6 11:15:50 nas1 kernel: EIP: 0010:[<80145017>] Aug 6 11:15:50 nas1 kernel: EFLAGS: 00010246 Aug 6 11:15:50 nas1 kernel: eax: 00000000 ebx: 8908a8a0 ecx: 8908a920 edx: 8908a8a0 Aug 6 11:15:50 nas1 kernel: esi: 8908a8a0 edi: 8908a920 ebp: 8908a920 esp: 8e0bbebc Aug 6 11:15:50 nas1 kernel: ds: 0018 es: 0018 ss: 0018 Aug 6 11:15:50 nas1 kernel: Process nfsd (pid: 24239, stackpage=8e0bb000) Aug 6 11:15:50 nas1 kernel: Stack: 00000007 8908a920 8908a8a0 8908a920 ffffffea 8908a8a0 80177ed8 8908a8a0 Aug 6 11:15:50 nas1 kernel: 00400080 00000000 80178276 8908a920 87dcb078 ffffff8c 00000000 00400080 Aug 6 11:15:50 nas1 kernel: 00000000 8efef004 8cade800 80178633 8e3a4400 00400080 00000000 00000000 Aug 6 11:15:50 nas1 kernel: Call Trace: [nfsd_findparent+248/256] [find_fh_dentry+566/896] [fh_verify+627/1200] [nfsd3_proc_getattr+151/176] [nfsd_dispatch+193/352] Aug 6 11:15:50 nas1 kernel: Call Trace: [<80177ed8>] [<80178276>] [<80178633>][<8017e627>] [<801764a1>] Aug 6 11:15:50 nas1 kernel: [svc_process+851/1248] [nfsd+505/800] [kernel_thread+38/48] [nfsd+0/800] Aug 6 11:15:50 nas1 kernel: [<80297ff3>] [<801762b9>] [<801055a6>] [<801760c0>] Aug 6 11:15:50 nas1 kernel: Aug 6 11:15:50 nas1 kernel: Code: 0f 0b 68 d8 14 30 80 53 e8 9c 64 15 00 5e 85c0 5a 0f 84 34 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/nfs _______________________________________________ NFS maillist - NFS@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/nfs From owner-linux-xfs@oss.sgi.com Wed Aug 8 06:54:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Dsn001774 for linux-xfs-outgoing; Wed, 8 Aug 2001 06:54:49 -0700 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 f78DsmV01753 for ; Wed, 8 Aug 2001 06:54:48 -0700 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 f78DxCS13638 for ; Wed, 8 Aug 2001 06:59:12 -0700 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 GAA49005; Wed, 8 Aug 2001 06:54:11 -0700 (PDT) Message-ID: <3B7143C4.6AA81923@sgi.com> Date: Wed, 08 Aug 2001 08:51:00 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Charles R. Tersteeg" CC: linux-xfs@oss.sgi.com Subject: Re: Kernel patches References: <997232344.4784.1.camel@moonwolf.nomewood.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Charles R. Tersteeg" wrote: > > would i be out of line to request patches in rpm format? for those of us > who do not have the processor power to build such a large object? Hm, patches are source code by definition, so it really doesn't make sense to talk about "rpm format patches." We do make RPMs available for major releases (1.0, 1.0.1) but RPMs of development snapshots are not something we plan to offer. -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 Aug 8 07:17:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78EHtg05072 for linux-xfs-outgoing; Wed, 8 Aug 2001 07:17:55 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78EHrV05050 for ; Wed, 8 Aug 2001 07:17:53 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA01789 for ; Wed, 8 Aug 2001 07:17:14 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2656401; Wed, 8 Aug 2001 09:16:36 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA39854; Wed, 8 Aug 2001 09:16:36 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f78EGAi01596; Wed, 8 Aug 2001 09:16:10 -0500 Message-Id: <200108081416.f78EGAi01596@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: root cc: linux-xfs@oss.sgi.com Subject: Re: Future of XFS? In-Reply-To: Message from root of "Mon, 06 Aug 2001 01:02:53 +0200." Date: Wed, 08 Aug 2001 09:16:10 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hello, > I'd like to ask what is planned for future of XFS for Linux (except > bugfixing, bugfixing and fixing bug :)) - do you expect XFS to be part > of official kernel? Does SGI want to continue to support this great project? > > Thanks, > Libor We are mostly in bugfixing mode right now, there is some feature work in the pipeline, but other work within the company is consuming resources at the moment. We do hope to be part of the mainline kernel, we expect xfs to go into the 2.5 kernel first, then probably be backported to to the official 2.4 kernel after the core Linux developers are happy with its stability. SGI does remain committed to the project, we are just slightly over committed to other things right now ;-) Steve From owner-linux-xfs@oss.sgi.com Wed Aug 8 07:52:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Eq3x09693 for linux-xfs-outgoing; Wed, 8 Aug 2001 07:52:03 -0700 Received: from chimta02 (chimta02.algx.net [216.99.233.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78EpvV09661 for ; Wed, 8 Aug 2001 07:52:01 -0700 Received: from jtsdell (66-2-81-28.customer.algx.net [66.2.81.28]) by chimmx02.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GHR00AGF7YJWQ@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Wed, 08 Aug 2001 09:51:56 -0500 (CDT) Date: Wed, 08 Aug 2001 10:52:08 -0400 (EDT) From: John Trostel Subject: XFS / VmWare Compatibility To: XFS list Reply-to: John Trostel Message-id: Organization: Connex MIME-version: 1.0 X-Mailer: XFMail 1.5.0 on Linux Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I remember reading several posts a bit ago about people having difficulty compiling VMWare under the newer kernels now in the XFS CVS. Has anyone (re)built the VMWare modules with the latest XFS CVS trees? -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Wed Aug 8 08:25:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78FPWN14489 for linux-xfs-outgoing; Wed, 8 Aug 2001 08:25:32 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78FPUV14456 for ; Wed, 8 Aug 2001 08:25:30 -0700 Received: from gwyn.tux.org (ident-user@gwyn.tux.org [207.96.122.8]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA01166 for ; Wed, 8 Aug 2001 08:25:15 -0700 (PDT) mail_from (timball@tux.org) Received: (from timball@localhost) by gwyn.tux.org (8.9.3/8.9.1) id LAA07287 for linux-xfs@oss.sgi.com; Wed, 8 Aug 2001 11:08:33 -0400 Date: Wed, 8 Aug 2001 11:08:32 -0400 From: Timothy Ball To: XFS Mailing List Subject: Can't make current kernel Message-ID: <20010808110832.M10328@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.19i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When I do a checkout and make bzImage I get all kindsa errors... I've tried just deleting the tree and rechecking it out with no success. Here are the errors. I'm not sure what the correct way to fix this is so I post this here: --snip--snip--snip-- 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 -malign-functions=4 -c -o init/main.o init/main.c 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 -malign-functions=4 -DUTS_MACHINE='"i386"' -c -o init/version.o init/version.c make CFLAGS="-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 -malign-functions=4 " -C kernel make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/kernel' make all_targets make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/kernel' 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 -malign-functions=4 -DEXPORT_SYMTAB -c ksyms.c In file included from /usr/src/linux-2.4-xfs/linux/include/linux/modversions.h:104, from /usr/src/linux-2.4-xfs/linux/include/linux/module.h:21, from ksyms.c:14: /usr/src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:78: warning: `cpu_data' redefined /usr/src/linux-2.4-xfs/linux/include/asm/processor.h:78: warning: this is the location of the previous definition /usr/src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:82: warning: `smp_num_cpus' redefined /usr/src/linux-2.4-xfs/linux/include/linux/smp.h:80: warning: this is the location of the previous definition /usr/src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:84: warning: `cpu_online_map' redefined /usr/src/linux-2.4-xfs/linux/include/linux/smp.h:88: warning: this is the location of the previous definition /usr/src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:98: warning: `smp_call_function' redefined /usr/src/linux-2.4-xfs/linux/include/linux/smp.h:87: warning: this is the location of the previous definition In file included from /usr/src/linux-2.4-xfs/linux/include/linux/modversions.h:130, from /usr/src/linux-2.4-xfs/linux/include/linux/module.h:21, from ksyms.c:14: /usr/src/linux-2.4-xfs/linux/include/linux/modules/ksyms.ver:554: warning: `del_timer_sync' redefined /usr/src/linux-2.4-xfs/linux/include/linux/timer.h:30: warning: this is the location of the previous definition In file included from /usr/src/linux-2.4-xfs/linux/include/linux/interrupt.h:45, from ksyms.c:21: /usr/src/linux-2.4-xfs/linux/include/asm/hardirq.h:37: warning: `synchronize_irq' redefined /usr/src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:86: warning: this is the location of the previous definition In file included from ksyms.c:17: /usr/src/linux-2.4-xfs/linux/include/linux/kernel_stat.h: In function `kstat_irqs': /usr/src/linux-2.4-xfs/linux/include/linux/kernel_stat.h:48: `smp_num_cpus' undeclared (first use in this function) /usr/src/linux-2.4-xfs/linux/include/linux/kernel_stat.h:48: (Each undeclared identifier is reported only once /usr/src/linux-2.4-xfs/linux/include/linux/kernel_stat.h:48: for each function it appears in.) make[2]: *** [ksyms.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/kernel' make: *** [_dir_kernel] Error 2 --snip--snip--snip-- --timball -- GPG key available on pgpkeys.mit.edu pub 1024R/CFF85605 1999-06-10 Timothy L. Ball Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD From owner-linux-xfs@oss.sgi.com Wed Aug 8 08:44:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78FiD517664 for linux-xfs-outgoing; Wed, 8 Aug 2001 08:44:13 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78FiAV17644 for ; Wed, 8 Aug 2001 08:44:10 -0700 Received: (qmail 4825 invoked from network); 8 Aug 2001 15:44:07 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 8 Aug 2001 15:44:07 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Timothy Ball cc: XFS Mailing List Subject: Re: Can't make current kernel In-reply-to: Your message of "Wed, 08 Aug 2001 11:08:32 -0400." <20010808110832.M10328@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 01:44:06 +1000 Message-ID: <4136.997285446@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 8 Aug 2001 11:08:32 -0400, Timothy Ball wrote: >When I do a checkout and make bzImage I get all kindsa errors... I've >tried just deleting the tree and rechecking it out with no success. > >Here are the errors. I'm not sure what the correct way to fix this is so >I post this here: You have been bitten by the broken kernel Makefiles when module symbol versions are turned on. It is a generic kernel problem, not just XFS. Follow the steps in http://www.tux.org/lkml/#s8-8 From owner-linux-xfs@oss.sgi.com Wed Aug 8 09:25:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78GPVt21969 for linux-xfs-outgoing; Wed, 8 Aug 2001 09:25:31 -0700 Received: from gwyn.tux.org (ident-user@gwyn.tux.org [207.96.122.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78GPSV21947 for ; Wed, 8 Aug 2001 09:25:28 -0700 Received: (from timball@localhost) by gwyn.tux.org (8.9.3/8.9.1) id MAA12833; Wed, 8 Aug 2001 12:24:58 -0400 Date: Wed, 8 Aug 2001 12:24:58 -0400 From: Timothy Ball To: Keith Owens Cc: XFS Mailing List Subject: Re: Can't make current kernel Message-ID: <20010808122458.N10328@gwyn.tux.org> References: <20010808110832.M10328@gwyn.tux.org> <4136.997285446@ocs3.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4136.997285446@ocs3.ocs-net> User-Agent: Mutt/1.3.19i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 01:44:06AM +1000, Keith Owens wrote: > On Wed, 8 Aug 2001 11:08:32 -0400, > Timothy Ball wrote: > >When I do a checkout and make bzImage I get all kindsa errors... I've > >tried just deleting the tree and rechecking it out with no success. > > > >Here are the errors. I'm not sure what the correct way to fix this is so > >I post this here: > > You have been bitten by the broken kernel Makefiles when module symbol > versions are turned on. It is a generic kernel problem, not just XFS. > Follow the steps in http://www.tux.org/lkml/#s8-8 Woo-hoo! fixed it thanks I forgot to make mrproper. I'm less smart. --timball ps) anyone know how to burn / to a bootable cdrom? (so I can convert my / partition) -- GPG key available on pgpkeys.mit.edu pub 1024R/CFF85605 1999-06-10 Timothy L. Ball Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD From owner-linux-xfs@oss.sgi.com Wed Aug 8 09:51:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78GpOx22985 for linux-xfs-outgoing; Wed, 8 Aug 2001 09:51:24 -0700 Received: from smtpstore.strencom.net ([217.75.0.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78GpMV22964 for ; Wed, 8 Aug 2001 09:51:22 -0700 Received: from raptor.raidtec.ie (unknown [217.75.2.18]) by smtpstore.strencom.net (Postfix) with SMTP id B22F9638D6 for ; Wed, 8 Aug 2001 17:53:08 +0100 (IST) Received: from no.name.available by raptor.raidtec.ie via smtpd (for [217.75.0.68]) with SMTP; 8 Aug 2001 18:11:20 UT MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Subject: Quota - grace X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Date: Wed, 8 Aug 2001 17:51:19 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quota - grace Thread-Index: AcEgKljoEQs1RRNYTPGzZXg/GyPXWQ== From: "Juer Lee" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f78GpMV22966 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, All, Has anybody met this case? I compiled quota tools version 2.00 with XFS patch. All commands work fine except when I run "edquota -t". I got the "Segmentation fault" error. I can fix THIS 'bug' in the file quotaops.c, but it seemed that I still can not set grace on that. My question is: Does XFS support quota grace -- soft time limits ? :>>> Juer From owner-linux-xfs@oss.sgi.com Wed Aug 8 10:18:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78HI4H24198 for linux-xfs-outgoing; Wed, 8 Aug 2001 10:18:04 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78HHwV24171 for ; Wed, 8 Aug 2001 10:17:58 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.4/8.11.4) id f78HHpU00323 for linux-xfs@oss.sgi.com; Wed, 8 Aug 2001 13:17:51 -0400 Date: Wed, 8 Aug 2001 13:17:51 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: vmware + xfs Message-ID: <20010808131751.A319@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just built the patched vmmon modules w/o incident. Can't run it from here because RH's sshd doesn't want to forward X11 connections, and I'm at work. But looks good. [alane@wwweasel alane]$ uname -a Linux wwweasel.geeksrus.net 2.4.8-SGI_XFS_cvs.20010801.0_pre3 #1 Wed Aug 1 07:36:50 EDT 2001 i686 unknown -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Wed Aug 8 12:16:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78JGQu32582 for linux-xfs-outgoing; Wed, 8 Aug 2001 12:16:26 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78JGOV32551 for ; Wed, 8 Aug 2001 12:16:24 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15UYoX-0005eb-00 for linux-xfs@oss.sgi.com; Wed, 08 Aug 2001 20:16:21 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id UAA06403 for ; Wed, 8 Aug 2001 20:16:21 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f78JGLq07691 for ; Wed, 8 Aug 2001 20:16:21 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Wed, 8 Aug 2001 20:16:21 +0100 (BST) From: "P.Dixon" To: SGI XFS Dev List Subject: Re: vmware + xfs In-Reply-To: <20010808131751.A319@wwweasel.geeksrus.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've had no problem running vmware under xfs (xfs 1.0.1, 2.4.5 kernel) - though I did have to rename /usr/src/linux-2.4.5-xfs to /usr/src/linux-2.4.5-SGI_XFS_1.0.1 to get the modules to compile. Paul > Just built the patched vmmon modules w/o incident. Can't run it from here > because RH's sshd doesn't want to forward X11 connections, and I'm at work. > But looks good. > > [alane@wwweasel alane]$ uname -a > Linux wwweasel.geeksrus.net 2.4.8-SGI_XFS_cvs.20010801.0_pre3 #1 Wed Aug 1 > 07:36:50 EDT 2001 i686 unknown > > From owner-linux-xfs@oss.sgi.com Wed Aug 8 12:25:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78JPRV01320 for linux-xfs-outgoing; Wed, 8 Aug 2001 12:25:27 -0700 Received: from ente.berdmann.de (frnk-d5141a9b.dsl.mediaWays.net [213.20.26.155]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78JPPV01300 for ; Wed, 8 Aug 2001 12:25:25 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15UYxD-0004KN-00; Wed, 08 Aug 2001 21:25:19 +0200 Message-ID: <3B71921F.7B20636E@berdmann.de> Date: Wed, 08 Aug 2001 21:25:19 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Alan Eldridge CC: SGI XFS Dev List Subject: Re: vmware + xfs References: <20010808131751.A319@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Just built the patched vmmon modules w/o incident. Can't run it from here > because RH's sshd doesn't want to forward X11 connections, and I'm at work. Try: ssh -X From owner-linux-xfs@oss.sgi.com Wed Aug 8 13:09:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78K9qN06847 for linux-xfs-outgoing; Wed, 8 Aug 2001 13:09:52 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78K9nV06821 for ; Wed, 8 Aug 2001 13:09:50 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 096D31AB10 for ; Wed, 8 Aug 2001 16:09:49 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 86315838; Wed, 8 Aug 2001 16:09:48 -0400 (EDT) Date: Wed, 8 Aug 2001 16:09:48 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: non-standard errno: -990 Message-ID: <20010808160948.D21284@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm getting errors like this with a 2.4.7 XFS patched kernel: kernel: nfsd: non-standard errno: -990 This isn't something I'd worry about normally, but just a few minutes ago a programmer told me that he got a "990" error when trying to create a directory on the same XFS filesystem - and it *wasn't* over nfs. I haven't been able to find any info via google. Any ideas? Thanks. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Aug 8 13:32:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78KWjA10628 for linux-xfs-outgoing; Wed, 8 Aug 2001 13:32:45 -0700 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 f78KWhV10595 for ; Wed, 8 Aug 2001 13:32:43 -0700 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 f78Kb7S03086 for ; Wed, 8 Aug 2001 13:37:08 -0700 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 PAA2653322; Wed, 8 Aug 2001 15:31:22 -0500 (CDT) Received: from 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 PAA28564; Wed, 8 Aug 2001 15:31:21 -0500 (CDT) Message-ID: <3B71A0D0.AC790506@sgi.com> Date: Wed, 08 Aug 2001 15:28:00 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Klaassen CC: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 References: <20010808160948.D21284@dkp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Klaassen wrote: > > I'm getting errors like this with a 2.4.7 XFS patched kernel: > > kernel: nfsd: non-standard errno: -990 > > This isn't something I'd worry about normally, but just a few > minutes ago a programmer told me that he got a "990" error when > trying to create a directory on the same XFS filesystem - and it > *wasn't* over nfs. I haven't been able to find any info via > google. xfs_linux.h: /* XXX also note these need to be < 1000 and fairly unique on linux */ #define EFSCORRUPTED 990 /* Filesystem is corrupted */ #define EWRONGFS 991 /* Mount with wrong filesystem type */ This can come from about a million places in XFS... any other hints? -Eric From owner-linux-xfs@oss.sgi.com Wed Aug 8 13:37:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78KbTs11440 for linux-xfs-outgoing; Wed, 8 Aug 2001 13:37:29 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78KbSV11421 for ; Wed, 8 Aug 2001 13:37:28 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 3FD381E4FF; Wed, 8 Aug 2001 22:37:22 +0200 (MEST) Date: Wed, 8 Aug 2001 22:37:13 +0200 From: Andi Kleen To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 Message-ID: <20010808223713.A1669@gruyere.muc.suse.de> References: <20010808160948.D21284@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010808160948.D21284@dkp.com>; from ak@dkp.com on Wed, Aug 08, 2001 at 04:09:48PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 04:09:48PM -0400, Andrew Klaassen wrote: > I'm getting errors like this with a 2.4.7 XFS patched kernel: > > kernel: nfsd: non-standard errno: -990 > > This isn't something I'd worry about normally, but just a few > minutes ago a programmer told me that he got a "990" error when > trying to create a directory on the same XFS filesystem - and it > *wasn't* over nfs. I haven't been able to find any info via > google. -990 is EFSCORRUPTED which XFS generates when it sees an nasty error internally. You should probably have an error message somewhere earlier in the logs. -Andi From owner-linux-xfs@oss.sgi.com Wed Aug 8 14:00:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78L04a14977 for linux-xfs-outgoing; Wed, 8 Aug 2001 14:00:04 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78L01V14935 for ; Wed, 8 Aug 2001 14:00:01 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id BC24D1AB11 for ; Wed, 8 Aug 2001 17:00:00 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 8E10B838; Wed, 8 Aug 2001 17:00:00 -0400 (EDT) Date: Wed, 8 Aug 2001 17:00:00 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 Message-ID: <20010808170000.E21284@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010808160948.D21284@dkp.com> <20010808223713.A1669@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010808223713.A1669@gruyere.muc.suse.de> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 10:37:13PM +0200, Andi Kleen wrote: > On Wed, Aug 08, 2001 at 04:09:48PM -0400, > Andrew Klaassen wrote: > > I'm getting errors like this with a 2.4.7 XFS patched kernel: > > > > kernel: nfsd: non-standard errno: -990 > > > > This isn't something I'd worry about normally, but just a few > > minutes ago a programmer told me that he got a "990" error when > > trying to create a directory on the same XFS filesystem - and it > > *wasn't* over nfs. I haven't been able to find any info via > > google. > -990 is EFSCORRUPTED which XFS generates when it sees an nasty > error internally. You should probably have an error message > somewhere earlier in the logs. One of these, maybe? kernel: XFS: bad magic number kernel: XFS: SB validate failed They showed up just after the filesystem was mounted. I can't spot anything else that seems to be relevant. The filesystem is still up and running, BTW, and doesn't seem to be adversely affected. The error has only occured twice, both times today. It's running on top of RAID 5, if that's of interest. Any suggested course of action? This is, unfortunately, a woefully undertested production drive... Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Aug 8 14:05:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78L5tg15939 for linux-xfs-outgoing; Wed, 8 Aug 2001 14:05:55 -0700 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 f78L5rV15916 for ; Wed, 8 Aug 2001 14:05:53 -0700 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 f78LBGW06854 for ; Wed, 8 Aug 2001 14:11:16 -0700 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 QAA2660707; Wed, 8 Aug 2001 16:04:26 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA72883; Wed, 8 Aug 2001 16:04:26 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f78L3wX02935; Wed, 8 Aug 2001 16:03:58 -0500 Message-Id: <200108082103.f78L3wX02935@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 In-Reply-To: Message from Andrew Klaassen of "Wed, 08 Aug 2001 17:00:00 EDT." <20010808170000.E21284@dkp.com> Date: Wed, 08 Aug 2001 16:03:58 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Aug 08, 2001 at 10:37:13PM +0200, > Andi Kleen wrote: > > > On Wed, Aug 08, 2001 at 04:09:48PM -0400, > > Andrew Klaassen wrote: > > > > I'm getting errors like this with a 2.4.7 XFS patched kernel: > > > > > > kernel: nfsd: non-standard errno: -990 > > > > > > This isn't something I'd worry about normally, but just a few > > > minutes ago a programmer told me that he got a "990" error when > > > trying to create a directory on the same XFS filesystem - and it > > > *wasn't* over nfs. I haven't been able to find any info via > > > google. > > > -990 is EFSCORRUPTED which XFS generates when it sees an nasty > > error internally. You should probably have an error message > > somewhere earlier in the logs. > > One of these, maybe? > > kernel: XFS: bad magic number > kernel: XFS: SB validate failed Well, both of these will result in a failed mount, so this is not the same filesystem. Also, if you get the 990 error, the filesystem should no longer be accessible, so something else is going on here. Steve > > They showed up just after the filesystem was mounted. I can't > spot anything else that seems to be relevant. > > The filesystem is still up and running, BTW, and doesn't seem to > be adversely affected. The error has only occured twice, both > times today. It's running on top of RAID 5, if that's of > interest. > > Any suggested course of action? This is, unfortunately, a > woefully undertested production drive... > > Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Aug 8 14:11:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78LB2f16873 for linux-xfs-outgoing; Wed, 8 Aug 2001 14:11:02 -0700 Received: from joshua.netcurrents.com (208.184.224.2.netcurrents.com [208.184.224.2] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78LB1V16852 for ; Wed, 8 Aug 2001 14:11:01 -0700 Received: from [192.168.30.110] (c1672638-a.frmt1.sfba.home.com [24.250.132.192]) by joshua.netcurrents.com (8.11.0/8.9.1) with ESMTP id f78KxlF20786; Wed, 8 Aug 2001 13:59:51 -0700 Subject: Re: non-standard errno: -990 From: Brian A Lauer To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20010808160948.D21284@dkp.com> References: <20010808160948.D21284@dkp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 08 Aug 2001 15:16:11 -0700 Message-Id: <997308984.881.20.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I used to receive these errors all the time when working with XFS on LVM. Usually after doing an xfs grow. It went away so far after updating to kernel 2.4.7 and my xfsprogs to 1.3.1. I was on the version from the version 1.0 iso image. brian. On 08 Aug 2001 16:09:48 -0400, Andrew Klaassen wrote: > I'm getting errors like this with a 2.4.7 XFS patched kernel: > > kernel: nfsd: non-standard errno: -990 > > This isn't something I'd worry about normally, but just a few > minutes ago a programmer told me that he got a "990" error when > trying to create a directory on the same XFS filesystem - and it > *wasn't* over nfs. I haven't been able to find any info via > google. > > Any ideas? > > Thanks. > > Andrew Klaassen > > From owner-linux-xfs@oss.sgi.com Wed Aug 8 14:29:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78LTnW19525 for linux-xfs-outgoing; Wed, 8 Aug 2001 14:29:49 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78LTjV19499 for ; Wed, 8 Aug 2001 14:29:45 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 2AC421AB11 for ; Wed, 8 Aug 2001 17:29:45 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id DD7D6838; Wed, 8 Aug 2001 17:29:44 -0400 (EDT) Date: Wed, 8 Aug 2001 17:29:44 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 Message-ID: <20010808172944.F21284@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200108082103.f78L3wX02935@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200108082103.f78L3wX02935@jen.americas.sgi.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 04:03:58PM -0500, Steve Lord wrote: > > On Wed, Aug 08, 2001 at 10:37:13PM +0200, > > Andi Kleen wrote: > > > On Wed, Aug 08, 2001 at 04:09:48PM -0400, > > > Andrew Klaassen wrote: > > > > I'm getting errors like this with a 2.4.7 XFS patched kernel: > > > > > > > > kernel: nfsd: non-standard errno: -990 > > > > > > > > This isn't something I'd worry about normally, but just > > > > a few minutes ago a programmer told me that he got a > > > > "990" error when trying to create a directory on the > > > > same XFS filesystem - and it *wasn't* over nfs. I > > > > haven't been able to find any info via google. > > > -990 is EFSCORRUPTED which XFS generates when it sees an > > > nasty error internally. You should probably have an error > > > message somewhere earlier in the logs. > > One of these, maybe? > > > > kernel: XFS: bad magic number > > kernel: XFS: SB validate failed > Well, both of these will result in a failed mount, so this is > not the same filesystem. Also, if you get the 990 error, the > filesystem should no longer be accessible, so something else > is going on here. Hmm. The filesystem affected seems to be mounted. The "bad magic number" and "SB validate failed" may be from a scratch filesystem which is still in /etc/fstab but doesn't exist on disk; the "-990" error, though, definitely seems to be associated with a mounted filesystem... kernel: Start mounting filesystem: md(9,0) kernel: Ending clean XFS mount for filesystem: md(9,0) kernel: Start mounting filesystem: md(9,2) kernel: Ending clean XFS mount for filesystem: md(9,2) kernel: XFS: bad magic number kernel: XFS: SB validate failed kernel: spurious 8259A interrupt: IRQ15. kernel: PCI: Found IRQ 5 for device 00:09.0 kernel: PCI: Sharing IRQ 5 with 00:04.2 kernel: eth1: Intel(R) PRO/100+ PCI Adapter kernel: Mem:0xe3000000 IRQ:5 Speed:100 Mbps Dx:Full kernel: Hardware receive checksums disabled kernel: ucode was not loaded kernel: XFS: bad magic number kernel: XFS: SB validate failed xinetd: xinetd startup succeeded Then, later: sshd(pam_unix)[22260]: session opened for user XXXX by (uid=0) kernel: nfsd: non-standard errno: -990 rpc.mountd: authenticated mount request from XXX.XXX.XXX.XXX:788 for /n/bubba1 (/n/bubba1) kernel: svc: unknown version (3) And, from the programmer: os.mkdir(d, 0775) OSError: [Errno 990] Unknown error 990: '/n/bubba1/Projects/20_Million/COMP/scenes/hol183_8/film' /n/bubba1, the filesystem in question, is mounted: # df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/md1 4196096 2488644 1707452 60% / /dev/md0 131648 17836 113812 14% /boot /dev/md2 825749760 281092956 544656804 35% /n/bubba1 Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Aug 8 14:32:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78LWGH19910 for linux-xfs-outgoing; Wed, 8 Aug 2001 14:32:16 -0700 Received: from chimta01.algx.net (chimta01.algx.net [216.99.233.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78LWAV19878 for ; Wed, 8 Aug 2001 14:32:15 -0700 Received: from jtsdell (66-2-81-28.customer.algx.net [66.2.81.28]) by chimmx01.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GHR00LDUKJU3C@chimmx01.algx.net> for linux-xfs@oss.sgi.com; Wed, 08 Aug 2001 14:23:55 -0500 (CDT) Date: Wed, 08 Aug 2001 15:24:03 -0400 (EDT) From: John Trostel Subject: Re: vmware + xfs In-reply-to: To: "P.Dixon" Cc: SGI XFS Dev List Reply-to: John Trostel Message-id: Organization: Connex MIME-version: 1.0 X-Mailer: XFMail 1.5.0 on Linux Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The patched (with vmmon-for-2.4.7-only.tar.gz) version of VMWare is working fine here now with the latest 2.4.8pre4 XFS-ilated kernel! On 08-Aug-2001 P.Dixon wrote: > Hi, > > I've had no problem running vmware under xfs (xfs 1.0.1, 2.4.5 kernel) - > though I did have to rename /usr/src/linux-2.4.5-xfs to > /usr/src/linux-2.4.5-SGI_XFS_1.0.1 to get the modules to compile. > > Paul > >> Just built the patched vmmon modules w/o incident. Can't run it from here >> because RH's sshd doesn't want to forward X11 connections, and I'm at work. >> But looks good. >> >> [alane@wwweasel alane]$ uname -a >> Linux wwweasel.geeksrus.net 2.4.8-SGI_XFS_cvs.20010801.0_pre3 #1 Wed Aug 1 >> 07:36:50 EDT 2001 i686 unknown >> >> -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Wed Aug 8 14:46:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Lk3b21765 for linux-xfs-outgoing; Wed, 8 Aug 2001 14:46:03 -0700 Received: from twain.franken.de (mail@dsl-213-023-054-230.arcor-ip.net [213.23.54.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78Lk1V21742 for ; Wed, 8 Aug 2001 14:46:01 -0700 Received: from smoki by twain.franken.de with local (Exim 3.22 #1 (Debian)) id 15Ub87-0000fb-00 for ; Wed, 08 Aug 2001 23:44:43 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Christian Mueller Subject: XFS for Linux/390 Date: Wed, 8 Aug 2001 23:44:43 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01080823432102.01286@twain> Content-Transfer-Encoding: 8bit To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, have someone in this list experiance in running the xfs on Linux on s/390. I've Patched a 2.4.5 Kernel, with the patches from IBM and XFS. The Kernel and the modules was compiled fine. If i format a dasd-Device with xfs it seems to work, but if i mount the file-system, the kernel dies and i have "IPL" the system :( I've read somewhere in the archives of this list, that xfs could only run with LVM on s390, is this right? If i understand it right, it didn't work, becouse the xfs uses 512 block's for some reasons to save and the dasd can handle this right, becouse my blocking for DASD is bigger (4096). My Questions: Is there a development to solve this bug. What had to solve DASD or XFS? Or have i missunderstood something? Is there somewhere documentation for XFS on Linux/390? Thank you, for u help Christian Mueller From owner-linux-xfs@oss.sgi.com Wed Aug 8 15:14:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78ME3S25795 for linux-xfs-outgoing; Wed, 8 Aug 2001 15:14:03 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78ME1V25775 for ; Wed, 8 Aug 2001 15:14:01 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA26305; Thu, 9 Aug 2001 00:13:58 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA28086; Thu, 9 Aug 2001 00:13:58 +0200 (CEST) Date: Thu, 9 Aug 2001 00:13:58 +0200 (CEST) From: Seth Mos To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 In-Reply-To: <20010808160948.D21284@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 Wed, 8 Aug 2001, Andrew Klaassen wrote: > I'm getting errors like this with a 2.4.7 XFS patched kernel: > > kernel: nfsd: non-standard errno: -990 > > This isn't something I'd worry about normally, but just a few > minutes ago a programmer told me that he got a "990" error when > trying to create a directory on the same XFS filesystem - and it > *wasn't* over nfs. I haven't been able to find any info via > google. Explanation in the FAQ. Basically this means a very probable corruption. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Aug 8 15:19:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78MJhj26756 for linux-xfs-outgoing; Wed, 8 Aug 2001 15:19:43 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78MJcV26722 for ; Wed, 8 Aug 2001 15:19:38 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAB04133 for ; Wed, 8 Aug 2001 15:18:51 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2662025 for ; Wed, 8 Aug 2001 17:18:22 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA53811 for ; Wed, 8 Aug 2001 17:18:22 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f78MHr003130; Wed, 8 Aug 2001 17:17:53 -0500 Message-Id: <200108082217.f78MHr003130@jen.americas.sgi.com> Date: Wed, 8 Aug 2001 17:17:53 -0500 Subject: TAKE - merge up to 2.4.8-pre6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Here is the latest small change from Linus, I will now disappear back into my hole..... My recent low profile is because I am neck deep in a bunch of other stuff right now. Date: Wed Aug 8 15:15:12 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100416a linux/drivers/scsi/pcmcia/nsp_message.c - 1.1 linux/Documentation/sound/btaudio - 1.1 linux/drivers/media/radio/radio-gemtek-pci.c - 1.1 linux/drivers/media/video/msp3400.h - 1.1 linux/drivers/s390/block/dasd_3370_erp.h - 1.1 linux/drivers/s390/block/dasd_int.h - 1.1 linux/drivers/s390/block/dasd_9336_erp.h - 1.1 linux/scripts/Menuconfig - 1.12 linux/net/sched/sch_cbq.c - 1.10 linux/net/sched/cls_u32.c - 1.5 linux/net/sched/cls_route.c - 1.4 linux/net/packet/af_packet.c - 1.24 linux/net/netsyms.c - 1.35 linux/net/ipv6/addrconf.c - 1.18 linux/net/ipv4/ip_output.c - 1.23 linux/net/ipv4/icmp.c - 1.19 linux/net/ipv4/af_inet.c - 1.27 linux/net/core/skbuff.c - 1.21 linux/net/core/rtnetlink.c - 1.8 linux/mm/vmscan.c - 1.66 linux/lib/vsprintf.c - 1.11 linux/include/net/addrconf.h - 1.8 linux/include/linux/serial.h - 1.13 linux/include/linux/netdevice.h - 1.26 linux/include/linux/fs.h - 1.105 linux/include/linux/blkdev.h - 1.35 linux/include/asm-sparc64/mmu_context.h - 1.9 linux/include/asm-sparc/pgtable.h - 1.18 linux/include/asm-i386/serial.h - 1.4 linux/fs/read_write.c - 1.14 linux/fs/buffer.c - 1.75 linux/drivers/scsi/sd.c - 1.38 linux/drivers/scsi/qlogicfc.c - 1.18 linux/drivers/scsi/atp870u.c - 1.15 linux/drivers/scsi/aha152x.c - 1.21 linux/drivers/pci/quirks.c - 1.22 linux/drivers/net/sunhme.h - 1.10 linux/drivers/net/ne2.c - 1.14 linux/drivers/net/hamradio/scc.c - 1.19 linux/drivers/char/sysrq.c - 1.14 linux/drivers/char/serial.c - 1.44 linux/drivers/char/riscom8.c - 1.11 linux/drivers/char/nvram.c - 1.14 linux/drivers/block/floppy.c - 1.24 linux/arch/sparc64/mm/init.c - 1.26 linux/arch/sparc64/mm/extable.c - 1.3 linux/arch/sparc64/kernel/smp.c - 1.24 linux/arch/sparc64/kernel/ioctl32.c - 1.37 linux/arch/sparc64/defconfig - 1.42 linux/arch/sparc/mm/extable.c - 1.3 linux/arch/sparc/kernel/ebus.c - 1.10 linux/arch/i386/boot/setup.S - 1.21 linux/arch/i386/boot/Makefile - 1.10 linux/Makefile - 1.110 linux/MAINTAINERS - 1.66 linux/Documentation/video4linux/bttv/README - 1.13 linux/Documentation/pci.txt - 1.14 linux/drivers/net/arlan.c - 1.18 linux/fs/partitions/check.c - 1.27 linux/net/atm/common.c - 1.12 linux/drivers/block/DAC960.h - 1.8 linux/drivers/block/DAC960.c - 1.30 linux/drivers/net/pcmcia/3c589_cs.c - 1.17 linux/drivers/net/tokenring/ibmtr.c - 1.16 linux/include/linux/pci_ids.h - 1.40 linux/drivers/net/pcmcia/3c574_cs.c - 1.15 linux/mm/highmem.c - 1.22 linux/drivers/net/sk98lin/skge.c - 1.14 linux/Documentation/video4linux/bttv/Sound-FAQ - 1.6 linux/Documentation/video4linux/bttv/CARDLIST - 1.10 linux/Documentation/video4linux/bttv/Insmod-options - 1.9 linux/drivers/usb/usbkbd.c - 1.16 linux/drivers/ieee1394/ieee1394_core.h - 1.6 linux/drivers/ieee1394/ieee1394_core.c - 1.11 linux/arch/i386/kernel/mpparse.c - 1.10 linux/drivers/char/mxser.c - 1.9 linux/drivers/net/tulip/tulip_core.c - 1.25 linux/drivers/ide/sis5513.c - 1.10 linux/net/ipv4/netfilter/ip_nat_proto_tcp.c - 1.2 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.9 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.7 linux/include/linux/ibmtr.h - 1.4 linux/fs/partitions/ibm.c - 1.5 linux/include/asm-s390/cache.h - 1.3 linux/drivers/s390/block/dasd_eckd.c - 1.5 linux/drivers/s390/block/dasd.c - 1.8 linux/drivers/s390/Config.in - 1.7 linux/drivers/s390/block/Makefile - 1.4 linux/net/ipv6/netfilter/ip6_tables.c - 1.6 linux/net/ipv6/netfilter/Makefile - 1.6 linux/drivers/char/drm/agpsupport.c - 1.5 linux/drivers/char/sbc60xxwdt.c - 1.7 linux/drivers/net/tun.c - 1.8 linux/net/ipv4/tcp_minisocks.c - 1.5 linux/drivers/media/video/tuner.h - 1.4 linux/drivers/media/video/tuner.c - 1.5 linux/drivers/media/video/tda7432.c - 1.5 linux/drivers/media/video/msp3400.c - 1.6 linux/drivers/media/video/bttv.h - 1.8 linux/drivers/media/video/bttv-driver.c - 1.11 linux/drivers/media/video/bttv-cards.c - 1.7 linux/drivers/media/video/bt848.h - 1.2 linux/drivers/media/radio/Makefile - 1.7 linux/drivers/media/radio/Config.in - 1.6 linux/drivers/scsi/cpqfc.Readme - 1.2 linux/drivers/scsi/cpqfcTS.h - 1.2 linux/drivers/scsi/cpqfcTScontrol.c - 1.4 linux/drivers/scsi/cpqfcTSinit.c - 1.8 linux/drivers/scsi/cpqfcTSstructs.h - 1.2 linux/drivers/scsi/cpqfcTSworker.c - 1.4 linux/drivers/media/video/tvaudio.c - 1.5 linux/drivers/media/video/bttvp.h - 1.4 linux/mm/shmem.c - 1.9 linux/include/asm-s390/dasd.h - 1.4 linux/include/asm-s390x/dasd.h - 1.5 linux/include/asm-s390x/cache.h - 1.3 linux/drivers/s390/block/dasd_fba.h - 1.2 linux/drivers/s390/block/dasd_fba.c - 1.4 linux/drivers/s390/block/dasd_eckd.h - 1.3 linux/drivers/s390/block/dasd_diag.h - 1.2 linux/drivers/s390/block/dasd_diag.c - 1.4 linux/drivers/s390/block/dasd_9343_erp.c - 1.2 linux/drivers/s390/block/dasd_9336_erp.c - 1.2 linux/drivers/s390/block/dasd_3990_erp.h - 1.3 linux/drivers/s390/block/dasd_3990_erp.c - 1.3 linux/drivers/s390/block/dasd_3370_erp.c - 1.2 linux/drivers/net/pci-skeleton.c - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx.c - 1.3 linux/drivers/net/sungem.c - 1.4 linux/drivers/s390/block/dasd_9343_erp.h - 1.2 linux/include/asm-s390/vtoc.h - 1.2 linux/include/asm-s390x/vtoc.h - 1.2 linux/drivers/net/irda/irda-usb.c - 1.2 linux/drivers/media/video/bt856.c - 1.2 linux/drivers/media/video/bt819.c - 1.2 linux/drivers/media/video/adv7175.c - 1.2 linux/drivers/net/irda/ali-ircc.c - 1.2 linux/drivers/net/sk98lin/skproc.c - 1.4 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.3 linux/drivers/scsi/pcmcia/nsp_cs.h - 1.3 linux/drivers/scsi/pcmcia/nsp_debug.c - 1.3 linux/drivers/scsi/pcmcia/nsp_io.h - 1.3 linux/drivers/video/aty/atyfb_base.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Aug 8 15:23:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78MN9627386 for linux-xfs-outgoing; Wed, 8 Aug 2001 15:23:09 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78MN6V27360 for ; Wed, 8 Aug 2001 15:23:06 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA27550; Thu, 9 Aug 2001 00:23:05 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA28751; Thu, 9 Aug 2001 00:23:05 +0200 (CEST) Date: Thu, 9 Aug 2001 00:23:05 +0200 (CEST) From: Seth Mos To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 In-Reply-To: <20010808172944.F21284@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 Wed, 8 Aug 2001, Andrew Klaassen wrote: > On Wed, Aug 08, 2001 at 04:03:58PM -0500, > Hmm. > > The filesystem affected seems to be mounted. What compiler did you use? Some people had some weird issues with the redhat compiler differing from machine to machine. > The "bad magic number" and "SB validate failed" may be from a > scratch filesystem which is still in /etc/fstab but doesn't > exist on disk; the "-990" error, though, definitely seems to be > associated with a mounted filesystem... It must be to generate one :-) > kernel: Start mounting filesystem: md(9,0) > kernel: Ending clean XFS mount for filesystem: md(9,0) > kernel: Start mounting filesystem: md(9,2) > kernel: Ending clean XFS mount for filesystem: md(9,2) > kernel: XFS: bad magic number > kernel: XFS: SB validate failed > kernel: spurious 8259A interrupt: IRQ15. What is the parallel port doing on the second IDE controller IRQ? > kernel: PCI: Found IRQ 5 for device 00:09.0 > kernel: PCI: Sharing IRQ 5 with 00:04.2 > > kernel: eth1: Intel(R) PRO/100+ PCI Adapter > kernel: Mem:0xe3000000 IRQ:5 Speed:100 Mbps Dx:Full > kernel: Hardware receive checksums disabled cat /proc/devices interrupts or ioports can help too. > kernel: ucode was not loaded > kernel: XFS: bad magic number > kernel: XFS: SB validate failed > xinetd: xinetd startup succeeded > > > Then, later: > > > sshd(pam_unix)[22260]: session opened for user XXXX by (uid=0) > kernel: nfsd: non-standard errno: -990 > rpc.mountd: authenticated mount request from XXX.XXX.XXX.XXX:788 for /n/bubba1 (/n/bubba1) > kernel: svc: unknown version (3) > Harmless, otherwise compile the kernel with version 3 nfs support. > And, from the programmer: > > os.mkdir(d, 0775) OSError: [Errno 990] > Unknown error 990: '/n/bubba1/Projects/20_Million/COMP/scenes/hol183_8/film' > > /n/bubba1, the filesystem in question, is mounted: You will have errors on this fs that will need repairing. Let's see if we can find some further clues. Do you see more messages with 990 in it in /var/log/messages? > # df -k > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/md1 4196096 2488644 1707452 60% / > /dev/md0 131648 17836 113812 14% /boot > /dev/md2 825749760 281092956 544656804 35% /n/bubba1 > > Andrew Klaassen Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Aug 8 15:28:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78MSDt28229 for linux-xfs-outgoing; Wed, 8 Aug 2001 15:28:13 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78MSBV28204 for ; Wed, 8 Aug 2001 15:28:11 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA27934; Thu, 9 Aug 2001 00:28:10 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA29056; Thu, 9 Aug 2001 00:28:10 +0200 (CEST) Date: Thu, 9 Aug 2001 00:28:10 +0200 (CEST) From: Seth Mos To: Christian Mueller cc: linux-xfs@oss.sgi.com Subject: Re: XFS for Linux/390 In-Reply-To: <01080823432102.01286@twain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 8 Aug 2001, Christian Mueller wrote: > Hi there, > > have someone in this list experiance in running the xfs on Linux on s/390. > I've Patched a 2.4.5 Kernel, with the patches from IBM and XFS. The Kernel > and the modules was compiled fine. I have heard that someone was working on something. > If i format a dasd-Device with xfs it seems to work, but if i mount the > file-system, the kernel dies and i have "IPL" the system :( I am not familiar with the term. > I've read somewhere in the archives of this list, that xfs could only run > with LVM on s390, is this right? Not sure. > If i understand it right, it didn't work, becouse the xfs uses 512 block's > for some reasons to save and the dasd can handle this right, becouse my > blocking for DASD is bigger (4096). XFS needs the pagesize to be equal to the blocksize. Something was seriuously in the way on S/390 but I can not remember what. > My Questions: Is there a development to solve this bug. What had to solve > DASD or XFS? Or have i missunderstood something? Is there somewhere > documentation for XFS on Linux/390? Both need some work and information links are in the FAQ. > Thank you, for u help > > Christian Mueller Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Aug 8 15:40:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78MeSW30073 for linux-xfs-outgoing; Wed, 8 Aug 2001 15:40:28 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78MeQV30038 for ; Wed, 8 Aug 2001 15:40:26 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09657 for ; Wed, 8 Aug 2001 15:38:21 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2663067; Wed, 8 Aug 2001 17:38:54 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA54620; Wed, 8 Aug 2001 17:38:49 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f78McJ103186; Wed, 8 Aug 2001 17:38:19 -0500 Message-Id: <200108082238.f78McJ103186@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Christian Mueller cc: linux-xfs@oss.sgi.com Subject: Re: XFS for Linux/390 In-Reply-To: Message from Christian Mueller of "Wed, 08 Aug 2001 23:44:43 +0200." <01080823432102.01286@twain> Date: Wed, 08 Aug 2001 17:38:19 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi there, > > have someone in this list experiance in running the xfs on Linux on s/390. > I've Patched a 2.4.5 Kernel, with the patches from IBM and XFS. The Kernel > and the modules was compiled fine. > > If i format a dasd-Device with xfs it seems to work, but if i mount the > file-system, the kernel dies and i have "IPL" the system :( > > I've read somewhere in the archives of this list, that xfs could only run > with LVM on s390, is this right? > > If i understand it right, it didn't work, becouse the xfs uses 512 block's > for some reasons to save and the dasd can handle this right, becouse my > blocking for DASD is bigger (4096). Yes, there are metadata structures in xfs which are 512 bytes long and which need to be individually read and written. There is a theoretical case where we must write one of them out to disk, but must not write another of them. This really ties xfs to devices with a 512 byte addressability. > > My Questions: Is there a development to solve this bug. What had to solve > DASD or XFS? Or have i missunderstood something? Is there somewhere > documentation for XFS on Linux/390? There is really nothing on going, there was an internal SGI project once to make xfs independent of the device blocksize, on a device which was not 512 byte addressable, the metadata would be made bigger. The code for this project (which was shelved) does still exist, but is against an old version of XFS running on Irix. Reviving this code would be one approach, another would be an atomic read/modify/write type of thing within the disk driver. Steve > > Thank you, for u help > > Christian Mueller From owner-linux-xfs@oss.sgi.com Wed Aug 8 16:11:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78NBIx02007 for linux-xfs-outgoing; Wed, 8 Aug 2001 16:11:18 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78NBGV01988 for ; Wed, 8 Aug 2001 16:11:16 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA03216 for ; Wed, 8 Aug 2001 16:10:57 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA34054 for ; Wed, 8 Aug 2001 16:16:00 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 1ED7E15A59C for ; Wed, 8 Aug 2001 16:09:55 -0700 (PDT) Subject: Re: corrupt inode From: Florin Andrei To: Linux XFS Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 08 Aug 2001 16:09:55 -0700 Message-Id: <997312195.20199.34.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 06 Aug 2001 14:50:50 +0800, Federico Sevilla III wrote: > > And the list goes on and on and on with Maildir entries and some MSIE > cache stuff. Thank God this is not our Samba data repository. Mail is > critical but I can live with losses. On a server that's not very loaded, i think it's ok to run "sync" every now and then, if the data is extremely important. Run it every minute from cron, or at the end of every script that's doing funny things with your data. But if your server has a lot of disk I/O, then "sync" is not a good idea. -- Florin Andrei From owner-linux-xfs@oss.sgi.com Wed Aug 8 16:18:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78NI8203117 for linux-xfs-outgoing; Wed, 8 Aug 2001 16:18:08 -0700 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 f78NI6V03088 for ; Wed, 8 Aug 2001 16:18:06 -0700 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 f78NMUS11191 for ; Wed, 8 Aug 2001 16:22:30 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA15762; Thu, 9 Aug 2001 09:16:40 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA45841; Thu, 9 Aug 2001 09:16:39 +1000 (EST) Date: Thu, 9 Aug 2001 09:16:39 +1000 From: Nathan Scott To: Juer Lee Cc: linux-xfs@oss.sgi.com Subject: Re: Quota - grace Message-ID: <20010809091639.A287093@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Juer.Lee@raidtec.ie on Wed, Aug 08, 2001 at 05:51:19PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Aug 08, 2001 at 05:51:19PM +0100, Juer Lee wrote: > ... > I compiled quota tools version 2.00 with XFS patch. All commands work Which patch was that? > fine except when I run "edquota -t". I got the "Segmentation fault" > error. I can fix THIS 'bug' in the file quotaops.c, but it seemed that I > still can not set grace on that. There was never any support for XFS in the 2.00 series of quota tools - try the 3.01 code from: http://sourceforge.net/projects/linuxquota/ > My question is: Does XFS support quota grace -- soft time limits ? > Yes - read cmd/xfsprogs/doc/README.quota for more details. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 8 16:51:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Npm508078 for linux-xfs-outgoing; Wed, 8 Aug 2001 16:51:48 -0700 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 f78NpkV08059 for ; Wed, 8 Aug 2001 16:51:46 -0700 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 f78NvDW14037 for ; Wed, 8 Aug 2001 16:57:13 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA15932; Thu, 9 Aug 2001 09:50:23 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA76241; Thu, 9 Aug 2001 09:50:22 +1000 (AEST) Date: Thu, 9 Aug 2001 09:50:21 +1000 From: Nathan Scott To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 Message-ID: <20010809095021.A260586@wobbly.melbourne.sgi.com> References: <20010808160948.D21284@dkp.com> <20010808223713.A1669@gruyere.muc.suse.de> <20010808170000.E21284@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010808170000.E21284@dkp.com>; from ak@dkp.com on Wed, Aug 08, 2001 at 05:00:00PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 05:00:00PM -0400, Andrew Klaassen wrote: > On Wed, Aug 08, 2001 at 10:37:13PM +0200, > Andi Kleen wrote: > > > On Wed, Aug 08, 2001 at 04:09:48PM -0400, > > Andrew Klaassen wrote: > > > > I'm getting errors like this with a 2.4.7 XFS patched kernel: > > > > > > kernel: nfsd: non-standard errno: -990 > > > > > > This isn't something I'd worry about normally, but just a few > > > minutes ago a programmer told me that he got a "990" error when > > > trying to create a directory on the same XFS filesystem - and it > > > *wasn't* over nfs. I haven't been able to find any info via > > > google. > > > -990 is EFSCORRUPTED which XFS generates when it sees an nasty > > error internally. You should probably have an error message > > somewhere earlier in the logs. > > ... > > Any suggested course of action? This is, unfortunately, a > woefully undertested production drive... > Only other suggestion would be to unmount and see what kind of corruption xfs_repair picks up. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 8 17:03:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7903xI09931 for linux-xfs-outgoing; Wed, 8 Aug 2001 17:03:59 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7903uV09902 for ; Wed, 8 Aug 2001 17:03:56 -0700 Received: (qmail 8326 invoked from network); 9 Aug 2001 00:03:51 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 9 Aug 2001 00:03:50 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Timothy Ball cc: XFS Mailing List Subject: Re: Can't make current kernel In-reply-to: Your message of "Wed, 08 Aug 2001 12:24:58 -0400." <20010808122458.N10328@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 10:03:48 +1000 Message-ID: <6737.997315428@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 8 Aug 2001 12:24:58 -0400, Timothy Ball wrote: >ps) anyone know how to burn / to a bootable cdrom? (so I can convert my >/ partition) http://open-projects.linuxcare.com/BBC/other_BBCs.epl From owner-linux-xfs@oss.sgi.com Wed Aug 8 17:24:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f790OA112309 for linux-xfs-outgoing; Wed, 8 Aug 2001 17:24:10 -0700 Received: from galactica.it (mail1.galactica.it [212.41.208.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f790O8V12289 for ; Wed, 8 Aug 2001 17:24:08 -0700 Received: from mat.home.xs ([62.122.97.13]) by galactica.it with Microsoft SMTPSVC(5.5.1877.537.53); Thu, 9 Aug 2001 02:26:15 +0200 Received: by mat.home.xs (Postfix, from userid 1000) id 8BD3010008A; Thu, 9 Aug 2001 02:25:50 +0200 (CEST) Date: Thu, 9 Aug 2001 02:25:50 +0200 From: `matte To: linux-xfs@oss.sgi.com Subject: How to make ext3+xfs kernel? Message-ID: <20010809022550.A13288@home.xs> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i X-Operating-System: Debian GNU/Linux 2.4.7-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I'm a little newbie ;-) I'was trying to patch a 2.4.7 kernel with ext3 and xfs patches, but there are some errors. I can patch with ext3 only and all is done, so with xfs only, but no ext3+xfs. I'm here to ask how I have to patch to obtain a correct kernel. Thanks ;-) Bye ps: sorry for my English :\ From owner-linux-xfs@oss.sgi.com Wed Aug 8 18:02:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7912oA16548 for linux-xfs-outgoing; Wed, 8 Aug 2001 18:02:50 -0700 Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7912lV16520 for ; Wed, 8 Aug 2001 18:02:47 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.9.3/8.9.3) id DAA12977 for linux-xfs@oss.sgi.com; Thu, 9 Aug 2001 03:02:50 +0200 Date: Thu, 9 Aug 2001 03:02:49 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: linux-xfs@oss.sgi.com Subject: xfsprogs support for > 1TB devices. Message-ID: <20010809030249.C9580@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Can you please apply the following patch to xfsprogs, if you have not alreaddy fixed it: --- xfsprogs-1.3.1/libxfs/init.c.orig Wed Aug 8 17:42:56 2001 +++ xfsprogs-1.3.1/libxfs/init.c Wed Aug 8 17:43:14 2001 @@ -132,7 +132,7 @@ { int fd; int error; - long size; + unsigned long size; struct stat64 st; /* Test to see if we are dealing with a regular file rather than * a or maybe make it a unsigned long long right away.. Could you also indicate if there are likely to be any other problems, or if 1-2 TB filesystems (and above 2tb?) should work with xfs? -- Ragnar Kjorstad Big Storage From owner-linux-xfs@oss.sgi.com Wed Aug 8 18:43:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f791hHe21392 for linux-xfs-outgoing; Wed, 8 Aug 2001 18:43:17 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f791hEV21373 for ; Wed, 8 Aug 2001 18:43:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA09689 for ; Wed, 8 Aug 2001 18:42:23 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16616; Thu, 9 Aug 2001 11:41:57 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA87276; Thu, 9 Aug 2001 11:41:56 +1000 (AEST) Date: Thu, 9 Aug 2001 11:41:56 +1000 From: Nathan Scott To: Ragnar Kj?rstad Cc: linux-xfs@oss.sgi.com Subject: Re: xfsprogs support for > 1TB devices. Message-ID: <20010809114155.C260586@wobbly.melbourne.sgi.com> References: <20010809030249.C9580@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010809030249.C9580@vestdata.no>; from xfs@ragnark.vestdata.no on Thu, Aug 09, 2001 at 03:02:49AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 09, 2001 at 03:02:49AM +0200, Ragnar Kj?rstad wrote: > Hi > > Can you please apply the following patch to xfsprogs, if you have not > alreaddy fixed it: > Yes, someone else has already sent that patch so its in the CVS tree now - thanks anyway though. > > or maybe make it a unsigned long long right away.. > There doesn't seem to be any point in doing that since the ioctl returns an unsigned long (or have I missed something?). I think your "unsigned long long" suggestion would cause an xfsprogs bug on some 32bit platforms, no? > Could you also indicate if there are likely to be any other problems, or > if 1-2 TB filesystems (and above 2tb?) should work with xfs? I don't have access to a big enough Linux system to try it I'm afraid, but the IRIX/XFS code is obviously 64 bit clean, so we had a good starting point for Linux/XFS - the sorts of problems you'll encounter are likely to be issues introduced during the port from IRIX (like the above) or existing limitations in the Linux block device layer. So, those issues aside, you shouldn't see any problems with XFS >2Tb. ;-) Steve sent some mail discussing the size of XFS inode numbers in bits a little while ago that will be of interest to you too (see http://oss.sgi.com/projects/xfs/mail_archive/0107/msg00727.html). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 8 19:36:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f792aub23536 for linux-xfs-outgoing; Wed, 8 Aug 2001 19:36:56 -0700 Received: from mustang.centralnet.ch (mustang.centralnet.ch [193.135.146.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f792arV23514 for ; Wed, 8 Aug 2001 19:36:54 -0700 Received: from vollmann.ch (luz171.centralnet.ch [193.135.147.171]) by mustang.centralnet.ch (8.9.3/8.9.3) with ESMTP id EAA348562 for ; Thu, 9 Aug 2001 04:36:41 +0200 (MES) Received: from two.vollmann.ch (localhost [127.0.0.1]) by vollmann.ch (8.8.6/8.8.5) with SMTP id CAA17482; Thu, 9 Aug 2001 02:37:22 GMT Message-ID: <3B71F762.58CD4725@vollmann.ch> Date: Thu, 09 Aug 2001 02:37:22 +0000 From: Detlef Vollmann Organization: vollmann engineering gmbh X-Mailer: Mozilla 3.04 (X11; U; Linux 2.2.14-5.0 i586) MIME-Version: 1.0 To: XFS list Subject: Problems with mkfs.xfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On writing a small testsuite for a simple utility, I hit several problems with mkfs.xfs (1.2.0): Minor problem: syntax mkfs.xfs does not conform to the mkfs syntax (at least not to the one described in mkfs(8) on Linux and which I know since more than 15 years now :-} mkfs -t xfs /dev/xxx 1234 produces just an error message on the size parameter :-( Bigger problem: semantics In the native mkfs.xfs option list, I found nothing that resembles the size parameter of the original mkfs command. I had to do some computations and give size parameters for the different parts (data and logging). Real problem: size itself I tried to create an xfs filesystem on a 4MB ramdisk (/dev/ram0), but I found no combination of option that succeeded. Did I not try hard enouh or is the lower limit for xfs size larger than 4MB? Detlef -- Detlef Vollmann vollmann engineering gmbh Tel: +41-41-4120911 P.O. Box 5106 Fax: +41-41-4120912 CH-6000 Luzern 5 / Switzerland eMail: dv@vollmann.ch From owner-linux-xfs@oss.sgi.com Wed Aug 8 19:57:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f792vWt24396 for linux-xfs-outgoing; Wed, 8 Aug 2001 19:57:32 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f792vTV24370 for ; Wed, 8 Aug 2001 19:57:29 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id EAA849518 for ; Thu, 9 Aug 2001 04:56:29 +0200 (CEST) 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 TAA04352; Wed, 8 Aug 2001 19:56:48 -0700 (PDT) Message-ID: <3B71FB2E.285A0E1F@sgi.com> Date: Wed, 08 Aug 2001 21:53:34 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Detlef Vollmann CC: XFS list Subject: Re: Problems with mkfs.xfs References: <3B71F762.58CD4725@vollmann.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Detlef Vollmann wrote: > Minor problem: syntax > mkfs.xfs does not conform to the mkfs syntax (at least not to > the one described in mkfs(8) on Linux and which I know since > more than 15 years now :-} > mkfs -t xfs /dev/xxx 1234 > produces just an error message on the size parameter :-( Part of the problem here is that "mkfs" is really just a wrapper for the actual "mkfs.foo" for each filesystem "foo"... the mkfs man page was probably written before there were any filesystems that had the concept of a log. So when the filesystem has 2 or even 3 things that can get a size, (data, log, realtime...) simply placing a number of blocks at the end is ambiguous. > Bigger problem: semantics > In the native mkfs.xfs option list, I found nothing that resembles > the size parameter of the original mkfs command. I had to do > some computations and give size parameters for the different > parts (data and logging). mkfs.xfs will do sane things if you don't specify any sizes - it will default to an internal log, with some decent value for the size of the log. What computations did you need to do? > Real problem: size itself > I tried to create an xfs filesystem on a 4MB ramdisk (/dev/ram0), > but I found no combination of option that succeeded. > Did I not try hard enouh or is the lower limit for xfs size > larger than 4MB? Not sure about this one, perhaps the Australians are more awake than I am and can speak to this. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Aug 8 20:03:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7933eh24944 for linux-xfs-outgoing; Wed, 8 Aug 2001 20:03:40 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7933bV24924 for ; Wed, 8 Aug 2001 20:03:37 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA26724 for ; Wed, 8 Aug 2001 20:03:22 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f7932Wf34502534 for ; Wed, 8 Aug 2001 20:02:32 -0700 (PDT) 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 FAA842473 for ; Thu, 9 Aug 2001 05:00:22 +0200 (CEST) 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 UAA59798; Wed, 8 Aug 2001 20:00:27 -0700 (PDT) Message-ID: <3B71FC09.64125EF0@sgi.com> Date: Wed, 08 Aug 2001 21:57:13 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: `matte CC: linux-xfs@oss.sgi.com Subject: Re: How to make ext3+xfs kernel? References: <20010809022550.A13288@home.xs> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk `matte wrote: > > Hi all, I'm a little newbie ;-) > I'was trying to patch a 2.4.7 kernel with ext3 and xfs patches, but > there are some errors. I can patch with ext3 only and all is done, so > with xfs only, but no ext3+xfs. > > I'm here to ask how I have to patch to obtain a correct kernel. Well, the only real answer is "resolve the conflicts" - sorry! I have not yet tried patching xfs + ext3, so I'm afraid I don't have any advice. -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 Aug 8 20:10:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f793An625677 for linux-xfs-outgoing; Wed, 8 Aug 2001 20:10:49 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f793AlV25656 for ; Wed, 8 Aug 2001 20:10:47 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA27412 for ; Wed, 8 Aug 2001 20:10:32 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA16953; Thu, 9 Aug 2001 13:09:30 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA55612; Thu, 9 Aug 2001 13:09:29 +1000 (AEST) Date: Thu, 9 Aug 2001 13:09:28 +1000 From: Nathan Scott To: Detlef Vollmann Cc: XFS list Subject: Re: Problems with mkfs.xfs Message-ID: <20010809130928.D260586@wobbly.melbourne.sgi.com> References: <3B71F762.58CD4725@vollmann.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B71F762.58CD4725@vollmann.ch>; from dv@vollmann.ch on Thu, Aug 09, 2001 at 02:37:22AM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 09, 2001 at 02:37:22AM +0000, Detlef Vollmann wrote: > On writing a small testsuite for a simple utility, I hit > several problems with mkfs.xfs (1.2.0): > > Minor problem: syntax > mkfs.xfs does not conform to the mkfs syntax (at least not to > the one described in mkfs(8) on Linux and which I know since > more than 15 years now :-} > mkfs -t xfs /dev/xxx 1234 > produces just an error message on the size parameter :-( > Hmm... yes, you're right. If it's a problem, send a patch. You're the first person to notice this in well over a year now, so I guess it just hasn't bothered most people. > Bigger problem: semantics > In the native mkfs.xfs option list, I found nothing that resembles > the size parameter of the original mkfs command. I had to do > some computations and give size parameters for the different > parts (data and logging). You're after the -d size=XXXb option, which I think would most closely match the optional [blocks] parameter of mkfs. > > Real problem: size itself > I tried to create an xfs filesystem on a 4MB ramdisk (/dev/ram0), > but I found no combination of option that succeeded. > Did I not try hard enouh or is the lower limit for xfs size > larger than 4MB? > Yes - the minimum is 16MB, if I remember correctly (ie. the minimum size of one allocation group). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 8 20:19:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f793Jx526730 for linux-xfs-outgoing; Wed, 8 Aug 2001 20:19:59 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f793JvV26711 for ; Wed, 8 Aug 2001 20:19:57 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA05780 for ; Wed, 8 Aug 2001 20:17:52 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA16986; Thu, 9 Aug 2001 13:18:40 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA75192; Thu, 9 Aug 2001 13:18:39 +1000 (AEST) Date: Thu, 9 Aug 2001 13:18:39 +1000 From: Nathan Scott To: Eric Sandeen Cc: Detlef Vollmann , XFS list Subject: Re: Problems with mkfs.xfs Message-ID: <20010809131838.E260586@wobbly.melbourne.sgi.com> References: <3B71F762.58CD4725@vollmann.ch> <3B71FB2E.285A0E1F@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: <3B71FB2E.285A0E1F@sgi.com>; from sandeen@sgi.com on Wed, Aug 08, 2001 at 09:53:34PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Aug 08, 2001 at 09:53:34PM -0500, Eric Sandeen wrote: > Detlef Vollmann wrote: > > > Minor problem: syntax > > mkfs.xfs does not conform to the mkfs syntax (at least not to > > the one described in mkfs(8) on Linux and which I know since > > more than 15 years now :-} > > mkfs -t xfs /dev/xxx 1234 > > produces just an error message on the size parameter :-( > > Part of the problem here is that "mkfs" is really just a wrapper for the > actual "mkfs.foo" for each filesystem "foo"... the mkfs man page was > probably written before there were any filesystems that had the concept > of a log. So when the filesystem has 2 or even 3 things that can get a > size, (data, log, realtime...) simply placing a number of blocks at the > end is ambiguous. Yup. From an XFS point of view, I guess the only sane interpretation for this extra argument would be to treat it as the size of the data device. Or just not worry about it - it may actually be more helpful to see the usage message & know what mkfs options are available. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 8 21:00:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79405929933 for linux-xfs-outgoing; Wed, 8 Aug 2001 21:00:05 -0700 Received: from mustang.centralnet.ch (mustang.centralnet.ch [193.135.146.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79402V29912 for ; Wed, 8 Aug 2001 21:00:02 -0700 Received: from vollmann.ch (luz135.centralnet.ch [193.135.147.135]) by mustang.centralnet.ch (8.9.3/8.9.3) with ESMTP id FAA352305; Thu, 9 Aug 2001 05:59:52 +0200 (MES) Received: from two.vollmann.ch (localhost [127.0.0.1]) by vollmann.ch (8.8.6/8.8.5) with SMTP id DAA00548; Thu, 9 Aug 2001 03:55:44 GMT Message-ID: <3B7209C0.1DDDE1DD@vollmann.ch> Date: Thu, 09 Aug 2001 03:55:44 +0000 From: Detlef Vollmann Organization: vollmann engineering gmbh X-Mailer: Mozilla 3.04 (X11; U; Linux 2.2.14-5.0 i586) MIME-Version: 1.0 To: Nathan Scott CC: XFS list Subject: Re: Problems with mkfs.xfs References: <3B71F762.58CD4725@vollmann.ch> <20010809130928.D260586@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott wrote: > > hi, > > On Thu, Aug 09, 2001 at 02:37:22AM +0000, Detlef Vollmann wrote: > > On writing a small testsuite for a simple utility, I hit > > several problems with mkfs.xfs (1.2.0): > > > > Minor problem: syntax > > mkfs.xfs does not conform to the mkfs syntax (at least not to > > the one described in mkfs(8) on Linux and which I know since > > more than 15 years now :-} > > mkfs -t xfs /dev/xxx 1234 > > produces just an error message on the size parameter :-( > > > > Hmm... yes, you're right. If it's a problem, send a patch. Probably I should. Perhaps later. > > Bigger problem: semantics > > In the native mkfs.xfs option list, I found nothing that resembles > > the size parameter of the original mkfs command. I had to do > > some computations and give size parameters for the different > > parts (data and logging). > > You're after the -d size=XXXb option, which I think would most > closely match the optional [blocks] parameter of mkfs. If I read the manpage correctly, that filesystem would not fit into a device with size xxxb, as the log is still added. > > > > > Real problem: size itself > > I tried to create an xfs filesystem on a 4MB ramdisk (/dev/ram0), > > but I found no combination of option that succeeded. > > Did I not try hard enouh or is the lower limit for xfs size > > larger than 4MB? > > > > Yes - the minimum is 16MB, if I remember correctly (ie. the > minimum size of one allocation group). Ahh, that's serious. I'll have to find a workaround for that :-{ Thanks for the info. Detlef -- Detlef Vollmann vollmann engineering gmbh Tel: +41-41-4120911 P.O. Box 5106 Fax: +41-41-4120912 CH-6000 Luzern 5 / Switzerland eMail: dv@vollmann.ch From owner-linux-xfs@oss.sgi.com Wed Aug 8 21:20:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f794KFb31252 for linux-xfs-outgoing; Wed, 8 Aug 2001 21:20:15 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f794KAV31231 for ; Wed, 8 Aug 2001 21:20:10 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id GAA856725 for ; Thu, 9 Aug 2001 06:19:13 +0200 (CEST) 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 OAA17235; Thu, 9 Aug 2001 14:18:49 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA74146; Thu, 9 Aug 2001 14:18:48 +1000 (AEST) Date: Thu, 9 Aug 2001 14:18:48 +1000 From: Nathan Scott To: Detlef Vollmann Cc: XFS list Subject: Re: Problems with mkfs.xfs Message-ID: <20010809141847.I260586@wobbly.melbourne.sgi.com> References: <3B71F762.58CD4725@vollmann.ch> <20010809130928.D260586@wobbly.melbourne.sgi.com> <3B7209C0.1DDDE1DD@vollmann.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7209C0.1DDDE1DD@vollmann.ch>; from dv@vollmann.ch on Thu, Aug 09, 2001 at 03:55:44AM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 09, 2001 at 03:55:44AM +0000, Detlef Vollmann wrote: > > > In the native mkfs.xfs option list, I found nothing that resembles > > > the size parameter of the original mkfs command. I had to do > > > some computations and give size parameters for the different > > > parts (data and logging). > > > > You're after the -d size=XXXb option, which I think would most > > closely match the optional [blocks] parameter of mkfs. > If I read the manpage correctly, that filesystem would not > fit into a device with size xxxb, as the log is still added. > The log is either internal (ie. part of the data volume), in which case its size must be accounted for in sizing the data volume; or its external in which case you would have to give other mkfs options to show where it lives, and it would have to be on a different device. So, I think you'll find mkfs.xfs does all these computations for you. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 8 21:37:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f794blm31990 for linux-xfs-outgoing; Wed, 8 Aug 2001 21:37:47 -0700 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 f794biV31970 for ; Wed, 8 Aug 2001 21:37:44 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f794hCW19833 for ; Wed, 8 Aug 2001 21:43:13 -0700 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA31971; Thu, 9 Aug 2001 14:36:21 +1000 (EST) Date: Thu, 9 Aug 2001 14:36:20 +1000 From: Timothy Shimmin To: "Daniel J. Mastrian" Cc: linux-xfs@oss.sgi.com Subject: Re: Default ACL execute permission inheritance Message-ID: <20010809143620.M78571@boing.melbourne.sgi.com> References: <788335771.997220748@[192.168.1.4]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <788335771.997220748@[192.168.1.4]>; from djm2@andrew.cmu.edu on Tue, Aug 07, 2001 at 09:45:48PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Dan, On Tue, Aug 07, 2001 at 09:45:48PM -0400, Daniel J. Mastrian wrote: > I've searched through the Linux-XFS mailing list archives, searched through > google, and even skimmed the IEEE Posix 1003.1e draft standard, and perhaps > I'm just dense, but I haven't found a sufficient answer to this question > about ACLs (in general...although in this case I am using XFS on Linux) > > I want the user and group who owns /foo to have rw- for all files, and rwx > for all directories. I want user apache to have r-- for all files, and r-x > for all directories. Everyone else should have --- (although I want to > leave the option open to give a specific user write access later on, for > example) > > So say I set /foo to have this default ACL... > u::rwx,g::rwx,o::---,m::rwx,u:apache:r-x > > Now, if I create a directory /foo/bar, bar has an access ACL and a default > ACL identical to /foo's default ACL. Correct, intended behavior, yay. > > However, if I 'touch somefile', I get a file access ACL that is not what I > expected... > > u::rw-,g::rwx,o::---,m::rw-,u:apache:r-x > > I see two things wrong with this. (1) ACL_GROUP_OBJ has rwx perms. It > should not be able to execute. I believe someone else on this list > mentioned that this was part of the standard, although weird. If this is > intended behavior, could someone please confirm it? (2) apache has r-x > perms, and should also not have the execute bit set. Shouldn't the execute > bit have been dropped by intersection with the rw-rw-rw- creation > permissions? > The result you reported seems correct to me according to the standard. * As you would probably know, the umask takes no effect in this situation with a default ACL. (just thought I'd mention it :) * The mode bits of the creat/open called by touch (rw-rw-rw-) are intersected with: USER_OBJ ACE perms. - with the mode's user permissions OTHER ACE perms. - with the mode's other permissions GROUP_OBJ ACE perms. if there is no MASK ACE - with the mode's group permissions or MASK ACE if there is one - with the mode's group permissions Check out section 5.3.1.2 of standard - confusingly worded. Note that if there is a MASK ACE, then the standard group permissions (as seen with ls -l) will match the MASK ACE (see section 23.1.2 of standard on File Permission bits). * Thus, USER and GROUP ACEs are the same as the default ACLs'; they are not intersected with anything. HOWEVER, the MASK ACE will be used with them in the ACL Access Check algorithm (section 23.1.5 of standard). * In your case, as we have a MASK ACE, the GROUP_OBJ permissions are not intersected with the mode's group permissions, the MASK ACE's permissions are set instead (as I said above) Cheers, Tim. From owner-linux-xfs@oss.sgi.com Wed Aug 8 22:23:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f795NS103741 for linux-xfs-outgoing; Wed, 8 Aug 2001 22:23:28 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f795NJV03704 for ; Wed, 8 Aug 2001 22:23:19 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 536B6C00FAE for ; Thu, 9 Aug 2001 13:01:18 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 98B77C00FAF for ; Thu, 9 Aug 2001 13:01:16 +0800 (PHT) Date: Thu, 9 Aug 2001 13:01:16 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: corrupt inode In-Reply-To: <997312195.20199.34.camel@stantz.corp.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 On 8 Aug 2001 at 16:09, Florin Andrei wrote: > On a server that's not very loaded, i think it's ok to run "sync" > every now and then, if the data is extremely important. Shouldn't bdflush (or something like that) handle regular flushing of buffers to disk for the event that the system dies without a clean shutdown/unmount? How does XFS handle the cache (or is the a kernel function that is independent from the filesystem)? When does data get sent to disk other than during explicit sync calls (or deletes, which are done synchronously, hehehe)? --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 9 00:03:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7973KW13596 for linux-xfs-outgoing; Thu, 9 Aug 2001 00:03:20 -0700 Received: from exocore.com (PPP-200-9-118.bng.vsnl.net.in [203.200.9.118]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7973GV13574 for ; Thu, 9 Aug 2001 00:03:17 -0700 Received: (from shanu@localhost) by exocore.com (8.11.2/8.8.7) id f79737n05981 for linux-xfs@oss.sgi.com; Thu, 9 Aug 2001 12:33:07 +0530 Date: Thu, 9 Aug 2001 12:33:07 +0530 From: Shanker Balan To: XFS list Subject: Re: XFS / VmWare Compatibility Message-ID: <20010809123307.A3254@exocore.com> Reply-To: Shanker Balan Mail-Followup-To: XFS list References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jtrostel@connex.com on Wed, Aug 08, 2001 at 10:52:08AM -0400 Organisation: Exocore Consulting (P) Ltd Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello: John Trostel wrote, > I remember reading several posts a bit ago about people having > difficulty compiling VMWare under the newer kernels now in the XFS > CVS. Has anyone (re)built the VMWare modules with the latest XFS CVS > trees? Heh, i just asked the very same thing yday on irc.debian.org. Basically, u need to update a couple of files in the vmmon.tar file (driver.c IIRC). I can mail in the updated vmmon.tar if its ok with you as i don't remember the specific changes. IAC, google should be able to provide you with a suitable link which describes the procedure. I now just need to fix the stupid locking complaint that VMware gives out every time i start it from the XFS home partition. -- Shanu -- ------------------------------------------( Shanu )----- Shanker Balan http://people.exocore.com/shanu God is silent. Now if we can only get Man to shut up. From owner-linux-xfs@oss.sgi.com Thu Aug 9 01:13:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f798Dwn22215 for linux-xfs-outgoing; Thu, 9 Aug 2001 01:13:58 -0700 Received: from mail.isg.de (foobar.isg.de [62.96.243.63]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f798DsV22182 for ; Thu, 9 Aug 2001 01:13:54 -0700 Received: from isg.de (wall2-outer.isg.de [62.96.243.126]) by mail.isg.de (Postfix) with ESMTP id E385A77BDD3; Thu, 9 Aug 2001 10:13:52 +0200 (CEST) Message-ID: <3B724638.2E447882@isg.de> Date: Thu, 09 Aug 2001 10:13:44 +0200 From: Constantin Loizides Organization: Innovative Software AG X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: matte Cc: xfs-list Subject: Re: How to make ext3+xfs kernel? References: <20010809022550.A13288@home.xs> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD320F3ABB99B6AFA242B933D" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dies ist eine kryptographisch unterzeichnete Nachricht im MIME-Format. --------------msD320F3ABB99B6AFA242B933D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Matte, > I'was trying to patch a 2.4.7 kernel with ext3 and xfs patches, but I didn't do it for 2.4.7, but for 2.4.5. But there should be no great difference. > there are some errors. I can patch with ext3 only and all is done, so > with xfs only, but no ext3+xfs. > > I'm here to ask how I have to patch to obtain a correct kernel. > Thanks ;-) > my advice is: patch first xfs, see for rejected files (should be none) then patch ext3 look for rejected files for 2.4.5 that were less than 5 (if I remember correctly) open all files that belong together: eg. file.orig file.rej file.c Look in file.rej where the patch didn't succeed. Look in file.orig at which line number it should work do the changes in file.c by hand Hope that helps... Constantin --------------msD320F3ABB99B6AFA242B933D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Kryptographische Unterschrift mit S/MIME MIIGAwYJKoZIhvcNAQcCoIIF9DCCBfACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC A+wwggPoMIIDUaADAgECAgICcTANBgkqhkiG9w0BAQQFADCBvjELMAkGA1UEBhMCREUxDzAN BgNVBAgTBkhlc3NlbjEaMBgGA1UEBxMRRnJhbmtmdXJ0IGFtIE1haW4xITAfBgNVBAoTGElu bm92YXRpdmUgU29mdHdhcmUgR21iSDEfMB0GA1UECxMWTmV0d29yayBBZG1pbmlzdHJhdGlv bjEiMCAGA1UEAxMZSVNHIENlcnRpZmljYXRlIEF1dGhvcml0eTEaMBgGCSqGSIb3DQEJARYL aW5mb0Bpc2cuZGUwHhcNMDEwNTAyMTQxNTI0WhcNMDYxMDIzMTQxNTI0WjCBqTELMAkGA1UE BhMCREUxDzANBgNVBAgTBkhlc3NlbjEMMAoGA1UEBxMDRmZtMR8wHQYDVQQKExZJbm5vdmF0 aXZlIFNvZnR3YXJlIEFHMREwDwYDVQQLEwhSZXNlYXJjaDEcMBoGA1UEAxMTQ29uc3RhbnRp biBMb2l6aWRlczEpMCcGCSqGSIb3DQEJARYaQ29uc3RhbnRpbi5Mb2l6aWRlc0Bpc2cuZGUw XDANBgkqhkiG9w0BAQEFAANLADBIAkEAsW2pUSk51o7X5A8uQihUQSdCN0sYAwOPKdJRxchM Qy1hexd1b8H0AVWWJFe4Yu2j84YGRh/G8dBJHzXXIgXnmQIDAQABo4IBSjCCAUYwCQYDVR0T BAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFNeyMNn58HC/DEARX6lxYmwcm4FzMIHrBgNVHSMEgeMwgeCAFJyzCKYgVHSxntGN kKK4rHhml9G6oYHEpIHBMIG+MQswCQYDVQQGEwJERTEPMA0GA1UECBMGSGVzc2VuMRowGAYD VQQHExFGcmFua2Z1cnQgYW0gTWFpbjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBTb2Z0d2FyZSBH bWJIMR8wHQYDVQQLExZOZXR3b3JrIEFkbWluaXN0cmF0aW9uMSIwIAYDVQQDExlJU0cgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MRowGAYJKoZIhvcNAQkBFgtpbmZvQGlzZy5kZYIBADANBgkq hkiG9w0BAQQFAAOBgQBml7w7SceeJ52t6FsokyIELEVVzEHgvaYlupX9ZNXbUctdfi0DpHXZ cS0OPrU1dY56665RiPw7XDcVSnEiPNwJsi/Z2042RKfSkK1Vwj2rCB6tX7w5U+Q6pUIZdWhI kb3YLYNLFU9BYrH6jlljWtYpovxDZCtsuVbGbQZ95XsnwTGCAd8wggHbAgEBMIHFMIG+MQsw CQYDVQQGEwJERTEPMA0GA1UECBMGSGVzc2VuMRowGAYDVQQHExFGcmFua2Z1cnQgYW0gTWFp bjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBTb2Z0d2FyZSBHbWJIMR8wHQYDVQQLExZOZXR3b3Jr IEFkbWluaXN0cmF0aW9uMSIwIAYDVQQDExlJU0cgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRow GAYJKoZIhvcNAQkBFgtpbmZvQGlzZy5kZQICAnEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTA4MDkwODEzNDVaMCMGCSqGSIb3 DQEJBDEWBBQAILuzqj/gVoSImGkh309WwPaZrTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0D AgIBKDANBgkqhkiG9w0BAQEFAARAcgNaTHQdkNBk2SxcHi0CKiFbf/0+h93MPqYpYkCgC2ap UalfGLNcW/dHT+q+02mvtX/4pOwgaw2CD+AcfRVb9w== --------------msD320F3ABB99B6AFA242B933D-- From owner-linux-xfs@oss.sgi.com Thu Aug 9 01:47:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f798lBb26300 for linux-xfs-outgoing; Thu, 9 Aug 2001 01:47:11 -0700 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 f798l9V26280 for ; Thu, 9 Aug 2001 01:47:09 -0700 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 f798pYS24077 for ; Thu, 9 Aug 2001 01:51:34 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA18413; Thu, 9 Aug 2001 18:45:46 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA64334; Thu, 9 Aug 2001 18:45:45 +1000 (AEST) Date: Thu, 9 Aug 2001 18:45:44 +1000 From: Nathan Scott To: Detlef Vollmann Cc: XFS list Subject: Re: Problems with mkfs.xfs Message-ID: <20010809184544.L260586@wobbly.melbourne.sgi.com> References: <3B71F762.58CD4725@vollmann.ch> <20010809130928.D260586@wobbly.melbourne.sgi.com> <3B7209C0.1DDDE1DD@vollmann.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7209C0.1DDDE1DD@vollmann.ch>; from dv@vollmann.ch on Thu, Aug 09, 2001 at 03:55:44AM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 09, 2001 at 03:55:44AM +0000, Detlef Vollmann wrote: > Nathan Scott wrote: > > > > > > Real problem: size itself > > > I tried to create an xfs filesystem on a 4MB ramdisk (/dev/ram0), > > > but I found no combination of option that succeeded. > > > Did I not try hard enouh or is the lower limit for xfs size > > > larger than 4MB? > > > > > > > Yes - the minimum is 16MB, if I remember correctly (ie. the > > minimum size of one allocation group). > Ahh, that's serious. I'll have to find a workaround for that :-{ > I looked into this a bit more ... I got that minimum size from the man page, so assumed it was right. Its not. On IRIX, I'm able to create a 4MB filesystem (which is strange because IRIX mkfs man page also documents 16MB as the minimum). To create a filesystem this small, you need to use -linternal,size=512b (thanks for the tip, Eric). Our Linux code goes south when I try to mount a 4MB filesystem though - the log recovery code tries to write at a really big offset and crashes and burns a bit after doing that. I'll look into this a bit more tomorrow - it seems very strange (broken). [btw, another thing I found with the rd driver is you'll need to set the blocksize to 512 for XFS - it defaults to 1024, but this is configurable] cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 9 02:03:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7993tb28743 for linux-xfs-outgoing; Thu, 9 Aug 2001 02:03:55 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7993rV28723 for ; Thu, 9 Aug 2001 02:03:53 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 8D48B1E0C1; Thu, 9 Aug 2001 11:03:47 +0200 (MEST) Date: Thu, 9 Aug 2001 11:03:46 +0200 From: Andi Kleen To: Nathan Scott Cc: Ragnar Kj?rstad , linux-xfs@oss.sgi.com Subject: Re: xfsprogs support for > 1TB devices. Message-ID: <20010809110346.A10539@gruyere.muc.suse.de> References: <20010809030249.C9580@vestdata.no> <20010809114155.C260586@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: <20010809114155.C260586@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Thu, Aug 09, 2001 at 11:41:56AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 11:41:56AM +1000, Nathan Scott wrote: > I don't have access to a big enough Linux system to try it I'm > afraid, but the IRIX/XFS code is obviously 64 bit clean, so we > had a good starting point for Linux/XFS - the sorts of problems > you'll encounter are likely to be issues introduced during the > port from IRIX (like the above) or existing limitations in the > Linux block device layer. So, those issues aside, you shouldn't > see any problems with XFS >2Tb. ;-) You can simulate > 1TB block device on linux by using the loopback device with a holey backing file. Just don't fill it. -Andi From owner-linux-xfs@oss.sgi.com Thu Aug 9 05:14:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79CEGM15607 for linux-xfs-outgoing; Thu, 9 Aug 2001 05:14:16 -0700 Received: from galactica.it (mail6.galactica.it [212.41.208.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79CEEV15586 for ; Thu, 9 Aug 2001 05:14:14 -0700 Received: from mat.home.xs ([62.122.98.87]) by galactica.it with Microsoft SMTPSVC(5.5.1877.537.53); Thu, 9 Aug 2001 14:17:05 +0200 Received: by mat.home.xs (Postfix, from userid 1000) id B97721173C1; Thu, 9 Aug 2001 14:15:59 +0200 (CEST) Date: Thu, 9 Aug 2001 14:15:55 +0200 From: `matte To: xfs-list Subject: Re: How to make ext3+xfs kernel? Message-ID: <20010809141553.A1030@home.xs> Mail-Followup-To: xfs-list References: <20010809022550.A13288@home.xs> <3B724638.2E447882@isg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B724638.2E447882@isg.de> User-Agent: Mutt/1.3.18i X-Operating-System: Debian GNU/Linux 2.4.7-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk * Constantin Loizides wrote: > my advice is: patch first xfs, see for rejected files (should be none) > then patch ext3 [..cut] > Look in file.orig at which line number it should work > do the changes in file.c by hand > > Hope that helps... > Constantin Thanks! Bye From owner-linux-xfs@oss.sgi.com Thu Aug 9 06:39:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Ddt727074 for linux-xfs-outgoing; Thu, 9 Aug 2001 06:39:55 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79DdpV27052 for ; Thu, 9 Aug 2001 06:39:52 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA04283 for ; Thu, 9 Aug 2001 06:38:50 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2583712; Thu, 9 Aug 2001 08:38:28 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA30267; Thu, 9 Aug 2001 08:38:28 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f79Dbqq04067; Thu, 9 Aug 2001 08:37:52 -0500 Message-Id: <200108091337.f79Dbqq04067@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Detlef Vollmann cc: Nathan Scott , XFS list Subject: Re: Problems with mkfs.xfs In-Reply-To: Message from Detlef Vollmann of "Thu, 09 Aug 2001 03:55:44 -0000." <3B7209C0.1DDDE1DD@vollmann.ch> Date: Thu, 09 Aug 2001 08:37:52 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Nathan Scott wrote: > > > > hi, > > > > On Thu, Aug 09, 2001 at 02:37:22AM +0000, Detlef Vollmann wrote: > > > On writing a small testsuite for a simple utility, I hit > > > several problems with mkfs.xfs (1.2.0): > > > > > > Minor problem: syntax > > > mkfs.xfs does not conform to the mkfs syntax (at least not to > > > the one described in mkfs(8) on Linux and which I know since > > > more than 15 years now :-} > > > mkfs -t xfs /dev/xxx 1234 > > > produces just an error message on the size parameter :-( > > > > > > > Hmm... yes, you're right. If it's a problem, send a patch. > Probably I should. Perhaps later. Take a look at the xfs mkfs source code first, it has many many calculations based on the size of various things in there to prevent you from making a non-working filesystem, adding new options is not as simple as you might think. > > > > Bigger problem: semantics > > > In the native mkfs.xfs option list, I found nothing that resembles > > > the size parameter of the original mkfs command. I had to do > > > some computations and give size parameters for the different > > > parts (data and logging). > > > > You're after the -d size=XXXb option, which I think would most > > closely match the optional [blocks] parameter of mkfs. > If I read the manpage correctly, that filesystem would not > fit into a device with size xxxb, as the log is still added. > > > > > > > > > Real problem: size itself > > > I tried to create an xfs filesystem on a 4MB ramdisk (/dev/ram0), > > > but I found no combination of option that succeeded. > > > Did I not try hard enouh or is the lower limit for xfs size > > > larger than 4MB? > > > > > > > Yes - the minimum is 16MB, if I remember correctly (ie. the > > minimum size of one allocation group). > Ahh, that's serious. I'll have to find a workaround for that :-{ There is unfortunately no workaround for this, XFS on a floppy would have been a nice test bed for people, however, there are some minimum sizes in XFS which prevent this. For deadlock reasons, the log must be twice the size of the largest potential transaction we can have, this makes the minimum log size 1200 4K blocks which is already over 4Mbytes. XFS was designed to scale up, not to scale down ;-) Steve > > Thanks for the info. > Detlef > > -- > Detlef Vollmann > vollmann engineering gmbh Tel: +41-41-4120911 > P.O. Box 5106 Fax: +41-41-4120912 > CH-6000 Luzern 5 / Switzerland eMail: dv@vollmann.ch From owner-linux-xfs@oss.sgi.com Thu Aug 9 06:42:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79DgBj27467 for linux-xfs-outgoing; Thu, 9 Aug 2001 06:42:11 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79Dg8V27434 for ; Thu, 9 Aug 2001 06:42:08 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA01638 for ; Thu, 9 Aug 2001 06:41:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2668078; Thu, 9 Aug 2001 08:40:49 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA84220; Thu, 9 Aug 2001 08:40:49 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f79DeD604079; Thu, 9 Aug 2001 08:40:13 -0500 Message-Id: <200108091340.f79DeD604079@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Detlef Vollmann cc: Nathan Scott , XFS list Subject: Re: Problems with mkfs.xfs In-Reply-To: Message from Detlef Vollmann of "Thu, 09 Aug 2001 03:55:44 -0000." <3B7209C0.1DDDE1DD@vollmann.ch> Date: Thu, 09 Aug 2001 08:40:13 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > > > > > > Real problem: size itself > > > I tried to create an xfs filesystem on a 4MB ramdisk (/dev/ram0), > > > but I found no combination of option that succeeded. > > > Did I not try hard enouh or is the lower limit for xfs size > > > larger than 4MB? > > > > > > > Yes - the minimum is 16MB, if I remember correctly (ie. the > > minimum size of one allocation group). > Ahh, that's serious. I'll have to find a workaround for that :-{ I sent my previous message and realized another workaround, if you want to experiment with xfs like this, then you can use a loop device on top of a file in an existing filesystem. Performance is pretty good, there is absolutely no guarantee of recovery after a crash, if you do not unmount cleanly it will not recover. Steve > > Thanks for the info. > Detlef > > -- > Detlef Vollmann > vollmann engineering gmbh Tel: +41-41-4120911 > P.O. Box 5106 Fax: +41-41-4120912 > CH-6000 Luzern 5 / Switzerland eMail: dv@vollmann.ch From owner-linux-xfs@oss.sgi.com Thu Aug 9 06:44:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Di0627822 for linux-xfs-outgoing; Thu, 9 Aug 2001 06:44:00 -0700 Received: from lists.samba.org (samba.sourceforge.net [198.186.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79DhtV27796 for ; Thu, 9 Aug 2001 06:43:55 -0700 Received: by lists.samba.org (Postfix, from userid 1002) id 728D35077; Thu, 9 Aug 2001 06:39:40 -0700 (PDT) From: Andrew Tridgell To: linux-xfs@oss.sgi.com Cc: marcelo@conectiva.com.br Subject: high load lockup Reply-To: tridge@valinux.com Message-Id: <20010809133940.728D35077@lists.samba.org> Date: Thu, 9 Aug 2001 06:39:40 -0700 (PDT) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've got a lockup in XFS under very high nfs load (SPECsfs with 5000 OPS). The lockup is reproducible. With 2.4.7-xfs (the oss.sgi.com CVS tree July 24th) I get the following backtrace in kdb: [0]kdb> btp 484 EBP EIP Function(args) 0xf05a9704 0x80114952 schedule+0x406 (0xd3a3e0e0, 0x1) kernel .text 0x80100000 0x8011454c 0x80114b60 0xf05a9730 0x80105d34 __down+0x78 kernel .text 0x80100000 0x80105cbc 0x80105d94 0xf05a9744 0x80105ef3 __down_failed+0xb (0xf05a97f4, 0xf888a92a, 0xd3a3e0e0, 0x60c000, 0xedaaef60) kernel .text 0x80100000 0x80105ee8 0x80105efc 0xf888ae0a [pagebuf].text.lock+0x10c pagebuf .text.lock 0xf888acfe 0xf888acfe 0xf888aea0 0xf05a974c 0xf888a81f [pagebuf]_pagebuf_grab_lock+0x13 (0xd3a3e0e0, 0x60c000) pagebuf .text 0xf8886060 0xf888a80c 0xf888a824 0xf05a97f4 0xf888a92a [pagebuf]_pagebuf_find_lockable_buffer+0x106 (0xedaaef60, 0x60c000, 0x0, 0x2000, 0x2201) pagebuf .text 0xf8886060 0xf888a824 0xf888aa18 0xf05a9824 0xf888aa49 [pagebuf]_pagebuf_get_lockable_buffer+0x31 (0xedaaef60, 0x60c000, 0x0, 0x2000, 0x2201) pagebuf .text 0xf8886060 0xf888aa18 0xf888aaf8 0xf05a9860 0xf8886ef2 [pagebuf]pagebuf_get+0x8e (0xedaaef60, 0x60c000, 0x0, 0x2000, 0x2201) pagebuf .text 0xf8886060 0xf8886e64 0xf8886fb4 0xf05a9890 0xf88ddf74 [xfs]xfs_trans_read_buf+0x48 (0xf0325400, 0x0, 0xf0325564, 0x3060, 0x0) xfs .text 0xf8894060 0xf88ddf2c 0xf88de230 0xf05a98ec 0xf88c9697 [xfs]xfs_itobp+0xfb (0xf0325400, 0x0, 0xe36fd7d0, 0xf05a9930, 0xf05a9934) xfs .text 0xf8894060 0xf88c959c 0xf88c975c 0xf05a9938 0xf88cc500 [xfs]xfs_iflush+0xa8 (0xe36fd7d0, 0x5) xfs .text 0xf8894060 0xf88cc458 0xf88cc86c 0xf05a994c 0xf88cd74e [xfs]xfs_inode_item_push+0x12 (0xe50a38f8) xfs .text 0xf8894060 0xf88cd73c 0xf88cd760 0xf05a998c 0xf88dd928 [xfs]xfs_trans_push_ail+0x120 (0xf0325400, 0x784a, 0xbf) xfs .text 0xf8894060 0xf88dd808 0xf88dda0c 0xf05a99d4 0xf88d0703 [xfs]xlog_grant_push_ail+0x14b (0xf0325400, 0x2c5b8) xfs .text 0xf8894060 0xf88d05b8 0xf88d0710 0xf05a99f0 0xf88cfadb [xfs]xfs_log_reserve+0x3f (0xf0325400, 0x2abb8, 0x2, 0xe6b46e54, 0x69) xfs .text 0xf8894060 0xf88cfa9c 0xf88cfb24 0xf05a9a1c 0xf88dc88a [xfs]xfs_trans_reserve+0x76 (0xe6b46e20, 0x0, 0x2abb8, 0x0, 0x4) xfs .text 0xf8894060 0xf88dc814 0xf88dc934 0xf05a9a58 0xf88a6300 [xfs]xfs_bmap_finish+0xac (0xf05a9b28, 0xf05a9ac0, 0xffffffff, 0xffffffff, 0xf05a9ab0) xfs .text 0xf8894060 0xf88a6254 0xf88a63ac 0xf05a9acc 0xf88cb0a6 [xfs]xfs_itruncate_finish+0x22e (0xf05a9b28, 0xb08742b4, 0x400, 0x0, 0x0) xfs .text 0xf8894060 0xf88cae78 0xf88cb19c 0xf05a9b54 0xf88e2ba1 [xfs]xfs_inactive_free_eofblocks+0x209 (0xf0325400, 0xb08742b4) xfs .text 0xf8894060 0xf88e2998 0xf88e2be8 0xf05a9b84 0xf88e32be [xfs]xfs_inactive+0x10e (0xb08742cc, 0x0) xfs .text 0xf8894060 0xf88e31b0 0xf88e360c 0xf05a9ba0 0xf88f2325 [xfs]vn_put+0x49 (0xd7f3394c) xfs .text 0xf8894060 0xf88f22dc 0xf88f2398 0xf05a9bac 0xf88f1499 [xfs]linvfs_put_inode+0x19 (0xd7f33840) xfs .text 0xf8894060 0xf88f1480 0xf88f14a0 0xf05a9bc0 0x8014b875 iput+0x2d (0xd7f33840) kernel .text 0x80100000 0x8014b848 0x8014b9d8 0xf05a9bdc 0x801491c1 prune_dcache+0xe9 (0x1c209) kernel .text 0x80100000 0x801490d8 0x80149250 0xf05a9be8 0x80149526 shrink_dcache_memory+0x22 (0x6, 0xf0, 0xf0, 0x1) kernel .text 0x80100000 0x80149504 0x80149538 0xf05a9c0c 0x8012f758 do_try_to_free_pages+0x28 (0xf0, 0x1, 0x0) kernel .text 0x80100000 0x8012f730 0x8012f78c 0xf05a9c20 0x8012f8bc try_to_free_pages+0x24 (0xf0) kernel .text 0x80100000 0x8012f898 0x8012f8c8 0xf05a9c50 0x801306e7 __alloc_pages+0x1d3 kernel .text 0x80100000 0x80130514 0x80130790 0xf05a9c5c 0x8013050b _alloc_pages+0x1b kernel .text 0x80100000 0x801304f0 0x80130514 0xf05a9c64 0x8013079d __get_free_pages+0xd kernel .text 0x80100000 0x80130790 0x801307ac 0xf05a9c88 0x8012caf3 kmem_cache_grow+0xe3 (0xf020a970, 0xf0, 0x0, 0x6) kernel .text 0x80100000 0x8012ca10 0x8012cc80 0xf05a9cb0 0x8012d0e2 kmem_cache_zalloc+0xa6 (0xf020a970, 0xf0, 0xeda92358) kernel .text 0x80100000 0x8012d03c 0x8012d11c 0xf05a9ccc 0xf888f7ef [xfs_support]kmem_zone_zalloc+0x43 (0xf020a970, 0x4) xfs_support .text 0xf888f060 0xf888f7ac 0xf888f840 0xf05a9cf0 0xf88ca721 [xfs]xfs_iread+0x2d (0xf0325400, 0x0, 0x340102b, 0x0, 0xf05a9d38) xfs .text 0xf8894060 0xf88ca6f4 0xf88ca890 0xf05a9d3c 0xf88c87cc [xfs]xfs_iget_core+0x214 (0xbd3c13cc, 0xf0325400, 0x0, 0x340102b, 0x0) xfs .text 0xf8894060 0xf88c85b8 0xf88c8ae0 0xf05a9d80 0xf88c8b4e [xfs]xfs_iget+0x6e (0xf0325400, 0x0, 0x340102b, 0x0, 0x0) xfs .text 0xf8894060 0xf88c8ae0 0xf88c8c14 0xf05a9df0 0xf88def23 [xfs]xfs_dir_lookup_int+0x137 (0x0, 0xc74296b4, 0x5, 0x80f8e43c, 0xf05a9e7c) xfs .text 0xf8894060 0xf88dedec 0xf88df0b0 0xf05a9e38 0xf88e36a2 [xfs]xfs_lookup+0x96 (0xc74296b4, 0x80f8e43c, 0xf05a9e78, 0xf05a9e7c, 0x0) xfs .text 0xf8894060 0xf88e360c 0xf88e370c 0xf05a9e88 0xf88ec6a4 [xfs]linvfs_lookup+0x64 (0xe6ac70c0, 0x80f8e3e0) xfs .text 0xf8894060 0xf88ec640 0xf88ec6f4 0xf05a9ea8 0x8014168a lookup_hash+0xaa (0xf05a9ec0, 0x9b2a8ba0) kernel .text 0x80100000 0x801415e0 0x801416e4 0xf05a9ecc 0x80141737 lookup_one_len+0x53 (0x8c8428b4, 0x9b2a8ba0, 0xd) kernel .text 0x80100000 0x801416e4 0x80141750 0xf05a9f04 0x8017f48f nfsd_lookup+0x34f (0xf7932600, 0xf7932400, 0x8c8428b4, 0xd, 0xf7932200) kernel .text 0x80100000 0x8017f140 0x8017f5bc 0xf05a9f2c 0x8017ce7e nfsd_proc_lookup+0x86 (0xf7932600, 0xf7932400, 0xf7932200) kernel .text 0x80100000 0x8017cdf8 0x8017ce94 0xf05a9f4c 0x8017c759 nfsd_dispatch+0xc5 (0xf7932600, 0xf0584014) kernel .text 0x80100000 0x8017c694 0x8017c7f0 0xf05a9fa8 0x802593ca svc_process+0x2ca (0xf0e89f60, 0xf7932600) kernel .text 0x80100000 0x80259100 0x80259650 We get a similar lockup with a 2.4.8pre7 kernel: [1]kdb> btp 506 EBP EIP Function(args) 0xf6899868 0x80113342 schedule+0x476 (0xd7e37380, 0x1) kernel .text 0x80100000 0x80112ecc 0x80113550 0xf6899894 0x80105b54 __down+0x78 kernel .text 0x80100000 0x80105adc 0x80105bb4 0xf68998a8 0x80105d13 __down_failed+0xb (0xf6899958, 0xf889a94a, 0xd7e37380, 0x4026e000, 0xf3e3ad20) kernel .text 0x80100000 0x80105d08 0x80105d1c 0xf889ae2a [pagebuf].text.lock+0x10c pagebuf .text.lock 0xf889ad1e 0xf889ad1e 0xf889aec0 0xf68998b0 0xf889a83f [pagebuf]_pagebuf_grab_lock+0x13 (0xd7e37380, 0x4026e000) pagebuf .text 0xf8896060 0xf889a82c 0xf889a844 0xf6899958 0xf889a94a [pagebuf]_pagebuf_find_lockable_buffer+0x106 (0xf3e3ad20, 0x4026e00 0, 0x6, 0x2000, 0x22200) pagebuf .text 0xf8896060 0xf889a844 0xf889aa38 0xf6899988 0xf889aa69 [pagebuf]_pagebuf_get_lockable_buffer+0x31 (0xf3e3ad20, 0x4026e000, 0x6, 0x2000, 0x22200) pagebuf .text 0xf8896060 0xf889aa38 0xf889ab18 0xf68999c4 0xf8896ef2 [pagebuf]pagebuf_get+0x8e (0xf3e3ad20, 0x4026e000, 0x6, 0x2000, 0x2 2200) pagebuf .text 0xf8896060 0xf8896e64 0xf8896fb4 0xf68999f0 0xf88ede6c [xfs]xfs_trans_get_buf+0xfc (0xe5ba5a60, 0xf1e6a164, 0x3201370, 0x0 , 0x2000) xfs .text 0xf88a4060 0xf88edd70 0xf88edeb4 0xf6899b3c 0xf88d4e76 [xfs]xfs_ialloc_ag_alloc+0x546 (0xe5ba5a60, 0xecd48b40, 0xf6899bc4) xfs .text 0xf88a4060 0xf88d4930 0xf88d51f4 0xf6899be8 0xf88d5599 [xfs]xfs_dialloc+0x149 (0xe5ba5a60, 0x6400095, 0x0, 0x81b6, 0x1) [1]more> xfs .text 0xf88a4060 0xf88d5450 0xf88d5cb8 0xf6899c4c 0xf88da9cf [xfs]xfs_ialloc+0x6f (0xe5ba5a60, 0x8559c890, 0x81b6, 0x1, 0x0) xfs .text 0xf88a4060 0xf88da960 0xf88dacf4 0xf6899cc4 0xf88ef117 [xfs]xfs_dir_ialloc+0x67 (0xf6899d70, 0x8559c890, 0x81b6, 0x1, 0x0) xfs .text 0xf88a4060 0xf88ef0b0 0xf88ef2c8 0xf6899d9c 0xf88f3b45 [xfs]xfs_create+0x439 (0x8559c8a8, 0x8b89679c, 0xf6899de8, 0x0, 0x0) xfs .text 0xf88a4060 0xf88f370c 0xf88f4150 0xf6899e58 0xf88fc4b5 [xfs]linvfs_common_cr+0x99 (0x982620a0, 0x8b896740, 0x81b6, 0x1, 0x0) xfs .text 0xf88a4060 0xf88fc41c 0xf88fc624 0xf6899e74 0xf88fc63c [xfs]linvfs_create+0x18 (0x982620a0, 0x8b896740, 0x81b6) xfs .text 0xf88a4060 0xf88fc624 0xf88fc640 0xf6899e9c 0x80142164 vfs_create+0xd8 (0x982620a0, 0x8b896740, 0x81b6) kernel .text 0x80100000 0x8014208c 0x801421d4 0xf6899ec8 0x80182eb3 nfsd_create+0x27b (0xf68a7600, 0xf68a7400, 0x970730b4, 0xd, 0xf68a7498) kernel .text 0x80100000 0x80182c38 0x80182f7c 0xf6899f2c 0x8017fd37 nfsd_proc_create+0x3f3 (0xf68a7600, 0xf68a7400, 0xf68a7200) kernel .text 0x80100000 0x8017f944 0x8017fe74 0xf6899f4c 0x8017ef79 nfsd_dispatch+0xc5 (0xf68a7600, 0xf6894014) kernel .text 0x80100000 0x8017eeb4 0x8017f010 0xf6899fa8 0x80241aaa svc_process+0x2ca (0xf731ed20, 0xf68a7600) kernel .text 0x80100000 0x802417e0 0x80241d30 0xf6899fec 0x8017ed37 nfsd+0x1af kernel .text 0x80100000 0x8017eb88 0x8017eeb4 [1]more> 0x801055c7 kernel_thread+0x23 kernel .text 0x80100000 0x801055a4 0x801055dc The system has 8 XFS filesystems of size 32G each, each fs is mounted with a 16M logdev on a trd ramdisk and noatime. Any ideas? pagebuf bug perhaps? Cheers, Tridge From owner-linux-xfs@oss.sgi.com Thu Aug 9 06:57:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Dv5s29655 for linux-xfs-outgoing; Thu, 9 Aug 2001 06:57:05 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79Dv3V29627 for ; Thu, 9 Aug 2001 06:57:03 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 670FA1E151; Thu, 9 Aug 2001 15:56:57 +0200 (MEST) Date: Thu, 9 Aug 2001 15:56:56 +0200 From: Andi Kleen To: Steve Lord Cc: XFS list Subject: Re: Problems with mkfs.xfs Message-ID: <20010809155656.A16173@gruyere.muc.suse.de> References: <200108091337.f79Dbqq04067@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108091337.f79Dbqq04067@jen.americas.sgi.com>; from lord@sgi.com on Thu, Aug 09, 2001 at 08:37:52AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, On Thu, Aug 09, 2001 at 08:37:52AM -0500, Steve Lord wrote: > There is unfortunately no workaround for this, XFS on a floppy would > have been a nice test bed for people, however, there are some minimum > sizes in XFS which prevent this. For deadlock reasons, the log must be > twice the size of the largest potential transaction we can have, this > makes the minimum log size 1200 4K blocks which is already over 4Mbytes. Just curious: which transaction could need 600 4K blocks? -Andi From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:03:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79E3NI30714 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:03:23 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79E3KV30694 for ; Thu, 9 Aug 2001 07:03:20 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA23896 for ; Thu, 9 Aug 2001 07:03:06 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1411792; Thu, 9 Aug 2001 09:02:04 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA05349; Thu, 9 Aug 2001 09:02:04 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f79E1Sn04163; Thu, 9 Aug 2001 09:01:28 -0500 Message-Id: <200108091401.f79E1Sn04163@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: Steve Lord , XFS list Subject: Re: Problems with mkfs.xfs In-Reply-To: Message from Andi Kleen of "Thu, 09 Aug 2001 15:56:56 +0200." <20010809155656.A16173@gruyere.muc.suse.de> Date: Thu, 09 Aug 2001 09:01:27 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi Steve, > > On Thu, Aug 09, 2001 at 08:37:52AM -0500, Steve Lord wrote: > > There is unfortunately no workaround for this, XFS on a floppy would > > have been a nice test bed for people, however, there are some minimum > > sizes in XFS which prevent this. For deadlock reasons, the log must be > > twice the size of the largest potential transaction we can have, this > > makes the minimum log size 1200 4K blocks which is already over 4Mbytes. > > Just curious: which transaction could need 600 4K blocks? > > -Andi Well, not one on a filesystem this small - but the logic which makes the minimum log size calculation is too simple to factor in the size of the filesystem. I do not know which one it might be, the size is calculated out of a set of horrendous macros, here is one for allocating extents for file data: /* * In a write transaction we can allocate a maximum of 2 * extents. This gives: * the inode getting the new extents: inode size * the inode\'s bmap btree: max depth * block size * the agfs of the ags from which the extents are allocated: 2 * sector * the superblock free block counter: sector size * the allocation btrees: 2 exts * 2 trees * (2 * max depth - 1) * block size * And the bmap_finish transaction can free bmap blocks in a join: * the agfs of the ags containing the blocks: 2 * sector size * the agfls of the ags containing the blocks: 2 * sector size * the super block free block counter: sector size * the allocation btrees: 2 exts * 2 trees * (2 * max depth - 1) * block size */ #define XFS_CALC_WRITE_LOG_RES(mp) \ (MAX( \ ((mp)->m_sb.sb_inodesize + \ XFS_FSB_TO_B((mp), XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK)) + \ (2 * (mp)->m_sb.sb_sectsize) + \ (mp)->m_sb.sb_sectsize + \ XFS_ALLOCFREE_LOG_RES(mp, 2) + \ (128 * (4 + XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) + XFS_ALLOCFREE_LOG_CO UNT(mp, 2)))),\ ((2 * (mp)->m_sb.sb_sectsize) + \ (2 * (mp)->m_sb.sb_sectsize) + \ (mp)->m_sb.sb_sectsize + \ XFS_ALLOCFREE_LOG_RES(mp, 2) + \ (128 * (5 + XFS_ALLOCFREE_LOG_COUNT(mp, 2)))))) And some of the macros this uses are complex too, fortunately these get worked out at mount time, not at transaction time. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:13:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79EDjE32195 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:13:45 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79EDdV32161 for ; Thu, 9 Aug 2001 07:13:41 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id D28CAC00FB1 for ; Thu, 9 Aug 2001 22:13:37 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 7819DC00FAE for ; Thu, 9 Aug 2001 22:13:36 +0800 (PHT) Date: Thu, 9 Aug 2001 22:13:36 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: bdflush (was: corrupt inode) In-Reply-To: <3B7296F9.E1FAB9CA@fnal.gov> 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 Thu, 9 Aug 2001 at 08:58, yocum@fnal.gov wrote: > Nope. If the machine dies while there's still data in the buffer (in > local memory cache) that data is gone. And it's possible to get files filled with binary zeroes, which is explained in the FAQ. Right? > You can lose an amount of data that is up to 30% of your available RAM > or 30 seconds worth depending. The default settings of /proc/sys/vm/bdflush with Linux kernel 2.4.7 (and most others, 2.4 and 2.2 kernels, I presume) are: nfract = 30 ndirty = 64 nrefill = 64 nref_dirt = 256 age_buffer = 3000 age_super = 60 Which means that (looking at the age_buffer and age_super values) that data block buffers are flushed at least every 30 seconds while metadata buffers are flushed at least every 1/60th of a second. So will setting age_buffer to 100 jiffies (1 second) be equivalent to running "sync" every second via a cron job? This does not seem to be XFS-specific, but I hope the list members will pardon my asking here. Yes, I _have_ read /usr/src/linux/Documentation/filesystems/proc.txt, without which I wouldn't have been able to understand the contents of /proc/sys/vm/bdflush. I am still unclear as to whether the actions of bdflush are equivalent to those of sync, though, at least with XFS. (I am not sure whether this is filesystem-specific or not) Also: let's say I modify a small file, then leave the system active for 30 seconds. Theoretically that means the data would have been flushed to disk already, right? Assuming write cache is turned off, of course. Then will turning off the machine (or it dying for some reason) cause a file filled with binary zeroes? It shouldn't, at least by my limited understanding. I hope I am correct. Thanks for your patience. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:15:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79EFMX32554 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:15:22 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79EFFV32521 for ; Thu, 9 Aug 2001 07:15:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA07535 for ; Thu, 9 Aug 2001 07:13:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2671500; Thu, 9 Aug 2001 09:13:57 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA94245; Thu, 9 Aug 2001 09:13:57 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f79EDLR04185; Thu, 9 Aug 2001 09:13:21 -0500 Message-Id: <200108091413.f79EDLR04185@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: tridge@valinux.com cc: linux-xfs@oss.sgi.com, marcelo@conectiva.com.br Subject: Re: high load lockup In-Reply-To: Message from Andrew Tridgell of "Thu, 09 Aug 2001 06:39:40 PDT." <20010809133940.728D35077@lists.samba.org> Date: Thu, 09 Aug 2001 09:13:20 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm, I didn't know linux could survive a stack this deep! Going back into XFS from the memory free case like this is the real problem. You probably have a multi-thread deadlock here, the xfs_trans_read_buf call is basically blocked on a locked buffer. The upper layer thread which did the original memory allocation is not holding any buffer locks at this point, but it will be holding an inode lock, possibly you have another thread somewhere which is holding the buffer and is attempting to lock an inode. The Irix memory freeing code is quite different from the Linux code, and XFS is a little sensitive to getting this exactly right. Try changing this line in xfs_iread (fs/xfs/xfs_inode.c) int alloc_mode = tp ? KM_SLEEP : KM_SLEEP_IO; to this int alloc_mode = KM_SLEEP; That will prevent this allocate from ever going into prune_dcache, which of course raises the chance that it will fail and we will die a horrible death. I hate to request it, since it sounds like it will be huge, but can you send me the output of the kdb command bta for one of these hangs. Steve > I've got a lockup in XFS under very high nfs load (SPECsfs with 5000 > OPS). The lockup is reproducible. With 2.4.7-xfs (the oss.sgi.com CVS > tree July 24th) I get the following backtrace in kdb: > > [0]kdb> btp 484 > EBP EIP Function(args) > 0xf05a9704 0x80114952 schedule+0x406 (0xd3a3e0e0, 0x1) > kernel .text 0x80100000 0x8011454c 0x80114b60 > 0xf05a9730 0x80105d34 __down+0x78 > kernel .text 0x80100000 0x80105cbc 0x80105d94 > 0xf05a9744 0x80105ef3 __down_failed+0xb (0xf05a97f4, 0xf888a92a, 0xd3a3e0e0, > 0x60c000, 0xedaaef60) > kernel .text 0x80100000 0x80105ee8 0x80105efc > 0xf888ae0a [pagebuf].text.lock+0x10c > pagebuf .text.lock 0xf888acfe 0xf888acfe 0xf88 > 8aea0 > 0xf05a974c 0xf888a81f [pagebuf]_pagebuf_grab_lock+0x13 (0xd3a3e0e0, 0x60c000) > pagebuf .text 0xf8886060 0xf888a80c 0xf888a824 > 0xf05a97f4 0xf888a92a [pagebuf]_pagebuf_find_lockable_buffer+0x106 (0xedaaef6 > 0, 0x60c000, 0x0, 0x2000, 0x2201) > pagebuf .text 0xf8886060 0xf888a824 0xf888aa18 > 0xf05a9824 0xf888aa49 [pagebuf]_pagebuf_get_lockable_buffer+0x31 (0xedaaef60, > 0x60c000, 0x0, 0x2000, 0x2201) > pagebuf .text 0xf8886060 0xf888aa18 0xf888aaf8 > 0xf05a9860 0xf8886ef2 [pagebuf]pagebuf_get+0x8e (0xedaaef60, 0x60c000, 0x0, 0 > x2000, 0x2201) > pagebuf .text 0xf8886060 0xf8886e64 0xf8886fb4 > 0xf05a9890 0xf88ddf74 [xfs]xfs_trans_read_buf+0x48 (0xf0325400, 0x0, 0xf03255 > 64, 0x3060, 0x0) > xfs .text 0xf8894060 0xf88ddf2c 0xf88de230 > 0xf05a98ec 0xf88c9697 [xfs]xfs_itobp+0xfb (0xf0325400, 0x0, 0xe36fd7d0, 0xf05 > a9930, 0xf05a9934) > xfs .text 0xf8894060 0xf88c959c 0xf88c975c > 0xf05a9938 0xf88cc500 [xfs]xfs_iflush+0xa8 (0xe36fd7d0, 0x5) > xfs .text 0xf8894060 0xf88cc458 0xf88cc86c > 0xf05a994c 0xf88cd74e [xfs]xfs_inode_item_push+0x12 (0xe50a38f8) > xfs .text 0xf8894060 0xf88cd73c 0xf88cd760 > 0xf05a998c 0xf88dd928 [xfs]xfs_trans_push_ail+0x120 (0xf0325400, 0x784a, 0xbf > ) > xfs .text 0xf8894060 0xf88dd808 0xf88dda0c > 0xf05a99d4 0xf88d0703 [xfs]xlog_grant_push_ail+0x14b (0xf0325400, 0x2c5b8) > xfs .text 0xf8894060 0xf88d05b8 0xf88d0710 > 0xf05a99f0 0xf88cfadb [xfs]xfs_log_reserve+0x3f (0xf0325400, 0x2abb8, 0x2, 0x > e6b46e54, 0x69) > xfs .text 0xf8894060 0xf88cfa9c 0xf88cfb24 > 0xf05a9a1c 0xf88dc88a [xfs]xfs_trans_reserve+0x76 (0xe6b46e20, 0x0, 0x2abb8, > 0x0, 0x4) > xfs .text 0xf8894060 0xf88dc814 0xf88dc934 > 0xf05a9a58 0xf88a6300 [xfs]xfs_bmap_finish+0xac (0xf05a9b28, 0xf05a9ac0, 0xff > ffffff, 0xffffffff, 0xf05a9ab0) > xfs .text 0xf8894060 0xf88a6254 0xf88a63ac > 0xf05a9acc 0xf88cb0a6 [xfs]xfs_itruncate_finish+0x22e (0xf05a9b28, 0xb08742b4 > , 0x400, 0x0, 0x0) > xfs .text 0xf8894060 0xf88cae78 0xf88cb19c > 0xf05a9b54 0xf88e2ba1 [xfs]xfs_inactive_free_eofblocks+0x209 (0xf0325400, 0xb > 08742b4) > xfs .text 0xf8894060 0xf88e2998 0xf88e2be8 > 0xf05a9b84 0xf88e32be [xfs]xfs_inactive+0x10e (0xb08742cc, 0x0) > xfs .text 0xf8894060 0xf88e31b0 0xf88e360c > 0xf05a9ba0 0xf88f2325 [xfs]vn_put+0x49 (0xd7f3394c) > xfs .text 0xf8894060 0xf88f22dc 0xf88f2398 > 0xf05a9bac 0xf88f1499 [xfs]linvfs_put_inode+0x19 (0xd7f33840) > xfs .text 0xf8894060 0xf88f1480 0xf88f14a0 > 0xf05a9bc0 0x8014b875 iput+0x2d (0xd7f33840) > kernel .text 0x80100000 0x8014b848 0x8014b9d8 > 0xf05a9bdc 0x801491c1 prune_dcache+0xe9 (0x1c209) > kernel .text 0x80100000 0x801490d8 0x80149250 > 0xf05a9be8 0x80149526 shrink_dcache_memory+0x22 (0x6, 0xf0, 0xf0, 0x1) > kernel .text 0x80100000 0x80149504 0x80149538 > 0xf05a9c0c 0x8012f758 do_try_to_free_pages+0x28 (0xf0, 0x1, 0x0) > kernel .text 0x80100000 0x8012f730 0x8012f78c > 0xf05a9c20 0x8012f8bc try_to_free_pages+0x24 (0xf0) > kernel .text 0x80100000 0x8012f898 0x8012f8c8 > 0xf05a9c50 0x801306e7 __alloc_pages+0x1d3 > kernel .text 0x80100000 0x80130514 0x80130790 > 0xf05a9c5c 0x8013050b _alloc_pages+0x1b > kernel .text 0x80100000 0x801304f0 0x80130514 > 0xf05a9c64 0x8013079d __get_free_pages+0xd > kernel .text 0x80100000 0x80130790 0x801307ac > 0xf05a9c88 0x8012caf3 kmem_cache_grow+0xe3 (0xf020a970, 0xf0, 0x0, 0x6) > kernel .text 0x80100000 0x8012ca10 0x8012cc80 > 0xf05a9cb0 0x8012d0e2 kmem_cache_zalloc+0xa6 (0xf020a970, 0xf0, 0xeda92358) > kernel .text 0x80100000 0x8012d03c 0x8012d11c > 0xf05a9ccc 0xf888f7ef [xfs_support]kmem_zone_zalloc+0x43 (0xf020a970, 0x4) > xfs_support .text 0xf888f060 0xf888f7ac 0xf888 > f840 > 0xf05a9cf0 0xf88ca721 [xfs]xfs_iread+0x2d (0xf0325400, 0x0, 0x340102b, 0x0, 0 > xf05a9d38) > xfs .text 0xf8894060 0xf88ca6f4 0xf88ca890 > 0xf05a9d3c 0xf88c87cc [xfs]xfs_iget_core+0x214 (0xbd3c13cc, 0xf0325400, 0x0, > 0x340102b, 0x0) > xfs .text 0xf8894060 0xf88c85b8 0xf88c8ae0 > 0xf05a9d80 0xf88c8b4e [xfs]xfs_iget+0x6e (0xf0325400, 0x0, 0x340102b, 0x0, 0x > 0) > xfs .text 0xf8894060 0xf88c8ae0 0xf88c8c14 > 0xf05a9df0 0xf88def23 [xfs]xfs_dir_lookup_int+0x137 (0x0, 0xc74296b4, 0x5, 0x > 80f8e43c, 0xf05a9e7c) > xfs .text 0xf8894060 0xf88dedec 0xf88df0b0 > 0xf05a9e38 0xf88e36a2 [xfs]xfs_lookup+0x96 (0xc74296b4, 0x80f8e43c, 0xf05a9e7 > 8, 0xf05a9e7c, 0x0) > xfs .text 0xf8894060 0xf88e360c 0xf88e370c > 0xf05a9e88 0xf88ec6a4 [xfs]linvfs_lookup+0x64 (0xe6ac70c0, 0x80f8e3e0) > xfs .text 0xf8894060 0xf88ec640 0xf88ec6f4 > 0xf05a9ea8 0x8014168a lookup_hash+0xaa (0xf05a9ec0, 0x9b2a8ba0) > kernel .text 0x80100000 0x801415e0 0x801416e4 > 0xf05a9ecc 0x80141737 lookup_one_len+0x53 (0x8c8428b4, 0x9b2a8ba0, 0xd) > kernel .text 0x80100000 0x801416e4 0x80141750 > 0xf05a9f04 0x8017f48f nfsd_lookup+0x34f (0xf7932600, 0xf7932400, 0x8c8428b4, > 0xd, 0xf7932200) > kernel .text 0x80100000 0x8017f140 0x8017f5bc > 0xf05a9f2c 0x8017ce7e nfsd_proc_lookup+0x86 (0xf7932600, 0xf7932400, 0xf79322 > 00) > kernel .text 0x80100000 0x8017cdf8 0x8017ce94 > 0xf05a9f4c 0x8017c759 nfsd_dispatch+0xc5 (0xf7932600, 0xf0584014) > kernel .text 0x80100000 0x8017c694 0x8017c7f0 > 0xf05a9fa8 0x802593ca svc_process+0x2ca (0xf0e89f60, 0xf7932600) > kernel .text 0x80100000 0x80259100 0x80259650 > > > We get a similar lockup with a 2.4.8pre7 kernel: > > > [1]kdb> btp 506 > EBP EIP Function(args) > 0xf6899868 0x80113342 schedule+0x476 (0xd7e37380, 0x1) > kernel .text 0x80100000 0x80112ecc > 0x80113550 > 0xf6899894 0x80105b54 __down+0x78 > kernel .text 0x80100000 0x80105adc > 0x80105bb4 > 0xf68998a8 0x80105d13 __down_failed+0xb (0xf6899958, 0xf889a94a, > 0xd7e37380, 0x4026e000, > 0xf3e3ad20) > kernel .text 0x80100000 0x80105d08 > 0x80105d1c > 0xf889ae2a [pagebuf].text.lock+0x10c > pagebuf .text.lock 0xf889ad1e 0xf889ad1e > 0xf889aec0 > 0xf68998b0 0xf889a83f [pagebuf]_pagebuf_grab_lock+0x13 (0xd7e37380, > 0x4026e000) > pagebuf .text 0xf8896060 0xf889a82c > 0xf889a844 > 0xf6899958 0xf889a94a [pagebuf]_pagebuf_find_lockable_buffer+0x106 > (0xf3e3ad20, 0x4026e00 > 0, 0x6, 0x2000, 0x22200) > pagebuf .text 0xf8896060 0xf889a844 > 0xf889aa38 > 0xf6899988 0xf889aa69 [pagebuf]_pagebuf_get_lockable_buffer+0x31 > (0xf3e3ad20, 0x4026e000, > 0x6, 0x2000, 0x22200) > pagebuf .text 0xf8896060 0xf889aa38 > 0xf889ab18 > 0xf68999c4 0xf8896ef2 [pagebuf]pagebuf_get+0x8e (0xf3e3ad20, 0x4026e000, > 0x6, 0x2000, 0x2 > 2200) > pagebuf .text 0xf8896060 0xf8896e64 > 0xf8896fb4 > 0xf68999f0 0xf88ede6c [xfs]xfs_trans_get_buf+0xfc (0xe5ba5a60, 0xf1e6a164, > 0x3201370, 0x0 > , 0x2000) > xfs .text 0xf88a4060 0xf88edd70 0xf88edeb4 > 0xf6899b3c 0xf88d4e76 [xfs]xfs_ialloc_ag_alloc+0x546 (0xe5ba5a60, > 0xecd48b40, 0xf6899bc4) > xfs .text 0xf88a4060 0xf88d4930 0xf88d51f4 > 0xf6899be8 0xf88d5599 [xfs]xfs_dialloc+0x149 (0xe5ba5a60, 0x6400095, 0x0, > 0x81b6, 0x1) > [1]more> > xfs .text 0xf88a4060 0xf88d5450 0xf88d5cb8 > 0xf6899c4c 0xf88da9cf [xfs]xfs_ialloc+0x6f (0xe5ba5a60, 0x8559c890, > 0x81b6, 0x1, 0x0) > xfs .text 0xf88a4060 0xf88da960 0xf88dacf4 > 0xf6899cc4 0xf88ef117 [xfs]xfs_dir_ialloc+0x67 (0xf6899d70, 0x8559c890, > 0x81b6, 0x1, 0x0) > xfs .text 0xf88a4060 0xf88ef0b0 0xf88ef2c8 > 0xf6899d9c 0xf88f3b45 [xfs]xfs_create+0x439 (0x8559c8a8, 0x8b89679c, > 0xf6899de8, 0x0, 0x0) > xfs .text 0xf88a4060 0xf88f370c 0xf88f4150 > 0xf6899e58 0xf88fc4b5 [xfs]linvfs_common_cr+0x99 (0x982620a0, 0x8b896740, > 0x81b6, 0x1, 0x0) > xfs .text 0xf88a4060 0xf88fc41c 0xf88fc624 > 0xf6899e74 0xf88fc63c [xfs]linvfs_create+0x18 (0x982620a0, 0x8b896740, > 0x81b6) > xfs .text 0xf88a4060 0xf88fc624 0xf88fc640 > 0xf6899e9c 0x80142164 vfs_create+0xd8 (0x982620a0, 0x8b896740, 0x81b6) > kernel .text 0x80100000 0x8014208c > 0x801421d4 > 0xf6899ec8 0x80182eb3 nfsd_create+0x27b (0xf68a7600, 0xf68a7400, > 0x970730b4, 0xd, 0xf68a7498) > kernel .text 0x80100000 0x80182c38 > 0x80182f7c > 0xf6899f2c 0x8017fd37 nfsd_proc_create+0x3f3 (0xf68a7600, 0xf68a7400, > 0xf68a7200) > kernel .text 0x80100000 0x8017f944 > 0x8017fe74 > 0xf6899f4c 0x8017ef79 nfsd_dispatch+0xc5 (0xf68a7600, 0xf6894014) > kernel .text 0x80100000 0x8017eeb4 > 0x8017f010 > 0xf6899fa8 0x80241aaa svc_process+0x2ca (0xf731ed20, 0xf68a7600) > kernel .text 0x80100000 0x802417e0 > 0x80241d30 > 0xf6899fec 0x8017ed37 nfsd+0x1af > kernel .text 0x80100000 0x8017eb88 > 0x8017eeb4 > [1]more> > 0x801055c7 kernel_thread+0x23 > kernel .text 0x80100000 0x801055a4 > 0x801055dc > > > > The system has 8 XFS filesystems of size 32G each, each fs is mounted > with a 16M logdev on a trd ramdisk and noatime. > > Any ideas? pagebuf bug perhaps? > > Cheers, Tridge From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:25:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79EP4L01453 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:25:04 -0700 Received: from lists.samba.org (samba.sourceforge.net [198.186.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79EP3V01434 for ; Thu, 9 Aug 2001 07:25:03 -0700 Received: by lists.samba.org (Postfix, from userid 1002) id 3B04E4559; Thu, 9 Aug 2001 07:20:47 -0700 (PDT) From: Andrew Tridgell To: lord@sgi.com Cc: linux-xfs@oss.sgi.com, marcelo@conectiva.com.br In-reply-to: <200108091413.f79EDLR04185@jen.americas.sgi.com> (message from Steve Lord on Thu, 09 Aug 2001 09:13:20 -0500) Subject: Re: high load lockup Reply-To: tridge@valinux.com References: <200108091413.f79EDLR04185@jen.americas.sgi.com> Message-Id: <20010809142047.3B04E4559@lists.samba.org> Date: Thu, 9 Aug 2001 07:20:47 -0700 (PDT) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, > Try changing this line in xfs_iread (fs/xfs/xfs_inode.c) > > int alloc_mode = tp ? KM_SLEEP : KM_SLEEP_IO; > > to this > > int alloc_mode = KM_SLEEP; ok, I'll launch a run like that now. I'll see if its locked up when I get up tomorrow. > I hate to request it, since it sounds like it will be huge, but can > you send me the output of the kdb command bta for one of these hangs. if it does lockup I'll send that along. Thanks! From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:37:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79EbYZ03172 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:37:34 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79EbVV03152 for ; Thu, 9 Aug 2001 07:37:31 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id C0B7B1AB11 for ; Thu, 9 Aug 2001 10:37:30 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 592136EA; Thu, 9 Aug 2001 10:37:30 -0400 (EDT) Date: Thu, 9 Aug 2001 10:37:30 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 Message-ID: <20010809103729.A26556@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 12:23:05AM +0200, Seth Mos wrote: > What compiler did you use? Some people had some weird issues > with the redhat compiler differing from machine to machine. egcs-2.91.66 There's one more compile note which may (or may not) be of interest - I applied ide.2.4.7-p3.all.07092001.patch to the tree after applying patch-2.4.7-xfs-2001-07-22. (The tree was initially virgin.) > > ...the "-990" error, though, definitely seems to be > > associated with a mounted filesystem... > It must be to generate one :-) But it's *still* mounted; that's the thing. When I read in the FAQ that this error means that XFS has shut the disk down, I don't expect it to still be mounted... > > kernel: spurious 8259A interrupt: IRQ15. > What is the parallel port doing on the second IDE controller > IRQ? I just put these extra kernel messages in for context. This one is harmless, as far as I can tell... http://uwsg.iu.edu/hypermail/linux/kernel/0012.0/0694.html ...as are the rest that I included. Just normal bootup stuff. This, though... > > kernel: nfsd: non-standard errno: -990 And this... > > os.mkdir(d, 0775) OSError: [Errno 990] > > Unknown error 990: '/n/bubba1/Projects/20_Million/COMP/scenes/hol183_8/film' > You will have errors on this fs that will need repairing. > Let's see if we can find some further clues. > > Do you see more messages with 990 in it in /var/log/messages? Nope. Just one. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:45:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79EjlZ04387 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:45:47 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79EjjV04367 for ; Thu, 9 Aug 2001 07:45:45 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id B22D71AB11 for ; Thu, 9 Aug 2001 10:45:44 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 49A876EA; Thu, 9 Aug 2001 10:45:44 -0400 (EDT) Date: Thu, 9 Aug 2001 10:45:44 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 Message-ID: <20010809104544.B26556@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200108082103.f78L3wX02935@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200108082103.f78L3wX02935@jen.americas.sgi.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 04:03:58PM -0500, Steve Lord wrote: > > kernel: XFS: bad magic number > > kernel: XFS: SB validate failed > Well, both of these will result in a failed mount, so this is > not the same filesystem. Also, if you get the 990 error, the > filesystem should no longer be accessible, so something else > is going on here. Okay - double checked these errors, and yes, they are failed mounts of a filesystem that's no longer there. The filesystem giving the 990 error, though, is still accessible... Andrew Klaassen From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:49:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79EnOF04952 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:49:24 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79EnMV04923 for ; Thu, 9 Aug 2001 07:49:22 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id E4E4C1AB11 for ; Thu, 9 Aug 2001 10:49:21 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id B21906EA; Thu, 9 Aug 2001 10:49:21 -0400 (EDT) Date: Thu, 9 Aug 2001 10:49:21 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 Message-ID: <20010809104921.C26556@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010808160948.D21284@dkp.com> <20010808223713.A1669@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010808223713.A1669@gruyere.muc.suse.de> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 10:37:13PM +0200, Andi Kleen wrote: > -990 is EFSCORRUPTED which XFS generates when it sees an nasty > error internally. You should probably have an error message > somewhere earlier in the logs. Other than the "SB validate failed" stuff, which I've determined are associated with another drive... nothing. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:51:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Eprr05245 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:51:53 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79EpqV05225 for ; Thu, 9 Aug 2001 07:51:52 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id BC2F81AB14 for ; Thu, 9 Aug 2001 10:51:51 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 8F8126EA; Thu, 9 Aug 2001 10:51:51 -0400 (EDT) Date: Thu, 9 Aug 2001 10:51:51 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: non-standard errno: -990 Message-ID: <20010809105151.D26556@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010808160948.D21284@dkp.com> <20010808223713.A1669@gruyere.muc.suse.de> <20010808170000.E21284@dkp.com> <20010809095021.A260586@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010809095021.A260586@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 09:50:21AM +1000, Nathan Scott wrote: > Only other suggestion would be to unmount and see what kind of > corruption xfs_repair picks up. I might be able to do that on the weekend. (Ugh. This working on the weekend thing is becoming a little too common for me...) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:55:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79EtGF05791 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:55:16 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79EtEV05769 for ; Thu, 9 Aug 2001 07:55:15 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.4/8.11.4) id f79Et9V16649 for linux-xfs@oss.sgi.com; Thu, 9 Aug 2001 10:55:09 -0400 Date: Thu, 9 Aug 2001 10:55:09 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: OT: WMware beta Message-ID: <20010809105509.A16557@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there anyone else on this list using VMware beta? Let me know and when I work up a vmmon patch tonight I'll send it to you. Please respond privately as VMware beta is not a topic for this list, nor a topic for public discussion in general. Thanks. Mpffmfmmfpmpmffpppmfm Pppppfppp-Mpmmfffmmmmfpmfppffmmfmfpffmpp Mmmmfmpffmppmppppmmpppppfmpfmm... -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Aug 9 07:58:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79EwI806210 for linux-xfs-outgoing; Thu, 9 Aug 2001 07:58:18 -0700 Received: from imapserver2.fnal.gov (imapserver2.fnal.gov [131.225.9.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79EwGV06190 for ; Thu, 9 Aug 2001 07:58:16 -0700 Received: from imapserver2.fnal.gov ([131.225.9.7]) by imapserver2.fnal.gov (Netscape Messaging Server 3.62) with SMTP id 1542 for ; Thu, 9 Aug 2001 09:58:16 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserver2.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001080909581519333 ; Thu, 09 Aug 2001 09:58:15 -0500 Message-ID: <3B72A5C9.C6178CF9@fnal.gov> Date: Thu, 09 Aug 2001 10:01:29 -0500 From: yocum@fnal.gov 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: linux ide , xfs-list Subject: 3ware driver and XFS kernel from SGI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, Does anyone have the latest 3ware driver (> v1.02.00.006) working in any of the XFS patched kernels from SGI (cvs or rpm)? When I do an insmod of the module, it locks up the system tight with the error "NMI watchdog detected lockup on CPU 1" (or CPU 0, depending on what mood it's in) and I don't seem to have the option of compiling it directly into the kernel, for some strange reason. 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 Aug 9 08:49:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79FnLR12171 for linux-xfs-outgoing; Thu, 9 Aug 2001 08:49:21 -0700 Received: from jinyblue ([211.180.39.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79FnDV12130 for ; Thu, 9 Aug 2001 08:49:14 -0700 Message-Id: <200108091549.f79FnDV12130@oss.sgi.com> From: =?ks_c_5601-1987?B?xsTGrrPK?= To: linux-xfs@oss.sgi.com Subject: =?ks_c_5601-1987?B?vd+87iC6o7PKsaSw7SDBpr7IwNS0z7TZLg==?= Date: Fri, 10 Aug 2001 00:49:20 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0F10A.93A49C00" X-Priority: 3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0F10A.93A49C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 bWFpbCAgICAgICAgICAgIL3fvO7AxyAguqOzyiCxpLDtIL7utrC9xcH2v+Q/ICANCg0KICAg ICAgICAgICAgICAgICAgICAgDQq+yLPnx8+8vL/kLiC937zuIMGmyN7GxMaus8ogtOO058Da wNS0z7TZLg0KIA0KIMerx6sgwu60wiC09cCnv6G1tSC+8MGms6ogvd+87sDHIMiruri4piDA p8fYIL7WveHB1rzFvK0gsKi757XluLO0z7TZLg0KIDi/+brOxc0gvd+87sDHIMbExq6zyiC8 9sDNsd3AzCDAzrvztce+7iDGxMaus8q01LKyILXluK60wiCx3b7XwMwgtPUguLm+xsGzvcC0 z7TZLg0KIA0Kwfax3SC52bfOIL3fvO7AxyC758DMxq63ziC/wL3DuOkgvPbAzbHdIMPWx88g MzAluKYgteW4rrDtIMDWvcC0z7TZLiCwxbHiv6EguMXD4iC067rxIMDOvL7GvLrqse7B9iDB +Mfgwd/AzLb4tM+02S4gvd+87iC758DMxq6/obytIMbExq6zyiDBpsjeILn2xrDAuyC7obiu IMWsuK/AuyDHz7y8v+QuDQogIA0KwMy5+LHiyLi/oSDIzr7AILT1ILP0vsbB+CDEv7nMvMfA uLfOIMbExq6zyrTUwMcgvPbAzbHdwLsgxsXGxSDDrLHivcOx4iC52bb4tM+02S4gXl4NCiC+ xrehwMcgx6W4piDC/LDtIMfPvLy/5C4gx/bA5yDGxMaus8ogu+fAzMautMIgwMzA/CC758DM xq6/zSC02biotM+02S4gwK/Ax8fPvLy/5CEhICAgICANCiAgICANCiANCiAgICAgICAgICAg ICAgICAgICC758DMwe4gIDQ2OCAqIDYwDQogICAgICAgIMa8vMXD97+hILD6s+EgwMy5zMH2 sKEgsde3wcH4IL/KwLsgwNTAuiC/qcDOwMwgte7A5cfPv6kNCiC53bq5tce0wiCw+rPhwMcg v/LB98DTwLsgs+vD4r3DxNG8rSC9w7yxwLsgwf3B38fPt8G0wiDAx7W1Lg0KICAgICAgICAg ICAgICAgICC758DMwe4gIDQ2OCAqIDYwDQogICAgICAgIMDavcXAxyDD68fitOu3ziCw8bbz ury89iDA1rTCIL3fvO4gISEgJ7nMvLqz4sDawMcgvNXAzCC06sH2IL7KtMIgsPcnv6EgILCz wOfH2CDB1ry8v+ReXjsNCiAgICAgICAgICAgICAgICAgu+fAzMHuIDQ2OCAgKiA2MCAgICAg ICAnwaa067fOIMLvwNontvO0wiC48MXkwMcguqOzyr+hIMDMufggvd+87sDHIMDMuqXGrrim IMPfsKHH0SCzu7/rDQogICAgICAgICAgICAgICC758DMxq64piC/7r+1x8+9w7jpvK0gvPbA zcC7IL7ywLi9w7DtIL3NwLi9yrTPse4/IL3fvO6woSC1tb/NILXluK6w2r3AtM+02S4NCiDD 1rTrx9EgxsTGrrPKt84gte63z8fPvcUgyLi/+LTUtenAuyDAp8fYvK0gv629ycj3IMfPsNq9 wLTPtNkuIL3fvO7AxyCz9L7GwfggxL+5zLzHsPoNCiC937zuwMcguuq3o7XluKYgx9G5+CC5 0L7uIMHWvcq9w7/kLiC8ur3Jsq8gwM/Hz7DavcC0z7TZLg0KIA0KyLi/+CDAzsGkseKwo8DM IDMwwM+3ziC1x776vcC0z7TZLiCh2qHaIMDMwPwgxsTGrrPKILvnwMzGrrTCIMDMsPe/oSCw oby8v+QuIKHaodoNCiDAzMD8IMbExq6zyiC758DMxq60wiC6r7W/u+fH18DMIL74vcC0z7TZ LiANCiDAzMGmIMi4v/i01LD6IL3fvO60wiCwocC7wLsgwdi68cfYvt8gtcu0z7TZLiCywCC9 37zuwMcguqOzyrimILTevsbB1ry8v+QuXl4gDQpHb29kIGx1Y2shICAgICAgICAgICAgICAg ICAgICAgICDGxMaus8ogsKHA1CC5rsDHIDogcGFydG5lckBzc2hvdy5jby5rciAgICAgICAg ICAgx+Owob74wMwguN7Az8C7ILq4s7u15bfBIMHLvNvH1bTPtNkuILHNx8/AxyC758DMxq6/ oSDHyr/kx9EguqOzyrChILXHvvrAuLjpILnZtvi0z7TZLiAgICAgICAgQ29weXJpZ2h0ICCo zyAyMDAwLTIwMDEuIFNzYW5nc2hvdy5jby5rciBDby4sTHRkLiBBbGwgcmlnaHRzIHJlc2Vy dmVkLiAgICAg ------=_NextPart_000_0007_01C0F10A.93A49C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5tYWlsPC9USVRMRT4NCjxNRVRBIEhUVFAtRVFVSVY9 IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8 bGluayByZWw9InN0eWxlc2hlZXQiIGhyZWY9ImNzcy9zdHlsZS5jc3MiIHR5cGU9InRleHQv Y3NzIj4NCjwvSEVBRD4NCjxCT0RZIEJHQ09MT1I9I0ZGRkZGRiBsZWZ0bWFyZ2luPSIwIiB0 b3BtYXJnaW49IjAiIG1hcmdpbndpZHRoPSIwIiBtYXJnaW5oZWlnaHQ9IjAiIGxpbms9IjRi NGI0YiI+DQo8IS0tIEltYWdlUmVhZHkgU2xpY2VzIChtYWlsLmdpZikgLS0+PGZvbnQgc2l6 ZT0iMiI+DQo8dGFibGUgd2lkdGg9IjYwMCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIg Y2VsbHBhZGRpbmc9IjAiIGFsaWduPSJjZW50ZXIiPg0KICA8dHI+DQogICAgPHRkIGhlaWdo dD0iMTAiPjwvdGQ+DQogIDwvdHI+DQo8L3RhYmxlPg0KPHRhYmxlIHdpZHRoPSI2MDAiIGJv cmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0iY2VudGVy Ij4NCiAgPHRyPg0KICAgIDx0ZCB3aWR0aD0iMzcxIj4mbmJzcDsgPC90ZD4NCiAgICA8dGQg d2lkdGg9IjI2MyI+IA0KICAgICAgPHRhYmxlIHdpZHRoPSIyNjMiIGJvcmRlcj0iMCIgY2Vs bHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgICAgICAgPHRyPiANCiAgICAgICAg ICA8dGQgd2lkdGg9IjEwIj48aW1nIHNyYz0iaHR0cDovL3d3dy5zc2FuZ3Nob3cuY28ua3Iv cGFydG5lcm1haWwvMDYxNS9pbWFnZXMvaW1nLTEuZ2lmIiB3aWR0aD0iMTAiIGhlaWdodD0i MjMiPjwvdGQ+DQogICAgICAgICAgPHRkIHdpZHRoPSIyNTMiIGJnY29sb3I9IjgxODE4MSIg YWxpZ249ImNlbnRlciIgdmFsaWduPSJib3R0b20iPjxmb250IGNvbG9yPSIjRkZGRkZGIiBz aXplPSIyIj48Yj6937zuwMcgDQogICAgICAgICAgICC6o7PKILGksO0gvu62sL3Fwfa/5D88 L2I+PC9mb250PjwvdGQ+DQogICAgICAgICAgPHRkIHdpZHRoPSIxMCI+IA0KICAgICAgICAg ICAgPHA+PGltZyBzcmM9Imh0dHA6Ly93d3cuc3NhbmdzaG93LmNvLmtyL3BhcnRuZXJtYWls LzA2MTUvaW1hZ2VzL2ltZy0yLmdpZiIgd2lkdGg9IjEwIiBoZWlnaHQ9IjIzIj48L3A+DQog ICAgICAgICAgICA8L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgPC90YWJsZT4NCiAgICA8 L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjx0YWJsZSB3aWR0aD0iNjAwIiBib3JkZXI9IjAi IGNlbGxzcGFjaW5nPSIyIiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImNlbnRlciIgYmdjb2xv cj0iNGI0YjRiIj4NCiAgPHRyPg0KICAgIDx0ZCBiZ2NvbG9yPSIjRkZGRkZGIiBhbGlnbj0i Y2VudGVyIj4gDQogICAgICA8dGFibGUgd2lkdGg9IjU5NiIgYm9yZGVyPSIwIiBjZWxsc3Bh Y2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgICAgICA8dHI+DQogICAgICAgICAgPHRk PjxpbWcgc3JjPSJodHRwOi8vd3d3LnNzYW5nc2hvdy5jby5rci9wYXJ0bmVybWFpbC8wNjE1 L2ltYWdlcy9pbWctNS5naWYiIHdpZHRoPSI1OTYiIGhlaWdodD0iNzYiPjwvdGQ+DQogICAg ICAgIDwvdHI+DQogICAgICA8L3RhYmxlPg0KICAgICAgPHRhYmxlIHdpZHRoPSI1OTYiIGJv cmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgICAgICAgPHRy Pg0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjE0Ij48L3RkPg0KICAgICAgICA8L3RyPg0KICAg ICAgPC90YWJsZT4NCiAgICAgIDx0YWJsZSB3aWR0aD0iNTM4IiBib3JkZXI9IjAiIGNlbGxz cGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAgIDx0cj4NCiAgICAgICAgICA8 dGQ+IA0KICAgICAgICAgICAgPHA+PGZvbnQgc2l6ZT0iMiI+vsiz58fPvLy/5C4gPGZvbnQg Y29sb3I9IiNGRjAwMDAiPjxiPr3fvO48L2I+PC9mb250PiDBpsjexsTGrrPKILTjtOfA2sDU tM+02S48YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgx6vHqyDC7rTC ILT1wKe/obW1IL7wwaazqiC937zuwMcgyKu6uLimIMCnx9ggvta94cHWvMW8rSCwqLvnteW4 s7TPtNkuPGJyPg0KICAgICAgICAgICAgIDi/+brOxc0gvd+87sDHIMbExq6zyiC89sDNsd3A zCDAzrvztce+7iDGxMaus8q01LKyILXluK60wiCx3b7XwMwgtPUguLm+xsGzvcC0z7TZLjxi cj4NCiAgICAgICAgICAgIDxwPjxmb250IGNvbG9yPSIjMDAwMEFBIj7B9rHdILnZt84gvd+8 7sDHILvnwMzGrrfOIL/AvcO46SC89sDNsd0gPGZvbnQgY29sb3I9IiNGRjAwMDAiPjxiPsPW x88gMzAluKY8L2I+PC9mb250PiC15biusO0gwNa9wLTPtNkuPC9mb250PiCwxbHiv6EguMXD 4iC067rxIMDOvL7GvLrqse7B9g0KICAgICAgICAgICAgICDB+Mfgwd/AzLb4tM+02S4gvd+8 7iC758DMxq6/obytIMbExq6zyiDBpsjeILn2xrDAuyC7obiuIMWsuK/AuyDHz7y8v+QuPGJy Pg0KICAgICAgICAgICAgIA0KICAgICAgICAgICAgPHA+IMDMufix4si4v6EgyM6+wCC09SCz 9L7GwfggxL+5zLzHwLi3ziDGxMaus8q01MDHILz2wM2x3cC7IMbFxsUgw6yx4r3DseIgudm2 +LTPtNkuIF5ePGJyPg0KICAgICAgICAgICAgIL7Gt6HAxyDHpbimIML8sO0gx8+8vL/kLiA8 dT7H9sDnIMbExq6zyiC758DMxq60wiDAzMD8ILvnwMzGrr/NILTZuKi0z7TZLiDAr8DHx8+8 vL/kISE8L2ZvbnQ+PC91Pg0KICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgPC90cj4NCiAg ICAgIDwvdGFibGU+DQogICAgICAmbmJzcDs8YnI+DQoNCiAgICAgIDx0YWJsZSB3aWR0aD0i NjAwIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAg ICAgIDx0cj4NCiAgICAgICAgICA8dGQ+DQogICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRl ciI+PGEgaHJlZj0iaHR0cDovL3d3dy5zc2FuZ3Nob3cuY28ua3IiPjxpbWcgc3JjPSJodHRw Oi8vd3d3LnNzYW5nc2hvdy5jby5rci9wYXJ0bmVybWFpbC8wNjE1L2ltYWdlcy9jb21taXNz aW9uLmdpZiIgYm9yZGVyPSIwIj48L2E+PC9wPiANCiAgICAgICAgICAgICA8cD4NCiAgICAg ICAgICA8L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgPC90YWJsZT4NCg0KICAgICAgPHRh YmxlIHdpZHRoPSI1MzgiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n PSIwIj4NCiAgICAgICAgPHRyPiANCiAgICAgICAgICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly93 d3cuc3NhbmdzaG93LmNvLmtyL3BhcnRuZXJtYWlsLzA2MTUvaW1hZ2VzL21lbnUtMi5naWYi IHdpZHRoPSIzMDYiIGhlaWdodD0iMjAiPjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICA8 L3RhYmxlPg0KICAgICAgPHRhYmxlIHdpZHRoPSI1OTYiIGJvcmRlcj0iMCIgY2VsbHNwYWNp bmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgICAgICAgPHRyPiANCiAgICAgICAgICA8dGQg aGVpZ2h0PSIxMCI+PC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgIDwvdGFibGU+DQoNCiAg ICAgIDx0YWJsZSB3aWR0aD0iNTM4IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIxIiBjZWxs cGFkZGluZz0iMCIgYmdjb2xvcj0iNGI0YjRiIj4NCiAgICAgICAgPHRyIGJnY29sb3I9IiNG RkZGRkYiIGFsaWduPSJjZW50ZXIiPiANCiAgICAgICAgICA8dGQgaGVpZ2h0PSI3MCIgY29s c3Bhbj0iMiI+PGEgaHJlZj0iaHR0cDovL3d3dy5zc2FuZ3Nob3cuY28ua3IiPjxpbWcgc3Jj PSdodHRwOi8vd3d3LmxpbmthZ2VudC5jby5rci9pbWcvYmFubmVyX2ltZy9iYW5uZXI3Lmdp ZicgYm9yZGVyPTA+PC9hPjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICAgIDx0ciBiZ2Nv bG9yPSIjRkZGRkZGIj4gDQogICAgICAgICAgPHRkIHdpZHRoPSI1NSIgaGVpZ2h0PSIyMSIg Ymdjb2xvcj0iRkVERkJEIiBjbGFzcz0iZm9udDEiIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0i Ym90dG9tIj6758DMwe48L3RkPg0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjIxIiBiZ2NvbG9y PSIjRkZGRkZGIiBhbGlnbj0iY2VudGVyIiBjbGFzcz0iZm9udDEiIHdpZHRoPSI0ODMiIHZh bGlnbj0iYm90dG9tIj4NCiAgICAgICAgICAgIDxkaXYgYWxpZ249ImNlbnRlciI+NDY4ICog NjA8L2Rpdj4NCiAgICAgICAgICA8L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgICA8dHIg Ymdjb2xvcj0iI0ZGRkZGRiIgYWxpZ249ImNlbnRlciI+IA0KICAgICAgICAgIDx0ZCBjb2xz cGFuPSIyIiBoZWlnaHQ9IjQzIj4gDQogICAgICAgICAgICA8dGFibGUgd2lkdGg9IjUyMCIg Ym9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgICAgICAg ICAgICA8dHI+IA0KICAgICAgICAgICAgICAgIDx0ZD4gDQogICAgICAgICAgICAgICAgICA8 cCBhbGlnbj0iY2VudGVyIj48Zm9udCBzaXplPSIyIj7GvLzFw/e/oSCw+rPhIMDMuczB9rCh ILHXt8HB+CC/ysC7IMDUwLogv6nAzsDMILXuwOXHz7+pPGJyPg0KICAgICAgICAgICAgICAg ICAgICC53bq5tce0wiCw+rPhwMcgv/LB98DTwLsgs+vD4r3DxNG8rSC9w7yxwLsgwf3B38fP t8G0wiDAx7W1LjwvZm9udD48L3A+DQogICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAg ICAgICAgICA8L3RyPg0KICAgICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgICA8L3RkPg0K ICAgICAgICA8L3RyPg0KICAgICAgPC90YWJsZT4NCiAgICAgIDx0YWJsZSB3aWR0aD0iNTk2 IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAg IDx0cj4gDQogICAgICAgICAgPHRkIGhlaWdodD0iNCI+PC90ZD4NCiAgICAgICAgPC90cj4N CiAgICAgIDwvdGFibGU+DQogICAgICA8dGFibGUgd2lkdGg9IjUzOCIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMSIgY2VsbHBhZGRpbmc9IjAiIGJnY29sb3I9IjRiNGI0YiI+DQogICAg ICAgIDx0ciBiZ2NvbG9yPSIjRkZGRkZGIiBhbGlnbj0iY2VudGVyIj4gDQogICAgICAgICAg PHRkIGhlaWdodD0iNzAiIGNvbHNwYW49IjIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuc3Nhbmdz aG93LmNvLmtyIj48aW1nIHNyYz0iaHR0cDovL3d3dy5zc2FuZ3Nob3cuY28ua3IvaW1hZ2Vz L2Jhbm5lci9iYW5uZXIxNi5naWYiIHdpZHRoPSI0NjgiIGhlaWdodD0iNjAiIGJvcmRlcj0i MCI+PC9hPjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICAgIDx0ciBiZ2NvbG9yPSIjRkZG RkZGIj4gDQogICAgICAgICAgPHRkIHdpZHRoPSI1NSIgaGVpZ2h0PSIyMSIgYmdjb2xvcj0i RkVERkJEIiBjbGFzcz0iZm9udDEiIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0iYm90dG9tIj67 58DMwe48L3RkPg0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjIxIiBiZ2NvbG9yPSIjRkZGRkZG IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0iZm9udDEiIHdpZHRoPSI0ODMiIHZhbGlnbj0iYm90 dG9tIj4NCiAgICAgICAgICAgIDxkaXYgYWxpZ249ImNlbnRlciI+NDY4ICogNjA8L2Rpdj4N CiAgICAgICAgICA8L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgICA8dHIgYmdjb2xvcj0i I0ZGRkZGRiIgYWxpZ249ImNlbnRlciI+IA0KICAgICAgICAgIDx0ZCBjb2xzcGFuPSIyIiBo ZWlnaHQ9IjQzIj4gDQogICAgICAgICAgICA8dGFibGUgd2lkdGg9IjUyMCIgYm9yZGVyPSIw IiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgICAgICAgICAgICA8dHI+ IA0KICAgICAgICAgICAgICAgIDx0ZD4NCiAgICAgICAgICAgICAgICAgIDxkaXYgYWxpZ249 ImNlbnRlciI+PGZvbnQgc2l6ZT0iMiI+wNq9xcDHIMPrx+K067fOILDxtvO6vLz2IMDWtMIg vd+87iAhISAnucy8urPiwNrAxyC81cDMILTqwfYgvsq0wiCw9ye/oSANCiAgICAgICAgICAg ICAgICAgICAgsLPA58fYIMHWvLy/5F5eOzwvZm9udD48L2Rpdj4NCiAgICAgICAgICAgICAg ICA8L3RkPg0KICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgPC90YWJsZT4NCiAg ICAgICAgICA8L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgPC90YWJsZT4NCiAgICAgIDx0 YWJsZSB3aWR0aD0iNTk2IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGlu Zz0iMCI+DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkIGhlaWdodD0iNCI+PC90ZD4N CiAgICAgICAgPC90cj4NCiAgICAgIDwvdGFibGU+DQogICAgICA8dGFibGUgd2lkdGg9IjUz OCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMSIgY2VsbHBhZGRpbmc9IjAiIGJnY29sb3I9 IjRiNGI0YiI+DQogICAgICAgIDx0ciBiZ2NvbG9yPSIjRkZGRkZGIiBhbGlnbj0iY2VudGVy Ij4gDQogICAgICAgICAgPHRkIGhlaWdodD0iNzAiIGNvbHNwYW49IjIiPjxhIGhyZWY9Imh0 dHA6Ly93d3cuc3NhbmdzaG93LmNvLmtyIj48aW1nIHNyYz0iaHR0cDovL3d3dy5zc2FuZ3No b3cuY28ua3IvaW1hZ2VzL2Jhbm5lci9iYW5uZXI2LmdpZiIgd2lkdGg9IjQ2OCIgaGVpZ2h0 PSI2MCIgYm9yZGVyPSIwIj48L2E+PC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgICAgPHRy IGJnY29sb3I9IiNGRkZGRkYiPiANCiAgICAgICAgICA8dGQgd2lkdGg9IjU1IiBoZWlnaHQ9 IjIxIiBiZ2NvbG9yPSJGRURGQkQiIGNsYXNzPSJmb250MSIgYWxpZ249ImNlbnRlciIgdmFs aWduPSJib3R0b20iPrvnwMzB7jwvdGQ+DQogICAgICAgICAgPHRkIGhlaWdodD0iMjEiIGJn Y29sb3I9IiNGRkZGRkYiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSJmb250MSIgd2lkdGg9IjQ4 MyIgdmFsaWduPSJib3R0b20iPjQ2OCANCiAgICAgICAgICAgICogNjA8L3RkPg0KICAgICAg ICA8L3RyPg0KICAgICAgICA8dHIgYmdjb2xvcj0iI0ZGRkZGRiIgYWxpZ249ImNlbnRlciI+ IA0KICAgICAgICAgIDx0ZCBjb2xzcGFuPSIyIiBoZWlnaHQ9IjQzIj4gDQogICAgICAgICAg ICA8dGFibGUgd2lkdGg9IjUyMCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBh ZGRpbmc9IjAiPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgIDx0ZD4N CiAgICAgICAgICAgICAgICAgIDxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgc2l6ZT0iMiI+ J8GmtOu3ziDC78DaJ7bztMIguPDF5MDHILqjs8q/oSDAzLn4IL3fvO7AxyDAzLqlxq64piDD 37Chx9Egs7u/6zwvZm9udD48L2Rpdj4NCiAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAg ICAgICAgICA8L3RyPg0KICAgICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgICA8L3RkPg0K ICAgICAgICA8L3RyPg0KICAgICAgPC90YWJsZT4NCiAgICAgIDx0YWJsZSB3aWR0aD0iNTk2 IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAg IDx0cj4gDQogICAgICAgICAgPHRkIGhlaWdodD0iOCI+PC90ZD4NCiAgICAgICAgPC90cj4N CiAgICAgIDwvdGFibGU+DQogICAgICA8dGFibGUgd2lkdGg9IjUwOCIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgICAgICA8dHI+DQogICAgICAg ICAgPHRkIHdpZHRoPSIxOCIgdmFsaWduPSJ0b3AiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnNz YW5nc2hvdy5jby5rci9wYXJ0bmVybWFpbC8wNjE1L2ltYWdlcy9hcnJvdy5naWYiIHdpZHRo PSIxOCIgaGVpZ2h0PSIxMSI+PC90ZD4NCiAgICAgICAgICA8dGQ+PGZvbnQgc2l6ZT0iMiI+ u+fAzMauuKYgv+6/tcfPvcO46bytILz2wM3AuyC+8sC4vcOw7SC9zcC4vcq0z7HuPyC937zu sKEgtbW/zSC15biusNq9wLTPtNkuPGJyPg0KICAgICAgICAgICAgw9a068fRIMbExq6zyrfO ILXut8/Hz73FIMi4v/i01LXpwLsgwKfH2LytIL+tvcnI9yDHz7DavcC0z7TZLiC937zuwMcg s/S+xsH4IMS/ucy8x7D6PGJyPg0KICAgICAgICAgICAgvd+87sDHILrqt6O15bimIMfRufgg udC+7iDB1r3KvcO/5C4gvLq9ybKvIMDPx8+w2r3AtM+02S48YnI+DQogICAgICAgICAgICA8 YnI+yLi/+CDAzsGkseKwo8DMIDMwwM+3ziC1x776vcC0z7TZLiAgPGEgaHJlZj0iaHR0cDov L3NzYW5nc2hvdy5saW5rcHJpY2UuY29tIj6h2qHaIDxmb250IGNvbG9yPSJGRjAwMDAiPsDM wPwgxsTGrrPKILvnwMzGrrTCIMDMsPe/oSCwoby8v+QuPC9mb250PiCh2qHaPC9hPjxicj4N CiAgICAgICAgICAgIMDMwPwgxsTGrrPKILvnwMzGrrTCILqvtb+758fXwMwgvvi9wLTPtNku IDxicj4NCiAgICAgICAgICAgIMDMwaYgyLi/+LTUsPogvd+87rTCILChwLvAuyDB2Lrxx9i+ 3yC1y7TPtNkuILLAIL3fvO7AxyC6o7PKuKYgtN6+xsHWvLy/5C5eXiA8YnI+PGI+R29vZCBs dWNrITwvYj48L2ZvbnQ+PC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgIDwvdGFibGU+DQog ICAgICA8dGFibGUgd2lkdGg9IjU5NiIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiPg0KICAgICAgICA8dHI+IA0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjE1 Ij48L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgPC90YWJsZT4NCiAgICAgIDx0YWJsZSB3 aWR0aD0iNTM4IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+ DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkPjxpbWcgc3JjPSJodHRwOi8vd3d3LnNz YW5nc2hvdy5jby5rci9wYXJ0bmVybWFpbC8wNjE1L2ltYWdlcy9tZW51LTMuZ2lmIiB3aWR0 aD0iMzE2IiBoZWlnaHQ9IjIwIj48L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgPC90YWJs ZT4NCiAgICAgIDx0YWJsZSB3aWR0aD0iNTk2IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIw IiBjZWxscGFkZGluZz0iMCI+DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkIGhlaWdo dD0iMTAiPjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICA8L3RhYmxlPg0KICAgICAgPHRh YmxlIHdpZHRoPSI1MzgiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n PSIwIj4NCiAgICAgICAgPHRyPiANCiAgICAgICAgICA8dGQgd2lkdGg9IjIwIiBoZWlnaHQ9 IjE5Ij4mbmJzcDs8L3RkPg0KICAgICAgICAgIDx0ZCB3aWR0aD0iMTEiIGhlaWdodD0iMTki PjxpbWcgc3JjPSJodHRwOi8vd3d3LnNzYW5nc2hvdy5jby5rci9wYXJ0bmVybWFpbC8wNjE1 L2ltYWdlcy9pY29uLmdpZiIgd2lkdGg9IjExIiBoZWlnaHQ9IjYiPjwvdGQ+DQogICAgICAg ICAgPHRkIGhlaWdodD0iMTkiIGNsYXNzPSJmb250MSI+PGI+PGZvbnQgc2l6ZT0iMiI+xsTG rrPKILChwNQgua7AxzwvYj4gOiA8YSBocmVmPW1haWx0bzpwYXJ0bmVyQHNzaG93LmNvLmty PnBhcnRuZXJAc3Nob3cuY28ua3I8L2E+PC9mb250PjwvdGQ+DQogICAgICAgIDwvdHI+DQog ICAgICA8L3RhYmxlPg0KICAgICAgPHRhYmxlIHdpZHRoPSI1OTYiIGJvcmRlcj0iMCIgY2Vs bHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgICAgICAgPHRyPiANCiAgICAgICAg ICA8dGQgaGVpZ2h0PSIxNSI+PC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgIDwvdGFibGU+ DQogICAgICA8dGFibGUgd2lkdGg9IjU5NiIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIg Y2VsbHBhZGRpbmc9IjAiPg0KICAgICAgICA8dHI+IA0KICAgICAgICAgIDx0ZCBoZWlnaHQ9 IjE5IiBiZ2NvbG9yPSJENEQ0RDQiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSJmb250IiB2YWxp Z249ImJvdHRvbSI+PGZvbnQgY29sb3I9IjRiNGI0YiIgY2xhc3M9ImZvbnQxIiBzaXplPSIy Ij4NCiAgICAgICAgICAgx+Owob74wMwguN7Az8C7ILq4s7u15bfBIMHLvNvH1bTPtNkuILHN x8/AxyC758DMxq6/oSDHyr/kx9EguqOzyrChILXHvvrAuLjpILnZtvi0z7TZLjwvZm9udD48 L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgPC90YWJsZT4NCiAgICAgIA0KICAgIDwvdGQ+ DQogIDwvdHI+DQo8L3RhYmxlPg0KPHRhYmxlIHdpZHRoPSI2MDAiIGJvcmRlcj0iMCIgY2Vs bHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0iY2VudGVyIj4NCiAgPHRyPg0K ICAgIDx0ZCB3aWR0aD0iMTAiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnNzYW5nc2hvdy5jby5r ci9wYXJ0bmVybWFpbC8wNjE1L2ltYWdlcy9pbWctMy5naWYiIHdpZHRoPSIxMCIgaGVpZ2h0 PSIyMSI+PC90ZD4NCiAgICA8dGQgd2lkdGg9IjU4MCIgYmdjb2xvcj0iNEI0QjRCIiBhbGln bj0iY2VudGVyIj48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiIgY2xhc3M9ImZvbnQx Ij5Db3B5cmlnaHQgDQogICAgICCozyAyMDAwLTIwMDEuIFNzYW5nc2hvdy5jby5rciBDby4s THRkLiBBbGwgcmlnaHRzIHJlc2VydmVkLjwvZm9udD48L3RkPg0KICAgIDx0ZCB3aWR0aD0i MTAiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnNzYW5nc2hvdy5jby5rci9wYXJ0bmVybWFpbC8w NjE1L2ltYWdlcy9pbWctNC5naWYiIHdpZHRoPSIxMCIgaGVpZ2h0PSIyMSI+PC90ZD4NCiAg PC90cj4NCjwvdGFibGU+DQo8dGFibGUgd2lkdGg9IjYwMCIgYm9yZGVyPSIwIiBjZWxsc3Bh Y2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJjZW50ZXIiPg0KICA8dHI+DQogICAg PHRkIGhlaWdodD0iMTAiPjwvdGQ+DQogIDwvdHI+DQo8L3RhYmxlPjwvZm9udD4NCjwvQk9E WT4NCjwvSFRNTD4= ------=_NextPart_000_0007_01C0F10A.93A49C00-- From owner-linux-xfs@oss.sgi.com Thu Aug 9 08:52:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Fqmn12719 for linux-xfs-outgoing; Thu, 9 Aug 2001 08:52:48 -0700 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 f79FqjV12688 for ; Thu, 9 Aug 2001 08:52:45 -0700 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 11:52:01 -0400 Message-ID: <23D04BDBA646D411BDDD00D0B774B5390460250A@SA-BWMAIL1> From: "Christian, Chip" To: "'NFS list (E-mail)'" , "Linux XFS (E-mail)" Subject: RE: [NFS] kernel nfsd crash Date: Thu, 9 Aug 2001 11:51:51 -0400 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 Replying to myself one last time... Ran through the stack trace, and sure enough, dput() kills us when it's called twice in a row with the same dentry. Here's the appropriate fix. Of course the open question is still how this directory wound up without a .., but at least NFS continues. --- nfsfh.c 2001/05/09 00:54:56 1.1 +++ nfsfh.c 2001/05/09 00:56:01 @@ -244,6 +244,10 @@ */ pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); d_drop(tdentry); /* we never want ".." hashed */ + if (!pdentry && tdentry->d_inode == NULL) { + dput(tdentry); + pdentry = ERR_PTR(-EINVAL); ==> + return() + } if (!pdentry) { /* I don't want to return a ".." dentry. * I would prefer to return an unconnected "IS_ROOT" dentry, -----Original Message----- From: Christian, Chip [mailto:chip.christian@storageapps.com] Sent: Tuesday, August 07, 2001 22:58 To: 'NFS list (E-mail)' Subject: RE: [NFS] kernel nfsd crash Sorry to keep responding to myself... The code as it is right now will do this: dput(tdentry); pdentry = ERR_PTR(-EINVAL); if (!pdentry) {} dput(tdentry); return(pdentry); Is it somehow screwing us up to call dput() twice like that? -----Original Message----- From: Christian, Chip Sent: Tuesday, August 07, 2001 22:43 To: Christian, Chip; NFS list (E-mail) Subject: RE: [NFS] kernel nfsd crash I don't get an oops, but knfsd surely does stop. It's happened to two different servers now, as well. And, by the way, this patch has already been applied 2.4.3 by RedHat: http://uwsg.iu.edu/hypermail/linux/kernel/0105.1/0135.html --- nfsfh.c 2001/05/09 00:54:56 1.1 +++ nfsfh.c 2001/05/09 00:56:01 @@ -244,6 +244,10 @@ */ pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); d_drop(tdentry); /* we never want ".." hashed */ + if (!pdentry && tdentry->d_inode == NULL) { + dput(tdentry); + pdentry = ERR_PTR(-EINVAL); + } if (!pdentry) { /* I don't want to return a ".." dentry. * I would prefer to return an unconnected "IS_ROOT" dentry, -----Original Message----- From: Christian, Chip [mailto:chip.christian@storageapps.com] Sent: Tuesday, August 07, 2001 16:04 To: NFS list (E-mail) Subject: [NFS] kernel nfsd crash All, I had the following occur at a client site. This is on 2.4.3-SGI_XFS_1.0.1 #1 SMP, i686, RedHat Linux 7.1. Any clues as to possible causes? Any more info I should collect? Thanks. -Chip Aug 6 11:15:50 nas1 kernel: invalid operand: 0000 Aug 6 11:15:50 nas1 kernel: CPU: 0 Aug 6 11:15:50 nas1 kernel: EIP: 0010:[dput+23/368] Aug 6 11:15:50 nas1 kernel: EIP: 0010:[<80145017>] Aug 6 11:15:50 nas1 kernel: EFLAGS: 00010246 Aug 6 11:15:50 nas1 kernel: eax: 00000000 ebx: 8908a8a0 ecx: 8908a920 edx: 8908a8a0 Aug 6 11:15:50 nas1 kernel: esi: 8908a8a0 edi: 8908a920 ebp: 8908a920 esp: 8e0bbebc Aug 6 11:15:50 nas1 kernel: ds: 0018 es: 0018 ss: 0018 Aug 6 11:15:50 nas1 kernel: Process nfsd (pid: 24239, stackpage=8e0bb000) Aug 6 11:15:50 nas1 kernel: Stack: 00000007 8908a920 8908a8a0 8908a920 ffffffea 8908a8a0 80177ed8 8908a8a0 Aug 6 11:15:50 nas1 kernel: 00400080 00000000 80178276 8908a920 87dcb078 ffffff8c 00000000 00400080 Aug 6 11:15:50 nas1 kernel: 00000000 8efef004 8cade800 80178633 8e3a4400 00400080 00000000 00000000 Aug 6 11:15:50 nas1 kernel: Call Trace: [nfsd_findparent+248/256] [find_fh_dentry+566/896] [fh_verify+627/1200] [nfsd3_proc_getattr+151/176] [nfsd_dispatch+193/352] Aug 6 11:15:50 nas1 kernel: Call Trace: [<80177ed8>] [<80178276>] [<80178633>][<8017e627>] [<801764a1>] Aug 6 11:15:50 nas1 kernel: [svc_process+851/1248] [nfsd+505/800] [kernel_thread+38/48] [nfsd+0/800] Aug 6 11:15:50 nas1 kernel: [<80297ff3>] [<801762b9>] [<801055a6>] [<801760c0>] Aug 6 11:15:50 nas1 kernel: Aug 6 11:15:50 nas1 kernel: Code: 0f 0b 68 d8 14 30 80 53 e8 9c 64 15 00 5e 85c0 5a 0f 84 34 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/nfs _______________________________________________ NFS maillist - NFS@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/nfs From owner-linux-xfs@oss.sgi.com Thu Aug 9 08:56:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79FuLD13184 for linux-xfs-outgoing; Thu, 9 Aug 2001 08:56:21 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79FuJV13159 for ; Thu, 9 Aug 2001 08:56:19 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id E3885C00FB4 for ; Thu, 9 Aug 2001 23:56:11 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 853BBC00FB3 for ; Thu, 9 Aug 2001 23:56:10 +0800 (PHT) Date: Thu, 9 Aug 2001 23:56:10 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: 3ware driver and XFS kernel from SGI In-Reply-To: <3B72A5C9.C6178CF9@fnal.gov> 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 Thu, 9 Aug 2001 at 10:01, yocum@fnal.gov wrote: > Does anyone have the latest 3ware driver (> v1.02.00.006) working in > any of the XFS patched kernels from SGI (cvs or rpm)? When I do an > insmod of the module, it locks up the system tight with the error "NMI > watchdog detected lockup on CPU 1" (or CPU 0, depending on what mood > it's in) and I don't seem to have the option of compiling it directly > into the kernel, for some strange reason. I am using a snapshot of the XFS CVS when it was still 2.4.7-xfs. That version of the kernel comes with the 1.02.00.007 3ware driver. I have NMI watchdog enabled, too, but have not run into this error at all. But then I don't load my 3ware driver as a module, since I need it at bootup. Why can't you compile the 3ware driver with the kernel? Wierd. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 9 09:08:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79G89W14222 for linux-xfs-outgoing; Thu, 9 Aug 2001 09:08:09 -0700 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 f79G87V14203 for ; Thu, 9 Aug 2001 09:08:07 -0700 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 GHT67800.OF0 for ; Thu, 9 Aug 2001 12:09:08 -0400 Message-ID: <3B72B565.2A797F51@umbi.umd.edu> Date: Thu, 09 Aug 2001 12:08:05 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: unable to open initial console References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk For the record, here is the fix that I used: 1. make gnutar of /dev from RH 7.1 system without devfs and with correct entries 2. copy tar to affected system 3. boot off the CD or boot.img floppy disk with "linux rescue" 4. untar the dev tar in the root tree 5. exit and reboot 6. for good measure "rpm -i --force" the dev rpm When I booted off the CD, sure enough, I found that /dev was essentially empty. I don't think just mknod for the /dev/console will work because you're also going to need the /dev/sdXX or /dev/hdXX entries so that mounting filesystems will work. It might be possible to write a short script to create just the necessary dev inodes to get the system back up, but I don't care enough about it to spend time on it. Another approach would be to "rpm -i --force" the dev rpm from the rescue console chrooted to the root partition. I don't think using relocate is a good idea because there may be symbolic links in /dev that get broken. -- "Jonathan F. Dill" (dill@umbi.umd.edu) CARB Systems and Network Administrator Home Page: http://www.umbi.umd.edu/~dill From owner-linux-xfs@oss.sgi.com Thu Aug 9 09:16:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79GGHk14496 for linux-xfs-outgoing; Thu, 9 Aug 2001 09:16:17 -0700 Received: from imapserver2.fnal.gov (imapserver2.fnal.gov [131.225.9.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79GGFV14477 for ; Thu, 9 Aug 2001 09:16:15 -0700 Received: from imapserver2.fnal.gov ([131.225.9.7]) by imapserver2.fnal.gov (Netscape Messaging Server 3.62) with SMTP id 1299 for ; Thu, 9 Aug 2001 11:16:14 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserver2.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001080911161432168 ; Thu, 09 Aug 2001 11:16:14 -0500 Message-ID: <3B72B810.B0AECC3D@fnal.gov> Date: Thu, 09 Aug 2001 11:19:28 -0500 From: yocum@fnal.gov 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: Federico Sevilla III CC: Linux XFS Mailing List Subject: Re: 3ware driver and XFS kernel from SGI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III wrote: > > On Thu, 9 Aug 2001 at 10:01, yocum@fnal.gov wrote: > > Does anyone have the latest 3ware driver (> v1.02.00.006) working in > > any of the XFS patched kernels from SGI (cvs or rpm)? When I do an > > insmod of the module, it locks up the system tight with the error "NMI > > watchdog detected lockup on CPU 1" (or CPU 0, depending on what mood > > it's in) and I don't seem to have the option of compiling it directly > > into the kernel, for some strange reason. > > I am using a snapshot of the XFS CVS when it was still 2.4.7-xfs. That > version of the kernel comes with the 1.02.00.007 3ware driver. I have NMI > watchdog enabled, too, but have not run into this error at all. But then I > don't load my 3ware driver as a module, since I need it at bootup. Why > can't you compile the 3ware driver with the kernel? Wierd. I just got done doing that and it still dumped me into kdb. I'm about to hook this machine up to a serial console so I can grab the stack traces. Do you have a SMP machine? What mobo? 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 Aug 9 09:18:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79GIrc14656 for linux-xfs-outgoing; Thu, 9 Aug 2001 09:18:53 -0700 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 f79GIoV14635 for ; Thu, 9 Aug 2001 09:18:50 -0700 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 f79GOLW06821 for ; Thu, 9 Aug 2001 09:24:21 -0700 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 LAA2671520; Thu, 9 Aug 2001 11:17:29 -0500 (CDT) Received: from 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 LAA67829; Thu, 9 Aug 2001 11:17:29 -0500 (CDT) Message-ID: <3B72B6C7.993C64A9@sgi.com> Date: Thu, 09 Aug 2001 11:13:59 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Dill CC: linux-xfs@oss.sgi.com Subject: Re: unable to open initial console References: <3B72B565.2A797F51@umbi.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jonathan Dill wrote: > When I booted off the CD, sure enough, I found that /dev was essentially > empty. Was this literally /dev, or /mnt/sysimage/dev? When you boot from the CD, your actual system root is not "/". The root of the rescue environment does have a very stripped down (nonexistant?) /dev. -Eric From owner-linux-xfs@oss.sgi.com Thu Aug 9 09:44:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79GiPT15298 for linux-xfs-outgoing; Thu, 9 Aug 2001 09:44:25 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79GiMV15279 for ; Thu, 9 Aug 2001 09:44:22 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA18396; Thu, 9 Aug 2001 18:44:01 +0200 (CEST) Message-Id: <4.3.2.7.2.20010809163227.0333b8f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Aug 2001 18:43:34 +0200 To: Federico Sevilla III , Linux XFS Mailing List From: Seth Mos Subject: Re: bdflush (was: corrupt inode) In-Reply-To: References: <3B7296F9.E1FAB9CA@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 22:13 9-8-2001 +0800, Federico Sevilla III wrote: >On Thu, 9 Aug 2001 at 08:58, yocum@fnal.gov wrote: > > Nope. If the machine dies while there's still data in the buffer (in > > local memory cache) that data is gone. > >And it's possible to get files filled with binary zeroes, which is >explained in the FAQ. Right? Explanation will follow soon, a bit tied up at the moment. Tonight perhaps. >I am still unclear as to whether the actions of bdflush are equivalent to >those of sync, though, at least with XFS. (I am not sure whether this is >filesystem-specific or not) I don't think defining it per filesystem would be efficient. I guess this goes for all filesystems >Also: let's say I modify a small file, then leave the system active for 30 >seconds. Theoretically that means the data would have been flushed to disk >already, right? It does on my system. > Assuming write cache is turned off, of course. Then will >turning off the machine (or it dying for some reason) cause a file filled >with binary zeroes? No, it will only do that if the program in question would actually truncate the file IIRC. > It shouldn't, at least by my limited understanding. I >hope I am correct. A email spool would probably not be affected since those programs are a lot more secure in making sure that the data goes to disk. http://marc.theaimsgroup.com/?l=linux-xfs&m=99535721114156&w=4 vi -r Seems to be the right way to do it. Pico does not exhibit this problem, better yet it seems this clients calls a sync after saving and exiting. I was real fast but it got it's data to disk. So i would say this is a "safe" editor ;-) The journaling fs is not to blame, it does it's work correctly. The application needs to have some form of modern day filesystems. Does anybody have a ReiserFS or JFS filesystem to test this with? I also tried this trick with vi and sure thing the file got filled with nulls. Somebody should patch vi to have a "fsync" operation mode. Otherwise you should put an alias in your .profile like: alias vi='vi -r' Or something resembling that. 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 Aug 9 10:07:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79H7Zx15813 for linux-xfs-outgoing; Thu, 9 Aug 2001 10:07:35 -0700 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 f79H7XV15794 for ; Thu, 9 Aug 2001 10:07:33 -0700 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 GHT8YA00.BGS; Thu, 9 Aug 2001 13:08:34 -0400 Message-ID: <3B72C353.E2A38B43@umbi.umd.edu> Date: Thu, 09 Aug 2001 13:07:31 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: unable to open initial console References: <3B72B565.2A797F51@umbi.umd.edu> <3B72B6C7.993C64A9@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, It was /mnt/sysimage/dev. I think it was my fault, because in both cases I used "rsync -avx" to relocate the root partition to a different disk, but since on devfs /dev is on a separate virtual filesystem, the "-x" option prevented rsync from copying over the /dev directory, and I did not do that separately. Eric Sandeen wrote: > Was this literally /dev, or /mnt/sysimage/dev? When you boot from the > CD, your actual system root is not "/". -- "Jonathan F. Dill" (dill@umbi.umd.edu) CARB Systems and Network Administrator Home Page: http://www.umbi.umd.edu/~dill From owner-linux-xfs@oss.sgi.com Thu Aug 9 10:25:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79HPBI16136 for linux-xfs-outgoing; Thu, 9 Aug 2001 10:25:11 -0700 Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79HP9V16117 for ; Thu, 9 Aug 2001 10:25:09 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 15UtYR-000CKK-0V for linux-xfs@oss.sgi.com; Thu, 9 Aug 2001 18:25:07 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 6BFD827F1 for ; Thu, 9 Aug 2001 18:25:05 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id ED8E6125E6; Thu, 9 Aug 2001 18:25:04 +0100 (BST) Date: Thu, 9 Aug 2001 18:25:04 +0100 (BST) From: Keith Matthews Subject: Re[2]: bdflush (was: corrupt inode) To: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20010809163227.0333b8f8@pop.xs4all.nl> References: <3B7296F9.E1FAB9CA@fnal.gov>, <4.3.2.7.2.20010809163227.0333b8f8@pop.xs4all.nl> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010809172504.ED8E6125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f79HP9V16118 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 09 Aug 2001 18:43:34 +0200 Seth Mos > wrote: > The journaling fs is not to blame, it does it's work correctly. The > application needs to have some form of modern day filesystems. Does anybody > have a ReiserFS or JFS filesystem to test this with? I would say that JFS, ReiserFS and ext3 in metada-only mode will give substantially the same result. Only ext3 in full journalling mode will differ. -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Thu Aug 9 10:58:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Hwpp16640 for linux-xfs-outgoing; Thu, 9 Aug 2001 10:58:51 -0700 Received: from alpha.public.smithconcepts.com (alpha.public.smithconcepts.com [205.245.53.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79HwmV16621 for ; Thu, 9 Aug 2001 10:58:48 -0700 Received: from ieee.org (localhost.public.smithconcepts.com [127.0.0.1]) by alpha.public.smithconcepts.com (8.9.3/8.9.3) with ESMTP id OAA02935; Thu, 9 Aug 2001 14:15:53 -0400 Message-ID: <3B72CDB0.853C4F3B@ieee.org> Date: Thu, 09 Aug 2001 13:51:44 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: yocum@fnal.gov CC: linux ide , xfs-list Subject: Re: 3ware driver and XFS kernel from SGI (YAMTR) References: <3B72A5C9.C6178CF9@fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk yocum@fnal.gov wrote: > Hi all, > Does anyone have the latest 3ware driver (> v1.02.00.006) working in any of > the XFS patched kernels from SGI (cvs or rpm)? When I do an insmod of the > module, it locks up the system tight with the error "NMI watchdog detected > lockup on CPU 1" (or CPU 0, depending on what mood it's in) and I don't seem > to have the option of compiling it directly into the kernel, for some > strange reason. [ Appologize for the YAMTR, "yet another me too reply") ] I have a 3Ware 6200 (dual-80GB, 160GB usable RAID-0) in a single CPU Athlon system using the updated firmware and the driver in RedHat 7.1 release (updated 2.4.3 kernel in 7.1 update / also used by SGI XFS 1.0.1). 0 issues, and have used 3Ware 6200s in other systems (both RAID-0 and RAID-1). I was considering putting a 3Ware 6410 (quad-40GB) in a dual-CPU Celeron system using the updated firmware and the same driver/kernel. Should I be concerned (the BP6/dual-Cel466 w/768MB PC100 ECC memory has been rock solid with RedHat 6.2, kernel 2.2.18 w/Ext3) with this configuration -- RedHat 7.1 / SGI XFS 1.0.1? Is the 3Ware not recommended in dual-CPU systems at this time? And/Or is the XFS filesystem not? I'm still debating whether or not to use RAID-5 (for 120GB usable) or RAID-0+1 (for 80GB usable). Given the fact that (A) the RAID-5 write performance is lackluster (due to the lack of the memory requirements usually needed for RAID-5), (B) there has been questions on the 3Ware cards with RAID-5 (which was added in the 6000-series via firmware update, recently updated again), and (C) it's only giving me 40GB more in the end, I think I'm going to "play it safe" RAID-0+1 (aka RAID-10) instead of RAID-5 (which the 3Ware cards excel at in StorageReview.COM comparisons). As such, do you think 3Ware+XFS is safe as long as I stick with just RAID-10 on my dual-CPU? All the problems I've seen with 3Ware have been at the hands of RAID-5 -- although I haven't tried it with a dual-CPU system yet, let alone XFS on a dual-CPU. Comments, discussion (on or off-list), flames welcome. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer Absolute Value Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com From owner-linux-xfs@oss.sgi.com Thu Aug 9 11:39:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Idbo18609 for linux-xfs-outgoing; Thu, 9 Aug 2001 11:39:37 -0700 Received: from ente.berdmann.de (frnk-d5141a8a.dsl.mediaWays.net [213.20.26.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79IdZV18589 for ; Thu, 9 Aug 2001 11:39:35 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15UuiN-0005ub-00; Thu, 09 Aug 2001 20:39:27 +0200 Message-ID: <3B72D8DF.8B384A62@berdmann.de> Date: Thu, 09 Aug 2001 20:39:27 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Shanker Balan CC: XFS list Subject: Re: XFS / VmWare Compatibility References: <20010809123307.A3254@exocore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I now just need to fix the stupid locking complaint that VMware gives > out every time i start it from the XFS home partition. put in your .cfg # Locking on XFS host.FSSupportLocking1 = 0x58465342 From owner-linux-xfs@oss.sgi.com Thu Aug 9 12:02:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79J24F20495 for linux-xfs-outgoing; Thu, 9 Aug 2001 12:02:04 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79J22V20471 for ; Thu, 9 Aug 2001 12:02:02 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.4/8.11.4) id f79J1tJ19704 for linux-xfs@oss.sgi.com; Thu, 9 Aug 2001 15:01:55 -0400 Date: Thu, 9 Aug 2001 15:01:55 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: Re: XFS / VmWare Compatibility Message-ID: <20010809150155.A19697@wwweasel.geeksrus.net> References: <20010809123307.A3254@exocore.com> <3B72D8DF.8B384A62@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B72D8DF.8B384A62@berdmann.de>; from be@berdmann.de on Thu, Aug 09, 2001 at 08:39:27PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 08:39:27PM +0200, Bernhard R. Erdmann wrote: >> I now just need to fix the stupid locking complaint that VMware gives >> out every time i start it from the XFS home partition. > >put in your .cfg ># Locking on XFS >host.FSSupportLocking1 = 0x58465342 I've tried this and it didn't work. For a release build, I've got build 1142. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Thu Aug 9 12:41:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Jfx424076 for linux-xfs-outgoing; Thu, 9 Aug 2001 12:41:59 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79JfqV24048 for ; Thu, 9 Aug 2001 12:41:52 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA11126 for ; Thu, 9 Aug 2001 12:41:38 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2672701 for ; Thu, 9 Aug 2001 14:40:36 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA99564 for ; Thu, 9 Aug 2001 14:40:36 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f79Jdw203163; Thu, 9 Aug 2001 14:39:58 -0500 Message-Id: <200108091939.f79Jdw203163@jen.americas.sgi.com> Date: Thu, 9 Aug 2001 14:39:58 -0500 Subject: TAKE - merge up to 2.4.8-pre7 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, some of this may well be from previous kernel versions, it appears that our merges are not always catching everything they should. So this one included an audit of the differences, hopefully I got them all. Date: Thu Aug 9 12:36:15 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100471a linux/drivers/char/drm/radeon.h - 1.1 linux/drivers/char/drm/drm_ioctl.h - 1.1 linux/drivers/char/drm/tdfx.h - 1.1 linux/drivers/char/drm/r128.h - 1.1 linux/drivers/char/drm/mga_warp.c - 1.1 linux/drivers/char/drm/mga_ucode.h - 1.1 linux/drivers/char/drm/mga.h - 1.1 linux/drivers/char/drm/i810.h - 1.1 linux/drivers/char/drm/gamma.h - 1.1 linux/drivers/char/drm/ffb.h - 1.1 linux/drivers/char/drm/drm_vm.h - 1.1 linux/drivers/char/drm/drm_stub.h - 1.1 linux/drivers/char/drm/drm_scatter.h - 1.1 linux/drivers/char/drm/drm_proc.h - 1.1 linux/drivers/char/drm/drm_memory.h - 1.1 linux/drivers/char/drm/drm_lock.h - 1.1 linux/drivers/char/drm/drm_lists.h - 1.1 linux/drivers/char/drm/drm_init.h - 1.1 linux/drivers/char/drm/drm_fops.h - 1.1 linux/drivers/char/drm/drm_drv.h - 1.1 linux/drivers/char/drm/drm_drawable.h - 1.1 linux/drivers/char/drm/drm_dma.h - 1.1 linux/drivers/char/drm/drm_context.h - 1.1 linux/drivers/char/drm/drm_bufs.h - 1.1 linux/drivers/char/drm/drm_auth.h - 1.1 linux/drivers/char/drm/drm_agpsupport.h - 1.1 linux/drivers/char/drm/ati_pcigart.h - 1.1 linux/scripts/Menuconfig - 1.13 linux/net/unix/af_unix.c - 1.32 linux/net/sched/sch_cbq.c - 1.11 linux/net/sched/cls_u32.c - 1.6 linux/net/sched/cls_route.c - 1.5 linux/net/packet/af_packet.c - 1.25 linux/net/netsyms.c - 1.36 linux/net/ipv6/addrconf.c - 1.19 linux/net/ipv4/ip_output.c - 1.24 linux/net/ipv4/igmp.c - 1.15 linux/net/ipv4/icmp.c - 1.20 linux/net/ipv4/af_inet.c - 1.28 linux/net/core/sock.c - 1.22 linux/net/core/skbuff.c - 1.22 linux/net/core/rtnetlink.c - 1.9 linux/mm/vmscan.c - 1.67 linux/mm/page_alloc.c - 1.49 linux/lib/vsprintf.c - 1.12 linux/include/net/addrconf.h - 1.9 linux/include/linux/swap.h - 1.33 linux/include/linux/serial.h - 1.14 linux/include/linux/netdevice.h - 1.27 linux/include/linux/fs.h - 1.106 linux/include/linux/blkdev.h - 1.36 linux/include/asm-sparc64/mmu_context.h - 1.10 linux/include/asm-sparc/pgtable.h - 1.19 linux/include/asm-sparc/bitops.h - 1.12 linux/include/asm-i386/serial.h - 1.5 linux/fs/read_write.c - 1.15 linux/fs/buffer.c - 1.76 linux/drivers/video/cgfourteenfb.c - 1.9 linux/drivers/scsi/sd.c - 1.39 linux/drivers/scsi/qlogicfc.c - 1.19 linux/drivers/scsi/atp870u.c - 1.16 linux/drivers/scsi/aha152x.c - 1.22 linux/drivers/pci/quirks.c - 1.23 linux/drivers/net/sunhme.h - 1.11 linux/drivers/net/sunhme.c - 1.29 linux/drivers/net/ne2.c - 1.15 linux/drivers/net/hamradio/scc.c - 1.20 linux/drivers/isdn/isdn_tty.c - 1.15 linux/drivers/isdn/isdn_ppp.c - 1.17 linux/drivers/isdn/isdn_net.c - 1.22 linux/drivers/char/sysrq.c - 1.15 linux/drivers/char/serial.c - 1.45 linux/drivers/char/riscom8.c - 1.12 linux/drivers/char/nvram.c - 1.15 linux/drivers/block/floppy.c - 1.25 linux/arch/sparc64/mm/init.c - 1.27 linux/arch/sparc64/mm/extable.c - 1.4 linux/arch/sparc64/kernel/smp.c - 1.25 linux/arch/sparc64/kernel/ioctl32.c - 1.38 linux/arch/sparc64/defconfig - 1.43 linux/arch/sparc64/Makefile - 1.12 linux/arch/sparc/mm/fault.c - 1.16 linux/arch/sparc/mm/extable.c - 1.4 linux/arch/sparc/kernel/ebus.c - 1.11 linux/arch/sparc/Makefile - 1.10 linux/arch/i386/boot/setup.S - 1.22 linux/arch/i386/boot/Makefile - 1.11 linux/Makefile - 1.111 linux/MAINTAINERS - 1.67 linux/Documentation/video4linux/bttv/README - 1.14 linux/Documentation/pci.txt - 1.15 linux/drivers/isdn/hisax/cert.c - 1.6 linux/drivers/net/arlan.c - 1.19 linux/fs/partitions/check.c - 1.28 linux/drivers/isdn/hisax/hfc_pci.c - 1.18 linux/net/atm/common.c - 1.13 linux/drivers/block/DAC960.h - 1.9 linux/drivers/block/DAC960.c - 1.31 linux/drivers/net/pcmcia/3c589_cs.c - 1.18 linux/drivers/char/drm/vm.c - 1.8 linux/drivers/char/drm/proc.c - 1.9 linux/drivers/char/drm/memory.c - 1.7 linux/drivers/char/drm/lock.c - 1.7 linux/drivers/char/drm/lists.c - 1.7 linux/drivers/char/drm/ioctl.c - 1.7 linux/drivers/char/drm/init.c - 1.7 linux/drivers/char/drm/gamma_drv.h - 1.5 linux/drivers/char/drm/gamma_drv.c - 1.11 linux/drivers/char/drm/gamma_dma.c - 1.8 linux/drivers/char/drm/fops.c - 1.10 linux/drivers/char/drm/drmP.h - 1.12 linux/drivers/char/drm/drm.h - 1.8 linux/drivers/char/drm/drawable.c - 1.6 linux/drivers/char/drm/dma.c - 1.9 linux/drivers/char/drm/context.c - 1.7 linux/drivers/char/drm/bufs.c - 1.10 linux/drivers/char/drm/auth.c - 1.6 linux/drivers/char/drm/Makefile - 1.11 linux/drivers/net/tokenring/ibmtr.c - 1.17 linux/include/linux/pci_ids.h - 1.41 linux/drivers/net/pcmcia/3c574_cs.c - 1.16 linux/mm/highmem.c - 1.23 linux/drivers/net/sk98lin/skge.c - 1.15 linux/drivers/char/drm/tdfx_drv.h - 1.4 linux/drivers/char/drm/tdfx_drv.c - 1.9 linux/drivers/char/drm/tdfx_context.c - 1.5 linux/Documentation/video4linux/bttv/Sound-FAQ - 1.7 linux/Documentation/video4linux/bttv/CARDLIST - 1.11 linux/Documentation/video4linux/bttv/Insmod-options - 1.10 linux/drivers/usb/usbkbd.c - 1.17 linux/drivers/ieee1394/ieee1394_core.h - 1.7 linux/drivers/ieee1394/ieee1394_core.c - 1.12 linux/arch/i386/kernel/mpparse.c - 1.11 linux/drivers/char/mxser.c - 1.10 linux/drivers/net/tulip/tulip_core.c - 1.26 linux/drivers/ide/sis5513.c - 1.11 linux/net/ipv4/netfilter/ip_nat_proto_tcp.c - 1.3 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.10 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.8 linux/include/linux/ibmtr.h - 1.5 linux/fs/partitions/ibm.c - 1.6 linux/include/asm-s390/cache.h - 1.4 linux/drivers/s390/block/dasd_eckd.c - 1.6 linux/drivers/s390/block/dasd.c - 1.9 linux/drivers/s390/Config.in - 1.8 linux/drivers/s390/block/Makefile - 1.5 linux/net/ipv6/netfilter/ip6_tables.c - 1.7 linux/net/ipv6/netfilter/Makefile - 1.7 linux/arch/i386/kernel/msr.c - 1.10 linux/drivers/char/drm/r128_drv.h - 1.6 linux/drivers/char/drm/r128_drv.c - 1.6 linux/drivers/char/drm/r128_drm.h - 1.4 linux/drivers/char/drm/r128_context.c - 1.4 linux/drivers/char/drm/r128_bufs.c - 1.6 linux/drivers/char/drm/mga_state.c - 1.6 linux/drivers/char/drm/mga_drv.h - 1.6 linux/drivers/char/drm/mga_drv.c - 1.6 linux/drivers/char/drm/mga_drm.h - 1.3 linux/drivers/char/drm/mga_dma.c - 1.5 linux/drivers/char/drm/mga_context.c - 1.4 linux/drivers/char/drm/mga_bufs.c - 1.6 linux/drivers/char/drm/i810_drv.h - 1.2 linux/drivers/char/drm/i810_drv.c - 1.5 linux/drivers/char/drm/i810_drm.h - 1.2 linux/drivers/char/drm/i810_dma.c - 1.8 linux/drivers/char/drm/i810_context.c - 1.3 linux/drivers/char/drm/i810_bufs.c - 1.4 linux/drivers/char/drm/ffb_drv.c - 1.8 linux/drivers/char/drm/ffb_context.c - 1.3 linux/drivers/char/drm/ctxbitmap.c - 1.2 linux/drivers/char/drm/agpsupport.c - 1.6 linux/drivers/usb/storage/usb.h - 1.9 linux/drivers/usb/storage/usb.c - 1.11 linux/drivers/usb/storage/transport.h - 1.7 linux/drivers/usb/storage/transport.c - 1.10 linux/drivers/usb/storage/scsiglue.c - 1.11 linux/drivers/char/drm/Config.in - 1.4 linux/drivers/char/sbc60xxwdt.c - 1.8 linux/drivers/usb/storage/protocol.h - 1.4 linux/drivers/usb/storage/protocol.c - 1.6 linux/drivers/usb/storage/debug.c - 1.6 linux/drivers/net/tun.c - 1.9 linux/net/ipv4/tcp_minisocks.c - 1.6 linux/drivers/usb/storage/shuttle_usbat.c - 1.6 linux/drivers/usb/storage/sddr09.c - 1.7 linux/drivers/usb/storage/freecom.c - 1.6 linux/drivers/usb/storage/dpcm.c - 1.3 linux/drivers/media/video/tuner.h - 1.5 linux/drivers/media/video/tuner.c - 1.6 linux/drivers/media/video/tda7432.c - 1.6 linux/drivers/media/video/msp3400.c - 1.7 linux/drivers/media/video/bttv.h - 1.9 linux/drivers/media/video/bttv-driver.c - 1.12 linux/drivers/media/video/bttv-cards.c - 1.8 linux/drivers/media/video/bt848.h - 1.3 linux/drivers/media/radio/Makefile - 1.8 linux/drivers/media/radio/Config.in - 1.7 linux/drivers/scsi/cpqfc.Readme - 1.3 linux/drivers/scsi/cpqfcTS.h - 1.3 linux/drivers/scsi/cpqfcTScontrol.c - 1.5 linux/drivers/scsi/cpqfcTSinit.c - 1.9 linux/drivers/scsi/cpqfcTSstructs.h - 1.3 linux/drivers/scsi/cpqfcTSworker.c - 1.5 linux/drivers/media/video/tvaudio.c - 1.6 linux/drivers/media/video/bttvp.h - 1.5 linux/mm/shmem.c - 1.10 linux/drivers/char/drm/r128_state.c - 1.2 linux/drivers/char/drm/r128_cce.c - 1.2 linux/drivers/char/drm/radeon_bufs.c - 1.5 linux/drivers/char/drm/radeon_context.c - 1.2 linux/drivers/char/drm/radeon_cp.c - 1.2 linux/drivers/char/drm/radeon_drm.h - 1.2 linux/drivers/char/drm/radeon_drv.c - 1.2 linux/drivers/char/drm/radeon_drv.h - 1.2 linux/drivers/char/drm/radeon_state.c - 1.2 linux/drivers/usb/storage/unusual_devs.h - 1.4 linux/include/asm-s390/dasd.h - 1.5 linux/include/asm-s390x/dasd.h - 1.6 linux/include/asm-s390x/cache.h - 1.4 linux/drivers/s390/block/dasd_fba.h - 1.3 linux/drivers/s390/block/dasd_fba.c - 1.5 linux/drivers/s390/block/dasd_eckd.h - 1.4 linux/drivers/s390/block/dasd_diag.h - 1.3 linux/drivers/s390/block/dasd_diag.c - 1.5 linux/drivers/s390/block/dasd_9343_erp.c - 1.3 linux/drivers/s390/block/dasd_9336_erp.c - 1.3 linux/drivers/s390/block/dasd_3990_erp.h - 1.4 linux/drivers/s390/block/dasd_3990_erp.c - 1.4 linux/drivers/s390/block/dasd_3370_erp.c - 1.3 linux/drivers/net/pci-skeleton.c - 1.7 linux/drivers/scsi/aic7xxx/aic7xxx.c - 1.4 linux/drivers/net/sungem.c - 1.5 linux/drivers/s390/block/dasd_9343_erp.h - 1.3 linux/include/asm-s390/vtoc.h - 1.3 linux/include/asm-s390x/vtoc.h - 1.3 linux/drivers/net/irda/irda-usb.c - 1.3 linux/drivers/media/video/bt856.c - 1.3 linux/drivers/media/video/bt819.c - 1.3 linux/drivers/media/video/adv7175.c - 1.3 linux/drivers/net/irda/ali-ircc.c - 1.3 linux/drivers/net/sk98lin/skproc.c - 1.5 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.4 linux/drivers/scsi/pcmcia/nsp_cs.h - 1.4 linux/drivers/scsi/pcmcia/nsp_debug.c - 1.4 linux/drivers/scsi/pcmcia/nsp_io.h - 1.4 linux/drivers/video/aty/atyfb_base.c - 1.3 From owner-linux-xfs@oss.sgi.com Thu Aug 9 13:15:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79KF8426925 for linux-xfs-outgoing; Thu, 9 Aug 2001 13:15:08 -0700 Received: from chipsworld.llamas.net (IDENT:root@chipsworld.LLAMAS.net [63.77.33.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79KF6V26900 for ; Thu, 9 Aug 2001 13:15:07 -0700 Received: from localhost (chipper@localhost) by chipsworld.llamas.net (8.11.3/8.11.3) with ESMTP id f79KEfp18992; Thu, 9 Aug 2001 16:14:41 -0400 Date: Thu, 9 Aug 2001 16:14:40 -0400 (EDT) From: "Chris 'Chipper' Chiapusio" To: Alan Eldridge cc: SGI XFS Dev List Subject: Re: XFS / VmWare Compatibility In-Reply-To: <20010809150155.A19697@wwweasel.geeksrus.net> Message-ID: X-Files: Resist or serve MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk NOTE: not your guest-os.cfg file, your system-wide vmware config, which on my system (rpm installed vmware) lives in /etc/vmware/config Chipper On Thu, 9 Aug 2001, Alan Eldridge wrote: >On Thu, Aug 09, 2001 at 08:39:27PM +0200, Bernhard R. Erdmann wrote: >>> I now just need to fix the stupid locking complaint that VMware gives >>> out every time i start it from the XFS home partition. >> >>put in your .cfg >># Locking on XFS >>host.FSSupportLocking1 = 0x58465342 > >I've tried this and it didn't work. For a release build, I've got build 1142. > > ------ Please encrypt anything important. PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D From owner-linux-xfs@oss.sgi.com Thu Aug 9 13:31:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79KV7428362 for linux-xfs-outgoing; Thu, 9 Aug 2001 13:31:07 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79KV5V28339 for ; Thu, 9 Aug 2001 13:31:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA01203 for ; Thu, 9 Aug 2001 13:29:01 -0700 (PDT) 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 PAA2676649 for ; Thu, 9 Aug 2001 15:29:49 -0500 (CDT) 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 PAA64843 for ; Thu, 9 Aug 2001 15:29:49 -0500 (CDT) From: eric@sgi.com Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f79KQfx13012; Thu, 9 Aug 2001 15:26:41 -0500 Message-Id: <200108092026.f79KQfx13012@stout.americas.sgi.com> Date: Thu, 9 Aug 2001 15:26:41 -0500 Subject: TAKE - Fix xfsdump / xfs_open_by_handle umount problem Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A bug showed up where umount failed after xfsdump on a filesystem, due to a busy inode. xfsdump calls xfs_open_by_handle, which will allocate a new dentry if it doesn't find one already in the dcache. Problem is, this dentry isn't connected anywhere in the dcache, and it's holding a reference count on the inode... umount code tears down the dcache, but it never found this dentry, so its inode stayed busy. Removing the call to d_rehash solves this problem, since dput will just tear down unreachable dentrys when the file is closed. Also added DCACHE_REFERENCED flag to the newly created dcache. Date: Thu Aug 9 13:19:32 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100478a linux/fs/xfs/linux/xfs_ioctl.c - 1.44 - Add DCACHE_REFERENCED to dentry flags in xfs_open_by_handle. Don't call d_rehash on new dentry so that dput will tear it down. From owner-linux-xfs@oss.sgi.com Thu Aug 9 13:32:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79KWVc28564 for linux-xfs-outgoing; Thu, 9 Aug 2001 13:32:31 -0700 Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79KWTV28543 for ; Thu, 9 Aug 2001 13:32:29 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.9.3/8.9.3) id WAA20783; Thu, 9 Aug 2001 22:32:31 +0200 Date: Thu, 9 Aug 2001 22:32:30 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: xfsprogs support for > 1TB devices. Message-ID: <20010809223230.E9580@vestdata.no> References: <20010809030249.C9580@vestdata.no> <20010809114155.C260586@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <20010809114155.C260586@wobbly.melbourne.sgi.com>; from Nathan Scott on Thu, Aug 09, 2001 at 11:41:56AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 11:41:56AM +1000, Nathan Scott wrote: > > or maybe make it a unsigned long long right away.. > > There doesn't seem to be any point in doing that since the ioctl > returns an unsigned long (or have I missed something?). I think > your "unsigned long long" suggestion would cause an xfsprogs bug > on some 32bit platforms, no? Yes. Sorry, I was not thinking clearly. > Steve sent some mail discussing the size of XFS inode numbers in > bits a little while ago that will be of interest to you too (see > http://oss.sgi.com/projects/xfs/mail_archive/0107/msg00727.html). Yes, I know about that. Thanks. -- Ragnar Kjorstad Big Storage From owner-linux-xfs@oss.sgi.com Thu Aug 9 14:14:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79LElZ32407 for linux-xfs-outgoing; Thu, 9 Aug 2001 14:14:47 -0700 Received: from mustang.centralnet.ch (mustang.centralnet.ch [193.135.146.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79LEgV32380 for ; Thu, 9 Aug 2001 14:14:42 -0700 Received: from vollmann.ch (luz159.centralnet.ch [193.135.147.159]) by mustang.centralnet.ch (8.9.3/8.9.3) with ESMTP id XAA394650; Thu, 9 Aug 2001 23:14:31 +0200 (MES) Received: from two.vollmann.ch (localhost [127.0.0.1]) by vollmann.ch (8.8.6/8.8.5) with SMTP id VAA03795; Thu, 9 Aug 2001 21:07:41 GMT Message-ID: <3B72FB9D.22F2A4F2@vollmann.ch> Date: Thu, 09 Aug 2001 21:07:41 +0000 From: Detlef Vollmann Organization: vollmann engineering gmbh X-Mailer: Mozilla 3.04 (X11; U; Linux 2.2.14-5.0 i586) MIME-Version: 1.0 To: Nathan Scott CC: XFS list Subject: Re: Problems with mkfs.xfs References: <3B71F762.58CD4725@vollmann.ch> <20010809130928.D260586@wobbly.melbourne.sgi.com> <3B7209C0.1DDDE1DD@vollmann.ch> <20010809184544.L260586@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott wrote: > [btw, another thing I found with the rd driver is you'll need to > set the blocksize to 512 for XFS - it defaults to 1024, but this > is configurable] Unfortunately I can't reboot just from a test shell script :-( > I looked into this a bit more ... I got that minimum size from > the man page, so assumed it was right. Its not. On IRIX, I'm > able to create a 4MB filesystem (which is strange because IRIX > mkfs man page also documents 16MB as the minimum). To create a > filesystem this small, you need to use -linternal,size=512b > (thanks for the tip, Eric). > > Our Linux code goes south when I try to mount a 4MB filesystem > though - the log recovery code tries to write at a really big > offset and crashes and burns a bit after doing that. I'll look > into this a bit more tomorrow - it seems very strange (broken). I played a littlebit around with a loopback device (thanks, Steve) and various sizes. Here are some results (all on linux-2.4.3): [root@dwarf tmp]# dd if=/dev/zero of=disk.xfs bs=1024 count=4851 4851+0 records in 4851+0 records out [root@dwarf tmp]# mkfs -t xfs disk.xfs meta-data=disk.xfs isize=256 agcount=1, agsize=4096 blks data = bsize=4096 blocks=1212, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 Segmentation fault (core dumped) That core dump is absolutely reproducible, if the size of the file is big enough for the log (i.e. in the default case >= 4096K) but the remaining size is less than 13b). [root@dwarf tmp]# dd if=/dev/zero of=disk.xfs bs=1024 count=4852 4852+0 records in 4852+0 records out [root@dwarf tmp]# mkfs -t xfs disk.xfs meta-data=disk.xfs isize=256 agcount=1, agsize=4096 blks data = bsize=4096 blocks=1213, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 [root@dwarf tmp]# mount -t xfs -o loop disk.xfs /mount2 [root@dwarf tmp]# df /mount2 Filesystem 1k-blocks Used Available Use% Mounted on /var/tmp/disk.xfs 52 32 20 62% /mount2 So, this works fine :-) [root@dwarf tmp]# umount /mount2 [root@dwarf tmp]# dd if=/dev/zero of=disk.xfs bs=1024 count=2100 2100+0 records in 2100+0 records out [root@dwarf tmp]# mkfs -t xfs -l internal,size=512b disk.xfs meta-data=disk.xfs isize=256 agcount=1, agsize=4096 blks data = bsize=4096 blocks=525, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=512 realtime =none extsz=65536 blocks=0, rtextents=0 [root@dwarf tmp]# mount -t xfs -o loop disk.xfs /mount2 [root@dwarf tmp]# tail -2 /var/log/messages Aug 9 21:31:42 dwarf kernel: Start mounting filesystem: loop(7,0) Aug 9 21:31:42 dwarf kernel: Ending clean XFS mount for filesystem: loop(7,0) [root@dwarf tmp]# df /mount2 Filesystem 1k-blocks Used Available Use% Mounted on /var/tmp/disk.xfs 52 32 20 62% /mount2 This was the smallest xfs fs I was able to produce. Interestingly, if I put the log externally, the data size needs to be larger than 13b: [root@dwarf tmp]# umount /mount2 [root@dwarf tmp]# dd if=/dev/zero of=log.xfs bs=1024 count=2048 2048+0 records in 2048+0 records out [root@dwarf tmp]# dd if=/dev/zero of=disk.xfs bs=1024 count=52 52+0 records in 52+0 records out [root@dwarf tmp]# mkfs -t xfs -l logdev=log.xfs,size=512b disk.xfs size 13 of data subvolume is too small, minimum 100 blocks Strange, as 13 blocks are ok if the log is internal. [root@dwarf tmp]# dd if=/dev/zero of=disk.xfs bs=1024 count=400 400+0 records in 400+0 records out [root@dwarf tmp]# mkfs -t xfs -l logdev=log.xfs,size=512b disk.xfs meta-data=disk.xfs isize=256 agcount=1, agsize=4096 blks data = bsize=4096 blocks=100, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =log.xfs bsize=4096 blocks=512 realtime =none extsz=65536 blocks=0, rtextents=0 So far, fine. [root@dwarf tmp]# mount -t xfs -o loop,logdev=/var/tmp/log.xfs disk.xfs /mount2 mount: wrong fs type, bad option, bad superblock on /dev/loop0, or too many mounted file systems [root@dwarf tmp]# tail -3 /var/log/messages Aug 9 21:53:45 dwarf kernel: XFS: filesystem is marked as having an external log; specify logdev on the Aug 9 21:53:45 dwarf kernel: mount command line. Aug 9 21:53:45 dwarf kernel: XFS: SB validate failed The error message in the log is a bit misleading, but in general it's probably not too surprising not to be able to mount a log volume from a loopback device -- there is just no option for that. BTW, using a real block device with the same options works fine: [root@dwarf tmp]# mkfs -t xfs -l logdev=/dev/hda2,size=512b disk.xfs meta-data=disk.xfs isize=256 agcount=1, agsize=4096 blks data = bsize=4096 blocks=100, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =/dev/hda2 bsize=4096 blocks=512 realtime =none extsz=65536 blocks=0, rtextents=0 [root@dwarf tmp]# mount -t xfs -o loop,logdev=/dev/hda2 disk.xfs /mount2 [root@dwarf tmp]# df /mount2 Filesystem 1k-blocks Used Available Use% Mounted on /var/tmp/disk.xfs 400 32 368 8% /mount2 [root@dwarf tmp]# tail -2 /var/log/messages Aug 9 22:04:08 dwarf kernel: Start mounting filesystem: loop(7,0) Aug 9 22:04:08 dwarf kernel: Ending clean XFS mount for filesystem: loop(7,0) cheers, Detlef -- Detlef Vollmann vollmann engineering gmbh Tel: +41-41-4120911 P.O. Box 5106 Fax: +41-41-4120912 CH-6000 Luzern 5 / Switzerland eMail: dv@vollmann.ch From owner-linux-xfs@oss.sgi.com Thu Aug 9 14:21:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79LLsG00735 for linux-xfs-outgoing; Thu, 9 Aug 2001 14:21:54 -0700 Received: from imapserver2.fnal.gov (imapserver2.fnal.gov [131.225.9.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79LLqV00708 for ; Thu, 9 Aug 2001 14:21:52 -0700 Received: from imapserver2.fnal.gov ([131.225.9.7]) by imapserver2.fnal.gov (Netscape Messaging Server 3.62) with SMTP id 1641 for ; Thu, 9 Aug 2001 16:21:49 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserver2.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001080916214829358 ; Thu, 09 Aug 2001 16:21:48 -0500 Message-ID: <3B72FFB0.62550563@fnal.gov> Date: Thu, 09 Aug 2001 16:25:04 -0500 From: yocum@fnal.gov 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: linux ide , xfs-list , Tom Tran , linux@3ware.com CC: mingo@redhat.com Subject: Re: 3ware driver and XFS kernel from SGI References: <3B72A5C9.C6178CF9@fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk yocum@fnal.gov wrote: > > Hi all, > > Does anyone have the latest 3ware driver (> v1.02.00.006) working in any of > the XFS patched kernels from SGI (cvs or rpm)? When I do an insmod of the > module, it locks up the system tight with the error "NMI watchdog detected > LOCKUP on CPU 1, registers: ....." (or CPU 0, depending on what mood it's in) and I don't seem Well, I got around the problem by turning off the NMI_watchdog, which can be done at the LILO: prompt by adding nmi_watchdog=0. The system boots and the volumes on the 3ware cards are available. For some reason the latest 3ware drivers (>1.02.00.006) trick the watchdog into thinking that the CPU has locked up dropping me into kdb, when in fact it hasn't. I don't know if this is a bug in the 3ware driver or the nmi_watchdog. > to have the option of compiling it directly into the kernel, for some > strange reason. Uh, duh, yocum. Make sure you compile the base SCSI into the kernel as well - then I had no problem. ;-) 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 Aug 9 14:49:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79LnK904319 for linux-xfs-outgoing; Thu, 9 Aug 2001 14:49:20 -0700 Received: from sunspot.csun.edu (IDENT:mail@sunspot.csun.edu [130.166.114.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79LnHV04299 for ; Thu, 9 Aug 2001 14:49:18 -0700 Received: by sunspot.csun.edu (Postfix, from userid 201) id 5CAE33FE9; Thu, 9 Aug 2001 14:49:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sunspot.csun.edu (Postfix) with ESMTP id 5C1121D74F; Thu, 9 Aug 2001 14:49:17 -0700 (PDT) Date: Thu, 9 Aug 2001 14:49:17 -0700 (PDT) From: Stephen Walton Reply-To: To: "Christian, Chip" Cc: "'NFS list (E-mail)'" , "Linux XFS (E-mail)" Subject: RE: [NFS] kernel nfsd crash In-Reply-To: <23D04BDBA646D411BDDD00D0B774B5390460250A@SA-BWMAIL1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 9 Aug 2001, Christian, Chip wrote: > --- nfsfh.c 2001/05/09 00:54:56 1.1 > +++ nfsfh.c 2001/05/09 00:56:01 > @@ -244,6 +244,10 @@ > */ > pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); > d_drop(tdentry); /* we never want ".." hashed */ > + if (!pdentry && tdentry->d_inode == NULL) { > + dput(tdentry); > + pdentry = ERR_PTR(-EINVAL); > ==> + return() > + } Wouldn't this be simpler: if (!pdentry && tdentry->d_inode == NULL) { dput(tdentry); return ERRPTR(-EINVAL); } ---- Stephen Walton, Professor of Physics and Astronomy, California State University, Northridge stephen.walton@csun.edu From owner-linux-xfs@oss.sgi.com Thu Aug 9 15:15:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79MF1H08009 for linux-xfs-outgoing; Thu, 9 Aug 2001 15:15:01 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79MEwV07983 for ; Thu, 9 Aug 2001 15:14:58 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 17:14:13 -0500 Message-ID: <85063BBE668FD411944400D0B744267A643686@AUSMAIL> From: "Gonyou, Austin" To: "Linux XFS (E-mail)" Subject: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer Date: Thu, 9 Aug 2001 17:14:12 -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 Currently on my desktop, this works fine for installing with no real modifications etc. But, on 2 scsi systems, The ./runInstaller will segfault several hundred times a second and the cpu utilization is at 99.8% on 1 of the CPUs. Any information in this regard to get it to work on an SMP setup would be very helpful. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Thu Aug 9 16:29:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79NToQ17927 for linux-xfs-outgoing; Thu, 9 Aug 2001 16:29:50 -0700 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 f79NTlV17900 for ; Thu, 9 Aug 2001 16:29:47 -0700 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 f79NZGW29829 for ; Thu, 9 Aug 2001 16:35:17 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA21885; Fri, 10 Aug 2001 09:28:23 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA64272; Fri, 10 Aug 2001 09:28:20 +1000 (AEST) Date: Fri, 10 Aug 2001 09:28:19 +1000 From: Nathan Scott To: Juer Lee Cc: Jan Kara , linux-xfs@oss.sgi.com Subject: Re: Quota - grace Message-ID: <20010810092819.A279562@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Juer.Lee@raidtec.ie on Thu, Aug 09, 2001 at 11:06:42AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, [cc: Jan so he knows about this issue, cc: linux-xfs so anyone else coming across this powerpc build issue will find some answers here] On Thu, Aug 09, 2001 at 11:06:42AM +0100, Juer Lee wrote: > Nathan, > > Thanks. > I downloaded quota-tools-3.01-pre8 two weeks ago. But I failed compiling > it on my Suse Linux7.1 PPC. > ... > Do I need some other package to compile it? It seemed that my system is > lack of some header file. > > When compiling : > > cc -DBSD_BEHAVIOUR -DRPC_SETQUOTA -DRPC -DALT_FORMAT -g -O2 > -DEXT2_DIRECT -D_GNU_SOURCE -Wall -D_LARGEFILE64_SOURCE -DHOSTS_ACCESS > -DQUOTA_VERSION=\"3.01\" -c -o quotacheck.o quotacheck.c > quotacheck.c:180: parse error before `umode_t' > quotacheck.c: In function `add_to_quota': > quotacheck.c:186: `type' undeclared (first use in this function) > quotacheck.c:186: (Each undeclared identifier is reported only once > quotacheck.c:186: for each function it appears in.) > quotacheck.c:187: `i_uid' undeclared (first use in this function) > quotacheck.c:189: `i_gid' undeclared (first use in this function) > quotacheck.c:194: `i_nlink' undeclared (first use in this function) > quotacheck.c:195: `i_num' undeclared (first use in this function) > quotacheck.c:198: `i_space' undeclared (first use in this function) > quotacheck.c:183: warning: `wanted' might be used uninitialized in this > function > Seems there is some subtle differences between the ia32 headers and the ppc ones - umode_t should come from which comes in via some other header, probably I would guess. Jan, have you come across this powerpc build issue before? Hmmm... from a quick poke around in the kernel source, I see that on powerpc, the linux/include/asm-ppc/types.h explicitly does not export umode_t - it is hidden with a ``#ifdef __KERNEL__'' macro. Perhaps the right fix is just to change umode_t to mode_t? That will at least fix your immediate build problem. Since quotacheck is a no-op for XFS, I haven't actually delved into this chunk of code too deeply - Jan will know the correct solution here though. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 9 16:39:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79NdWC19181 for linux-xfs-outgoing; Thu, 9 Aug 2001 16:39:32 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79NdUV19161 for ; Thu, 9 Aug 2001 16:39:30 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA07576 for ; Thu, 9 Aug 2001 16:38:25 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA21932; Fri, 10 Aug 2001 09:38:12 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA69381; Fri, 10 Aug 2001 09:38:11 +1000 (AEST) Date: Fri, 10 Aug 2001 09:38:11 +1000 From: Nathan Scott To: "Gonyou, Austin" Cc: "Linux XFS (E-mail)" Subject: Re: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer Message-ID: <20010810093811.B279562@wobbly.melbourne.sgi.com> References: <85063BBE668FD411944400D0B744267A643686@AUSMAIL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <85063BBE668FD411944400D0B744267A643686@AUSMAIL>; from austin@coremetrics.com on Thu, Aug 09, 2001 at 05:14:12PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 09, 2001 at 05:14:12PM -0500, Gonyou, Austin wrote: > Currently on my desktop, this works fine for installing with no real > modifications etc. But, on 2 scsi systems, The ./runInstaller will segfault > several hundred times a second and the cpu utilization is at 99.8% on 1 of > the CPUs. Any information in this regard to get it to work on an SMP setup > would be very helpful. > This seems unlikely to be an XFS problem - I'd suggest using gdb to figure out where in ./runInstaller your segfault initially happens, and then get in touch with the Oracle folk about the problem. If you're seeing a recursive segfault (which it sounds like you are), that would account for the high CPU utilization on 1 cpu. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 9 17:02:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A02pv21612 for linux-xfs-outgoing; Thu, 9 Aug 2001 17:02:51 -0700 Received: from camdb.vilcom.com (IDENT:root@[199.72.107.235]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A02mV21587 for ; Thu, 9 Aug 2001 17:02:48 -0700 Received: from towerpc (64-40-83-60.mb.dsl.mebtel.net [64.40.83.60]) by camdb.vilcom.com (8.9.3/8.9.3) with ESMTP id UAA03545; Thu, 9 Aug 2001 20:13:51 -0400 From: "Steven Tower" To: "'Nathan Scott'" , "'Gonyou, Austin'" Cc: "'Linux XFS \(E-mail\)'" Subject: RE: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer Date: Thu, 9 Aug 2001 20:03:25 -0400 Message-ID: <002e01c1212f$e0a58d10$3c532840@towerpc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 In-Reply-To: <20010810093811.B279562@wobbly.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The problem is almost certainly a problem with the Oracle Java version, there is a mention of oracle install problems with Redhat 7.1 in the redhat readme (and the SGI Redhat readme) do too glibc and the jdk. Take a look at the Redhat readme for a fix. Steven -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com] On Behalf Of Nathan Scott Sent: Thursday, August 09, 2001 7:38 PM To: Gonyou, Austin Cc: Linux XFS (E-mail) Subject: Re: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer hi, On Thu, Aug 09, 2001 at 05:14:12PM -0500, Gonyou, Austin wrote: > Currently on my desktop, this works fine for installing with no real > modifications etc. But, on 2 scsi systems, The ./runInstaller will segfault > several hundred times a second and the cpu utilization is at 99.8% on 1 of > the CPUs. Any information in this regard to get it to work on an SMP setup > would be very helpful. > This seems unlikely to be an XFS problem - I'd suggest using gdb to figure out where in ./runInstaller your segfault initially happens, and then get in touch with the Oracle folk about the problem. If you're seeing a recursive segfault (which it sounds like you are), that would account for the high CPU utilization on 1 cpu. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 9 17:58:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A0wke28075 for linux-xfs-outgoing; Thu, 9 Aug 2001 17:58:46 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A0wiV28045 for ; Thu, 9 Aug 2001 17:58:44 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA23301 for ; Thu, 9 Aug 2001 17:58:29 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22324; Fri, 10 Aug 2001 10:57:17 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Steve Lord cc: tridge@valinux.com, linux-xfs@oss.sgi.com, marcelo@conectiva.com.br Subject: Re: high load lockup In-reply-to: Your message of "Thu, 09 Aug 2001 09:13:20 EST." <200108091413.f79EDLR04185@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Aug 2001 10:57:17 +1000 Message-ID: <18399.997405037@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 0xf05a9704 0x80114952 schedule+0x406 (0xd3a3e0e0, 0x1) kernel .text 0x80100000 0x8011454c 0x80114b60 On Thu, 09 Aug 2001 09:13:20 -0500, Steve Lord wrote: > >Hmm, I didn't know linux could survive a stack this deep! The process table is 0xf05a8000-0xf05a9fff. The stack has got down to 0xf05a9704, struct task is about 0x800 bytes, still 0x0f00 bytes left. From owner-linux-xfs@oss.sgi.com Thu Aug 9 22:38:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A5cOT02730 for linux-xfs-outgoing; Thu, 9 Aug 2001 22:38:24 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A5cHV02687; Thu, 9 Aug 2001 22:38:17 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA13815; Fri, 10 Aug 2001 07:38:15 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA24389; Fri, 10 Aug 2001 07:38:15 +0200 (CEST) Date: Fri, 10 Aug 2001 07:38:15 +0200 (CEST) From: Seth Mos To: Ralf Baechle cc: Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer In-Reply-To: <20010810035106.A23548@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 10 Aug 2001, Ralf Baechle wrote: > On Thu, Aug 09, 2001 at 08:53:11PM -0400, Brandon Barker wrote: > > > My intel workstation uses SGI's XFS Installer to create partitions with XFS > > for Redhat 7.1 before it is installed, along with installing a modified > > kernel and utilitiies. I was wondering if there is anything like this for > > Linux Mips (on Indys), or if IRIX 6.2 can create a compatible XFS partition > > for use with linux. > > Don't take my answer as authoritative for XFS stuff - the directory format > of XFS on disk has somewhen been changed; the Linux version only supports > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > flavours are incompatible. True, linux suports only v2. I don't know if Irix 6.2 supports the v2 mode. Another thing to watch out for is that the blocksize must equal pagesize to be able to als mount it under linux. This has different size on different architectures. Most are 4k but ia64 is variable from 2 - 16k or so. This exlpained a bit in the FAQ http://oss.sgi.com/projects/xfs/faq.html I will cc the linux-xfs list for an answer on which Irix versions can support the v2 format. > Ralf > Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Aug 9 23:09:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A69if03149 for linux-xfs-outgoing; Thu, 9 Aug 2001 23:09:44 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A69eV03129; Thu, 9 Aug 2001 23:09:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id XAA05920; Thu, 9 Aug 2001 23:08:32 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA23914; Fri, 10 Aug 2001 16:08:20 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA17338; Fri, 10 Aug 2001 16:08:20 +1000 (AEST) Date: Fri, 10 Aug 2001 16:08:19 +1000 From: Nathan Scott To: Seth Mos Cc: Ralf Baechle , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810160819.D279562@wobbly.melbourne.sgi.com> References: <20010810035106.A23548@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from knuffie@xs4all.nl on Fri, Aug 10, 2001 at 07:38:15AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > On Fri, 10 Aug 2001, Ralf Baechle wrote: > > > On Thu, Aug 09, 2001 at 08:53:11PM -0400, Brandon Barker wrote: > > > > > My intel workstation uses SGI's XFS Installer to create partitions with XFS > > > for Redhat 7.1 before it is installed, along with installing a modified > > > kernel and utilitiies. I was wondering if there is anything like this for > > > Linux Mips (on Indys), or if IRIX 6.2 can create a compatible XFS partition > > > for use with linux. > > > > Don't take my answer as authoritative for XFS stuff - the directory format > > of XFS on disk has somewhen been changed; the Linux version only supports > > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > > flavours are incompatible. > > True, linux suports only v2. I don't know if Irix 6.2 supports the v2 > mode. Another thing to watch out for is that the blocksize must equal > pagesize to be able to als mount it under linux. > > This has different size on different architectures. Most are 4k but ia64 > is variable from 2 - 16k or so. > > This exlpained a bit in the FAQ http://oss.sgi.com/projects/xfs/faq.html > > I will cc the linux-xfs list for an answer on which Irix versions can > support the v2 format. V2 directories were first introduced in 6.5.5 and, AFAICT, there was no IRIX 6.2 patch. The default XFS blocksize on an Indy is 4K, you shouldn't have any trouble there. You could upgrade your Indy to a recent IRIX (6.5 has been around for 3+ years now...) or figure out what's wrong with the v1 directory support on Linux - can't remember what the issues were there, but the code is all still in the tree, might be just a "simple matter of programming". I thought RedHat dropped MIPS as a platform awhile back, so you may be out of luck on the installer front (I'll toss you back to the mips list on that one, I really don't know). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 9 23:30:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A6UGt03531 for linux-xfs-outgoing; Thu, 9 Aug 2001 23:30:16 -0700 Received: from ente.berdmann.de (frnk-d5141a1f.dsl.mediaWays.net [213.20.26.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A6UEV03512 for ; Thu, 9 Aug 2001 23:30:15 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15V5o8-0001pc-00; Fri, 10 Aug 2001 08:30:08 +0200 Message-ID: <3B737F70.503B65EE@berdmann.de> Date: Fri, 10 Aug 2001 08:30:08 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Alan Eldridge CC: SGI XFS Dev List Subject: Re: XFS / VmWare Compatibility References: <20010809123307.A3254@exocore.com> <3B72D8DF.8B384A62@berdmann.de> <20010809150155.A19697@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >put in your .cfg > ># Locking on XFS > >host.FSSupportLocking1 = 0x58465342 > > I've tried this and it didn't work. For a release build, I've got build 1142. When I first started VMWare after upgrading to XFS, it spit out a message "blah, if you're sure this filesystem supports locking, add the following lines to your vmware.cfg, blah" From owner-linux-xfs@oss.sgi.com Fri Aug 10 01:42:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A8g2L05683 for linux-xfs-outgoing; Fri, 10 Aug 2001 01:42:02 -0700 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 f7A8fxV05663 for ; Fri, 10 Aug 2001 01:42:00 -0700 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 f7A8kSS06403 for ; Fri, 10 Aug 2001 01:46:28 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA24609; Fri, 10 Aug 2001 18:40:37 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA34386; Fri, 10 Aug 2001 18:40:37 +1000 (AEST) Date: Fri, 10 Aug 2001 18:40:36 +1000 From: Nathan Scott To: Detlef Vollmann Cc: XFS list Subject: Re: Problems with mkfs.xfs Message-ID: <20010810184036.E279562@wobbly.melbourne.sgi.com> References: <3B71F762.58CD4725@vollmann.ch> <20010809130928.D260586@wobbly.melbourne.sgi.com> <3B7209C0.1DDDE1DD@vollmann.ch> <20010809184544.L260586@wobbly.melbourne.sgi.com> <3B72FB9D.22F2A4F2@vollmann.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B72FB9D.22F2A4F2@vollmann.ch>; from dv@vollmann.ch on Thu, Aug 09, 2001 at 09:07:41PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 09, 2001 at 09:07:41PM +0000, Detlef Vollmann wrote: > > Here are some results (all on linux-2.4.3): > > [root@dwarf tmp]# dd if=/dev/zero of=disk.xfs bs=1024 count=4851 > 4851+0 records in > 4851+0 records out > [root@dwarf tmp]# mkfs -t xfs disk.xfs > meta-data=disk.xfs isize=256 agcount=1, agsize=4096 > blks > data = bsize=4096 blocks=1212, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > Segmentation fault (core dumped) > > That core dump is absolutely reproducible, if the size of the file > is big enough for the log (i.e. in the default case >= 4096K) but > the remaining size is less than 13b). > I've just spent some time looking at this one and narrowed it down to the point where it goes astray in the libxfs code (kernel code), still need to figure out why. The failure happens trying to allocate the root directory inode, we get into [lib]xfs_alloc_fix_freelist which decides (wrongly, it seems) that we don't have enough space for an allocation in the first (and only) AG, so kicks us out, but without an error - in the context its called from, we shouldn't see an error here. We eventually percolate back up to xfs_mkfs.c code and since it didn't see an error, assumes the inode got allocated, and dereferences a null pointer which shoulda had space alloc'd lower down - mkfs.xfs takes a segv. This problem doesn't seem to happen on IRIX, so will be fixable - it will have to wait till Monday though. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Aug 10 04:09:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AB9C108793 for linux-xfs-outgoing; Fri, 10 Aug 2001 04:09:12 -0700 Received: from smtpstore.strencom.net ([217.75.0.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AB98V08774 for ; Fri, 10 Aug 2001 04:09:08 -0700 Received: from raptor.raidtec.ie (unknown [217.75.2.18]) by smtpstore.strencom.net (Postfix) with SMTP id 80EB563944; Fri, 10 Aug 2001 12:10:38 +0100 (IST) Received: from no.name.available by raptor.raidtec.ie via smtpd (for [217.75.0.68]) with SMTP; 10 Aug 2001 12:28:55 UT Subject: RE: Quota - grace Date: Fri, 10 Aug 2001 12:08:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quota - grace Thread-Index: AcEhKzB8xT/g7fUDThKWyNZZTErg7gAYMGiw X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message From: "Juer Lee" To: "Nathan Scott" Cc: "Jan Kara" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7AB99V08775 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks. It works on compiling quotacheck.c .. But when I compile quotacheck_v2.c, new compiling error ' undefined reference to '__fswab64' occured .. I think there must be the probelems when compiling them on PPC. Ok, since Jan will know it, I will wait ... Juer > >Seems there is some subtle differences between the ia32 headers >and the ppc ones - umode_t should come from which >comes in via some other header, probably I would >guess. > >Jan, have you come across this powerpc build issue before? > >Hmmm... from a quick poke around in the kernel source, I see that >on powerpc, the linux/include/asm-ppc/types.h explicitly does not >export umode_t - it is hidden with a ``#ifdef __KERNEL__'' macro. >Perhaps the right fix is just to change umode_t to mode_t? That >will at least fix your immediate build problem. Since quotacheck >is a no-op for XFS, I haven't actually delved into this chunk of >code too deeply - Jan will know the correct solution here though. > >cheers. > >-- >Nathan > From owner-linux-xfs@oss.sgi.com Fri Aug 10 04:21:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABLGG09149 for linux-xfs-outgoing; Fri, 10 Aug 2001 04:21:16 -0700 Received: from dea.waldorf-gmbh.de (u-187-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABLCV09126; Fri, 10 Aug 2001 04:21:12 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7ABJsg24044; Fri, 10 Aug 2001 13:19:54 +0200 Date: Fri, 10 Aug 2001 13:19:54 +0200 From: Ralf Baechle To: Seth Mos Cc: Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810131954.C23866@bacchus.dhis.org> References: <20010810035106.A23548@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from knuffie@xs4all.nl on Fri, Aug 10, 2001 at 07:38:15AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > > of XFS on disk has somewhen been changed; the Linux version only supports > > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > > flavours are incompatible. > > True, linux suports only v2. I don't know if Irix 6.2 supports the v2 > mode. Another thing to watch out for is that the blocksize must equal > pagesize to be able to als mount it under linux. Urg. MIPS also supports various page sizes and so this will limit the use of XFS for file exchange. Is this planned to be fixed? Ralf From owner-linux-xfs@oss.sgi.com Fri Aug 10 04:21:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABLMw09223 for linux-xfs-outgoing; Fri, 10 Aug 2001 04:21:22 -0700 Received: from dea.waldorf-gmbh.de (u-187-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABLGV09147; Fri, 10 Aug 2001 04:21:16 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7ABHgV24035; Fri, 10 Aug 2001 13:17:42 +0200 Date: Fri, 10 Aug 2001 13:17:42 +0200 From: Ralf Baechle To: Nathan Scott Cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810131742.B23866@bacchus.dhis.org> References: <20010810035106.A23548@bacchus.dhis.org> <20010810160819.D279562@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: <20010810160819.D279562@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Fri, Aug 10, 2001 at 04:08:19PM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Nathan, On Fri, Aug 10, 2001 at 04:08:19PM +1000, Nathan Scott wrote: > I thought RedHat dropped MIPS as a platform awhile back, so you may > be out of luck on the installer front (I'll toss you back to the mips > list on that one, I really don't know). Redhat supports MIPS as an embedded target; the only port of their standard distro they ever publshed was Hardhat Linux aka Rough Cuts which was a four CD collection of ports of Redhat to various architectures. (The name Hardhat has been recycled later on by Montavista for their embedded product which is totally unrelated.) Ralf From owner-linux-xfs@oss.sgi.com Fri Aug 10 04:32:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABW5S09788 for linux-xfs-outgoing; Fri, 10 Aug 2001 04:32:05 -0700 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 f7ABW3V09768 for ; Fri, 10 Aug 2001 04:32:03 -0700 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 f7ABbZW09618 for ; Fri, 10 Aug 2001 04:37:36 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA25354; Fri, 10 Aug 2001 21:30:36 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA86294; Fri, 10 Aug 2001 21:30:36 +1000 (EST) Date: Fri, 10 Aug 2001 21:30:35 +1000 From: Nathan Scott To: Juer Lee Cc: Jan Kara , linux-xfs@oss.sgi.com Subject: Re: Quota - grace Message-ID: <20010810213035.A282097@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Juer.Lee@raidtec.ie on Fri, Aug 10, 2001 at 12:08:53PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Fri, Aug 10, 2001 at 12:08:53PM +0100, Juer Lee wrote: > Thanks. > It works on compiling quotacheck.c .. > But when I compile quotacheck_v2.c, new compiling error ' undefined > reference to '__fswab64' occured .. > I think there must be the probelems when compiling them on PPC. > Ok, since Jan will know it, I will wait ... > I can help on that one - we had a similar problem in the XFS user space awhile ago. At the top of quotacheck_v1.c, where is, try this... #if defined(__powerpc__) /* ppc fix from: Robert Ramiega (jedi@plukwa.net) */ # define __BYTEORDER_HAS_U64__ #endif #include [This is derived from cmd/xfsprogs/include/platform_defs.h.in] cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Aug 10 04:39:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABdxL09994 for linux-xfs-outgoing; Fri, 10 Aug 2001 04:39:59 -0700 Received: from atrey.karlin.mff.cuni.cz (root@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABdvV09968 for ; Fri, 10 Aug 2001 04:39:57 -0700 Received: (from jack@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id NAA13303; Fri, 10 Aug 2001 13:39:50 +0200 Date: Fri, 10 Aug 2001 13:39:50 +0200 From: Jan Kara To: Nathan Scott Cc: Juer Lee , Jan Kara , linux-xfs@oss.sgi.com Subject: Re: Quota - grace Message-ID: <20010810133950.A10853@atrey.karlin.mff.cuni.cz> References: <20010810213035.A282097@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010810213035.A282097@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Fri, Aug 10, 2001 at 09:30:35PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, > On Fri, Aug 10, 2001 at 12:08:53PM +0100, Juer Lee wrote: > > Thanks. > > It works on compiling quotacheck.c .. > > But when I compile quotacheck_v2.c, new compiling error ' undefined > > reference to '__fswab64' occured .. > > I think there must be the probelems when compiling them on PPC. > > Ok, since Jan will know it, I will wait ... > > > > I can help on that one - we had a similar problem in the XFS > user space awhile ago. At the top of quotacheck_v1.c, where > is, try this... > > #if defined(__powerpc__) /* ppc fix from: Robert Ramiega (jedi@plukwa.net) */ > # define __BYTEORDER_HAS_U64__ > #endif > #include > > > [This is derived from cmd/xfsprogs/include/platform_defs.h.in] Yes. This should fix it but I think right fix would be to fix kernel includes for ppc - on other architectures __BYTEORDER_HAS_U64__ is defined if __KERNEL__ is defined or STRICT_ANSI is not defined. On ppc theres && instead of || (probably by some accident). To that umode_t thing - I don't know why it was there (this was a part of code I took from older utils :)). It seems to me that as everywhere mode_t is in fact passed there's not reason for umode_t. So I've changed it to mode_t. Honza -- Jan Kara SuSE Labs From owner-linux-xfs@oss.sgi.com Fri Aug 10 04:43:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABhYC10185 for linux-xfs-outgoing; Fri, 10 Aug 2001 04:43:34 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABhUV10165; Fri, 10 Aug 2001 04:43:30 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id EAA05053; Fri, 10 Aug 2001 04:42:21 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA25379; Fri, 10 Aug 2001 21:42:12 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA90837; Fri, 10 Aug 2001 21:42:11 +1000 (EST) Date: Fri, 10 Aug 2001 21:42:11 +1000 From: Nathan Scott To: Ralf Baechle Cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810214211.B282097@wobbly.melbourne.sgi.com> References: <20010810035106.A23548@bacchus.dhis.org> <20010810131954.C23866@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010810131954.C23866@bacchus.dhis.org>; from ralf@oss.sgi.com on Fri, Aug 10, 2001 at 01:19:54PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Fri, Aug 10, 2001 at 01:19:54PM +0200, Ralf Baechle wrote: > On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > > > > of XFS on disk has somewhen been changed; the Linux version only supports > > > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > > > flavours are incompatible. > > > > True, linux suports only v2. I don't know if Irix 6.2 supports the v2 > > mode. Another thing to watch out for is that the blocksize must equal > > pagesize to be able to als mount it under linux. > > Urg. MIPS also supports various page sizes and so this will limit the > use of XFS for file exchange. Is this planned to be fixed? > Yes, for the filesystem blocksize < pagesize case anyway - slated for Linux/XFS 1.1. On IRIX mkfs defaults to a 4K blocksize, which is fortunate I guess. IRIX/XFS supports 512byte through to 64K blocksizes, so having variable page sizes on Linux/MIPS actually makes sharing easier on MIPS than on many other architectures. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Aug 10 04:46:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABkhT10424 for linux-xfs-outgoing; Fri, 10 Aug 2001 04:46:43 -0700 Received: from smtpstore.strencom.net ([217.75.0.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABkfV10405 for ; Fri, 10 Aug 2001 04:46:41 -0700 Received: from raptor.raidtec.ie (unknown [217.75.2.18]) by smtpstore.strencom.net (Postfix) with SMTP id 7D48B63947; Fri, 10 Aug 2001 12:48:23 +0100 (IST) Received: from no.name.available by raptor.raidtec.ie via smtpd (for [217.75.0.68]) with SMTP; 10 Aug 2001 13:06:40 UT Subject: RE: Quota - grace Date: Fri, 10 Aug 2001 12:46:37 +0100 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quota - grace X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Thread-Index: AcEhkTg+P0DlSoMfQNGwu9BIDANoowAAKa7A From: "Juer Lee" To: "Jan Kara" , "Nathan Scott" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7ABkgV10406 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> I can help on that one - we had a similar problem in the XFS >> user space awhile ago. At the top of quotacheck_v1.c, where >> is, try this... >> >> #if defined(__powerpc__) /* ppc fix from: Robert Ramiega >(jedi@plukwa.net) */ >> # define __BYTEORDER_HAS_U64__ >> #endif >> #include >> >> >> [This is derived from cmd/xfsprogs/include/platform_defs.h.in] > Yes. This should fix it but I think right fix would be to >fix kernel includes >for ppc - on other architectures __BYTEORDER_HAS_U64__ is >defined if __KERNEL__ >is defined or STRICT_ANSI is not defined. On ppc theres && >instead of || (probably >by some accident). > To that umode_t thing - I don't know why it was there (this >was a part of code >I took from older utils :)). It seems to me that as everywhere >mode_t is in fact >passed there's not reason for umode_t. So I've changed it to mode_t. > > Honza > >-- >Jan Kara >SuSE Labs > Thank you all. It works, I can use the latest version now:) Juer From owner-linux-xfs@oss.sgi.com Fri Aug 10 05:21:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ACLe411037 for linux-xfs-outgoing; Fri, 10 Aug 2001 05:21:40 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ACLWV10992 for ; Fri, 10 Aug 2001 05:21:33 -0700 Received: (qmail 16740 invoked by uid 8); 10 Aug 2001 12:21:31 -0000 From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: Quota - grace Date: Fri, 10 Aug 2001 14:19:40 +0200 Organization: spoiled dot org Lines: 30 Distribution: local Message-ID: References: <20010810213035.A282097@wobbly.melbourne.sgi.com> Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.7-pre8-xfs (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott wrote: > hi, > On Fri, Aug 10, 2001 at 12:08:53PM +0100, Juer Lee wrote: >> Thanks. >> It works on compiling quotacheck.c .. >> But when I compile quotacheck_v2.c, new compiling error ' undefined >> reference to '__fswab64' occured .. >> I think there must be the probelems when compiling them on PPC. >> Ok, since Jan will know it, I will wait ... >> > I can help on that one - we had a similar problem in the XFS > user space awhile ago. At the top of quotacheck_v1.c, where > is, try this... > #if defined(__powerpc__) /* ppc fix from: Robert Ramiega (jedi@plukwa.net) */ > # define __BYTEORDER_HAS_U64__ > #endif > #include exactly this it was what i had too ... just from feeling - shouldn't this be fixed in the ppc byteoder.h file or am i wrong here? t -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Fri Aug 10 05:21:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ACLbW11030 for linux-xfs-outgoing; Fri, 10 Aug 2001 05:21:37 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ACLWV10991 for ; Fri, 10 Aug 2001 05:21:33 -0700 Received: (qmail 23480 invoked by uid 8); 10 Aug 2001 12:21:31 -0000 From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: Quota - grace Date: Fri, 10 Aug 2001 14:17:59 +0200 Organization: spoiled dot org Lines: 19 Distribution: local Message-ID: References: Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.7-pre8-xfs (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Juer Lee" wrote: > Thanks. > It works on compiling quotacheck.c .. > But when I compile quotacheck_v2.c, new compiling error ' undefined > reference to '__fswab64' occured .. > I think there must be the probelems when compiling them on PPC. > Ok, since Jan will know it, I will wait ... i remember having seen this __fswab64 thing too - it looked to me like a slightly broken headerfile ... will have to check at home on the ppc what exactly it was ... somehow a define is set so the the defines for those 64bit functions are not included ... t -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Fri Aug 10 06:21:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ADLb512108 for linux-xfs-outgoing; Fri, 10 Aug 2001 06:21:37 -0700 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 f7ADLYV12089 for ; Fri, 10 Aug 2001 06:21:34 -0700 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 09:20:54 -0400 Message-ID: <23D04BDBA646D411BDDD00D0B774B5390460251A@SA-BWMAIL1> From: "Christian, Chip" To: "'swalton@sunspot.csun.edu'" , "Christian, Chip" Cc: "'NFS list (E-mail)'" , "Linux XFS (E-mail)" Subject: RE: [NFS] kernel nfsd crash Date: Fri, 10 Aug 2001 09:20:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk And of course it was return pdentry; not return(); I typed that into the email by hand... -----Original Message----- From: Stephen Walton [mailto:swalton@sunspot.csun.edu] Sent: Thursday, August 09, 2001 17:49 To: Christian, Chip Cc: 'NFS list (E-mail)'; Linux XFS (E-mail) Subject: RE: [NFS] kernel nfsd crash On Thu, 9 Aug 2001, Christian, Chip wrote: > --- nfsfh.c 2001/05/09 00:54:56 1.1 > +++ nfsfh.c 2001/05/09 00:56:01 > @@ -244,6 +244,10 @@ > */ > pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); > d_drop(tdentry); /* we never want ".." hashed */ > + if (!pdentry && tdentry->d_inode == NULL) { > + dput(tdentry); > + pdentry = ERR_PTR(-EINVAL); > ==> + return() > + } Wouldn't this be simpler: if (!pdentry && tdentry->d_inode == NULL) { dput(tdentry); return ERRPTR(-EINVAL); } ---- Stephen Walton, Professor of Physics and Astronomy, California State University, Northridge stephen.walton@csun.edu From owner-linux-xfs@oss.sgi.com Fri Aug 10 06:48:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ADmej12641 for linux-xfs-outgoing; Fri, 10 Aug 2001 06:48:40 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ADmWV12604; Fri, 10 Aug 2001 06:48:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA974927; Fri, 10 Aug 2001 15:47:21 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2681294; Fri, 10 Aug 2001 08:47:12 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA03690; Fri, 10 Aug 2001 08:47:12 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7ADkQ307720; Fri, 10 Aug 2001 08:46:26 -0500 Message-Id: <200108101346.f7ADkQ307720@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ralf Baechle cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer In-Reply-To: Message from Ralf Baechle of "Fri, 10 Aug 2001 13:19:54 +0200." <20010810131954.C23866@bacchus.dhis.org> Date: Fri, 10 Aug 2001 08:46:26 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > > > > of XFS on disk has somewhen been changed; the Linux version only supports > > > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > > > flavours are incompatible. > > > > True, linux suports only v2. I don't know if Irix 6.2 supports the v2 > > mode. Another thing to watch out for is that the blocksize must equal > > pagesize to be able to als mount it under linux. > > Urg. MIPS also supports various page sizes and so this will limit the > use of XFS for file exchange. Is this planned to be fixed? The page size == block size will get fixed, we need to do that, but it may take a while. Block size less than pagesize will come first, blocksize greater than pagesize needs PAGE_CACHE_SIZE to be bumped, which appears to be on the cards for 2.5. V1 directories mostly work in Linux, but there are glibc getdents issues with them. The glibc code which lseeks backwards in a directory is the issue, if you have control over your glibc it can be fixed by using the 64 bit version of lseek in this code. This is all because the directory offset in V1 is a 64 bit hash value, not a 32 bit signed number. Steve > > Ralf From owner-linux-xfs@oss.sgi.com Fri Aug 10 07:18:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEIw713492 for linux-xfs-outgoing; Fri, 10 Aug 2001 07:18:58 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEIqV13467; Fri, 10 Aug 2001 07:18:52 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id QAA19646; Fri, 10 Aug 2001 16:18:34 +0200 (CEST) Message-Id: <4.3.2.7.2.20010810161107.032d5ee8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Aug 2001 16:18:07 +0200 To: Steve Lord , Ralf Baechle From: Seth Mos Subject: Re: XFS installer Cc: Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com In-Reply-To: <200108101346.f7ADkQ307720@jen.americas.sgi.com> References: <20010810131954.C23866@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:46 10-8-2001 -0500, Steve Lord wrote: > > On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: >V1 directories mostly work in Linux, but there are glibc getdents issues >with them. The glibc code which lseeks backwards in a directory is the issue, >if you have control over your glibc it can be fixed by using the 64 bit >version of lseek in this code. This is all because the directory offset in >V1 is a 64 bit hash value, not a 32 bit signed number. Would this have adverse effects on existing code if this would be changed? Is it something that can be done without pulling out everything from beneath us? Does userspace need to be recompiled? Would something like this be needed for other architectures as well? If this can become standard in glibc we can tell people that it is supported from glibc 2.2.? systems and higher. Would a workaround in the kernel code even be a possibility. 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 Aug 10 07:30:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEUxI13824 for linux-xfs-outgoing; Fri, 10 Aug 2001 07:30:59 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEUuV13805 for ; Fri, 10 Aug 2001 07:30:56 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 09:30:48 -0500 Message-ID: <85063BBE668FD411944400D0B744267A64368C@AUSMAIL> From: "Gonyou, Austin" To: "'Steven Tower'" , "'Nathan Scott'" , "Gonyou, Austin" Cc: "'Linux XFS (E-mail)'" Subject: RE: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer Date: Fri, 10 Aug 2001 09:30:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I had already gone through that. One thing that did help is the LD_ASSUME_KERNEL bit. But, it still won't run properly. I agree that it's not an XFS issue..but I wasn't sure and wanted to come here for confirmation as well. Anyone running this type of config on an SMP machine and has it working, I'd like to talk to that person. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Steven Tower [mailto:tower@towerhome.cx] > Sent: Thursday, August 09, 2001 7:03 PM > To: 'Nathan Scott'; 'Gonyou, Austin' > Cc: 'Linux XFS (E-mail)' > Subject: RE: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer > > > The problem is almost certainly a problem with the Oracle > Java version, > there is a mention of oracle install problems with Redhat 7.1 in the > redhat readme (and the SGI Redhat readme) do too glibc and the jdk. > Take a look at the Redhat readme for a fix. > > Steven > > -----Original Message----- > From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com] > On Behalf Of Nathan Scott > Sent: Thursday, August 09, 2001 7:38 PM > To: Gonyou, Austin > Cc: Linux XFS (E-mail) > Subject: Re: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer > > hi, > > On Thu, Aug 09, 2001 at 05:14:12PM -0500, Gonyou, Austin wrote: > > Currently on my desktop, this works fine for installing with no real > > modifications etc. But, on 2 scsi systems, The ./runInstaller will > segfault > > several hundred times a second and the cpu utilization is > at 99.8% on > 1 of > > the CPUs. Any information in this regard to get it to work on an SMP > setup > > would be very helpful. > > > > This seems unlikely to be an XFS problem - I'd suggest using gdb to > figure out where in ./runInstaller your segfault initially happens, > and then get in touch with the Oracle folk about the problem. > > If you're seeing a recursive segfault (which it sounds like you are), > that would account for the high CPU utilization on 1 cpu. > > cheers. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Fri Aug 10 07:35:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEZHY13985 for linux-xfs-outgoing; Fri, 10 Aug 2001 07:35:17 -0700 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 f7AEZCV13951; Fri, 10 Aug 2001 07:35:12 -0700 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 f7AEejW14760; Fri, 10 Aug 2001 07:40:45 -0700 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 JAA2680720; Fri, 10 Aug 2001 09:33:50 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA01468; Fri, 10 Aug 2001 09:33:50 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7AEX4P07846; Fri, 10 Aug 2001 09:33:04 -0500 Message-Id: <200108101433.f7AEX4P07846@jen.americas.sgi.com> To: Seth Mos cc: Steve Lord , Ralf Baechle , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer References: <20010810131954.C23866@bacchus.dhis.org> <4.3.2.7.2.20010810161107.032d5ee8@pop.xs4all.nl> Comments: In-reply-to Seth Mos message dated "Fri, 10 Aug 2001 16:18:07 +0200." Date: Fri, 10 Aug 2001 09:33:04 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > At 08:46 10-8-2001 -0500, Steve Lord wrote: > > > On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > >V1 directories mostly work in Linux, but there are glibc getdents issues > >with them. The glibc code which lseeks backwards in a directory is the issue > , > >if you have control over your glibc it can be fixed by using the 64 bit > >version of lseek in this code. This is all because the directory offset in > >V1 is a 64 bit hash value, not a 32 bit signed number. > > Would this have adverse effects on existing code if this would be changed? > Is it something that can be done without pulling out everything from > beneath us? Does userspace need to be recompiled? Would something like this > be needed for other architectures as well? This is only needed if reasonable V1 directory support is required on Linux, without it you can get files missing in directories etc. In fact even with it this can still happen. This was the whole reason we made V2 the default on Linux (we finally won the battle to make it the default on Irix too). > > If this can become standard in glibc we can tell people that it is > supported from glibc 2.2.? systems and higher. All attempts to get glibc to budge on this have failed. > > Would a workaround in the kernel code even be a possibility. I am not sure, no time to think about it right now... Steve > > 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 Aug 10 07:45:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEjOr14298 for linux-xfs-outgoing; Fri, 10 Aug 2001 07:45:24 -0700 Received: from dea.waldorf-gmbh.de (u-65-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEj7V14276; Fri, 10 Aug 2001 07:45:10 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7ACcDS24442; Fri, 10 Aug 2001 14:38:13 +0200 Date: Fri, 10 Aug 2001 14:38:13 +0200 From: Ralf Baechle To: Nathan Scott Cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810143813.A24347@bacchus.dhis.org> References: <20010810035106.A23548@bacchus.dhis.org> <20010810131954.C23866@bacchus.dhis.org> <20010810214211.B282097@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: <20010810214211.B282097@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Fri, Aug 10, 2001 at 09:42:11PM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 09:42:11PM +1000, Nathan Scott wrote: > > Urg. MIPS also supports various page sizes and so this will limit the > > use of XFS for file exchange. Is this planned to be fixed? > > Yes, for the filesystem blocksize < pagesize case anyway - slated > for Linux/XFS 1.1. On IRIX mkfs defaults to a 4K blocksize, which > is fortunate I guess. > > IRIX/XFS supports 512byte through to 64K blocksizes, so having > variable page sizes on Linux/MIPS actually makes sharing easier > on MIPS than on many other architectures. Some chips now support page sizes of 1kb an higher, so the case of filesystems of large blocksize than pagesize is also going to be of some interest. Ralf From owner-linux-xfs@oss.sgi.com Fri Aug 10 07:47:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AElOB14498 for linux-xfs-outgoing; Fri, 10 Aug 2001 07:47:24 -0700 Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AElMV14479 for ; Fri, 10 Aug 2001 07:47:22 -0700 Received: (qmail 29489 invoked by uid 3995); 10 Aug 2001 14:47:21 -0000 From: "Dave Sill" Mail-Followup-To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15219.62457.8652.45747@sws5.ctd.ornl.gov> Date: Fri, 10 Aug 2001 10:47:21 -0400 To: linux-xfs@oss.sgi.com Subject: NFS problems X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M To: Steve Lord Cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810164807.A24889@bacchus.dhis.org> References: <200108101346.f7ADkQ307720@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108101346.f7ADkQ307720@jen.americas.sgi.com>; from lord@sgi.com on Fri, Aug 10, 2001 at 08:46:26AM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 08:46:26AM -0500, Steve Lord wrote: > The page size == block size will get fixed, we need to do that, but it > may take a while. Block size less than pagesize will come first, blocksize > greater than pagesize needs PAGE_CACHE_SIZE to be bumped, which appears to > be on the cards for 2.5. > > V1 directories mostly work in Linux, but there are glibc getdents issues > with them. The glibc code which lseeks backwards in a directory is the issue, > if you have control over your glibc it can be fixed by using the 64 bit > version of lseek in this code. This is all because the directory offset in > V1 is a 64 bit hash value, not a 32 bit signed number. So in other words that means using kernel 2.4 / glibc 2.2 and for 32-bit systems building applications with the large file API. Ralf From owner-linux-xfs@oss.sgi.com Fri Aug 10 07:55:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEtFj14981 for linux-xfs-outgoing; Fri, 10 Aug 2001 07:55:15 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEtBV14962 for ; Fri, 10 Aug 2001 07:55:11 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id QAA21604; Fri, 10 Aug 2001 16:55:08 +0200 (CEST) Message-Id: <4.3.2.7.2.20010810161950.032a4c68@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Aug 2001 16:54:41 +0200 To: Bram Moolenaar From: Seth Mos Subject: Re: vim file write mode on journaling fs. Cc: Linux XFS Mailing List In-Reply-To: <200108101415.f7AEF8R05836@moolenaar.net> References: <4.3.2.7.2.20010810150353.034c08f8@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:15 10-8-2001 +0200, Bram Moolenaar wrote: >Seth - cc-ing the list > > I was noticing that on journaling filesystems (in this case XFS) you can > > lose data using vi. > > Example, possible explanation and solution provided. I have not read the > > code to vi (6.0z in my test) so I might have made a wrong assumption > about > > something but the problem stands as it is. > >What you describe sounds like a bug in the filesystem. Vim closes the file, >and that should be sufficient to be sure that the data has been written. On >an "old" file system there is always the risk that the computer crashes before >the cache has been flushed. Therefore Vim provides a backup file. > >Calling fsync() after writing a file would reduce the chance to lose data, but >it also makes Vim slower and increase the system load. Is there an option within vi to use this as a "Safe mode". >That the file is filled with NULLS is certainly a bug in the FS. If nothing >got written yet, the old data should still be there. If the meta data was >updated without the file contents being there, then something has gone wrong >in the FS. It should first write the new data and then update the meta data, >so that there is never an inconsistent situation. When overwriting a file >with new data the metadata doesn't even have to be changed, unless the size >changes. The Nulls come from the fact that XFS supports extents. The metadata is written out to disk and xfs allocates the extents for this file. a truncate is done on the file to start writing the data. Because this never happend you are seeing the NULLS from the "empty" extents. Observation has revealed that the data is only pushed out to disk after 30 seconds or so by the VM. The metadata (size and timestamp) was pushed out to disk on exit. Other filesystems might have this problem as well if they are journaling metadata only. >In the "old" FS there was only a problem when the system crashes halfway >flushing the file. A journaling fs will recover from this because the disk write will be logged and recovered from if it was not complete and reproduce the old data. However in this case the data is not pushed out simultaneously or takes another path. > Actually, a power failure halfway a write can cause >anything to happen to the harddisk. A spike is even worse, it's easy to >create a bad sector (or write while the head is moving, destroying several >sectors). A journaling filesystem doesn't protect you from hardware failure! That is not what it is supposed to do. > > Solution: > > > > When exiting vi call fsync on the file you work on to make sure the > data is > > sent to disk after exiting or user may have lost their data when something > > goes wrong. > >When Vim exits the file has already been closed. It would have to be done >each time you write a file, just before closing it. It actually doesn't >matter if you exit Vim or not, you might just use ":w" when you go off for >lunch and trip over the power cord. This produces the exact same pattern. I opened minicom.log which had one line of text and was 35Bytes. Added a line "test" wrote it with :w unplug. After reboot the file is: [seth@lsautom seth]$ ll minicom.log -rw-r--r-- 1 seth staff 42 Aug 10 17:37 minicom.log [seth@lsautom seth]$ cat -v minicom.log ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@[seth@lsautom seth]$ So the metadata was written but the data never got there. vi -r minicom.log did contain the valid data. So why was the .swp written out but the original file not! calling sync manually after exit gets it to disk for sure. Waiting 10 seconds before pulling the power was not enough to get it to disk. 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 Aug 10 07:58:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEwXq15175 for linux-xfs-outgoing; Fri, 10 Aug 2001 07:58:33 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEwPV15121; Fri, 10 Aug 2001 07:58:25 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA00509; Fri, 10 Aug 2001 07:56:22 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2678389; Fri, 10 Aug 2001 09:57:08 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA20365; Fri, 10 Aug 2001 09:57:08 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7AEuMi07997; Fri, 10 Aug 2001 09:56:22 -0500 Message-Id: <200108101456.f7AEuMi07997@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ralf Baechle cc: Steve Lord , Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer In-Reply-To: Message from Ralf Baechle of "Fri, 10 Aug 2001 16:48:07 +0200." <20010810164807.A24889@bacchus.dhis.org> Date: Fri, 10 Aug 2001 09:56:22 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, Aug 10, 2001 at 08:46:26AM -0500, Steve Lord wrote: > > > The page size == block size will get fixed, we need to do that, but it > > may take a while. Block size less than pagesize will come first, blocksize > > greater than pagesize needs PAGE_CACHE_SIZE to be bumped, which appears to > > be on the cards for 2.5. > > > > V1 directories mostly work in Linux, but there are glibc getdents issues > > with them. The glibc code which lseeks backwards in a directory is the issu > e, > > if you have control over your glibc it can be fixed by using the 64 bit > > version of lseek in this code. This is all because the directory offset in > > V1 is a 64 bit hash value, not a 32 bit signed number. > > So in other words that means using kernel 2.4 / glibc 2.2 and for 32-bit > systems building applications with the large file API. No, it all depends on which version of the glibc getdents code you have, there have been several, I cannot remember what it looks like now. here is an old patch: --- glibc-2.1.3/sysdeps/unix/sysv/linux/getdents.c.orig Fri May 7 09:41:08 1999 +++ glibc-2.1.3/sysdeps/unix/sysv/linux/getdents.c Thu Mar 23 11:49:11 2000 @@ -53,6 +53,9 @@ #ifdef GETDENTS64 # define __getdents __getdents64 # define dirent dirent64 +# undef off_t +# define off_t off64_t +# define __lseek __lseek64 #endif /* The problem here is that we cannot simply read the next NBYTES @@ -107,6 +110,33 @@ } last_offset = kdp->d_off; + +#ifdef GETDENTS64 + if (sizeof(__kernel_off_t) < sizeof(off64_t)) { + /* + * The kernel returns d_off as a 'cookie' that can be used + * in an lseek() to re-position the directory stream. + * "d_off" is signed by current definition of "__kernel_off_t", + * which is consistent with lseek() "off_t" semantics. + * Some file systems, most commonly NFS, may return "d_off" + * 'cookies' that use all 32 bits, or more specifically the + * sign bit. + * This means we need to be careful how we save "last_offset" + * in the case where "last_offset" is defined to be a larger + * container than "__kernel_off_t", we want to prevent the sign + * extension; it's only the lower 32 bits that we want to be + * able to pass back in via lseek64(). + */ + switch(sizeof(__kernel_off_t)) { + case 4: + { + last_offset = (u_int32_t)kdp->d_off; + + break; + } + } + } +#endif dp->d_ino = kdp->d_ino; dp->d_off = kdp->d_off; dp->d_reclen = new_reclen; I am pretty sure this patch is useless with a 2.2 glibc. The issue is not so much the application interface as the fact that glibc has the nasty habit of lseeking back in the directory because its dirent and the kernels are not the same size. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 10 08:07:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AF78C15515 for linux-xfs-outgoing; Fri, 10 Aug 2001 08:07:08 -0700 Received: from ganymede.conwaycorp.net ([24.144.1.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AF76V15496 for ; Fri, 10 Aug 2001 08:07:06 -0700 Received: from tao.wang-fu.org (tao.wang-fu.org [24.144.32.127]) by ganymede.conwaycorp.net with ESMTP id f7AEwDE22021 for ; Fri, 10 Aug 2001 09:58:13 -0500 (CDT) Received: from kraken by tao.wang-fu.org with local (Exim 3.32 #1 (Debian)) id 15VDrF-0006aA-00 for ; Fri, 10 Aug 2001 10:05:53 -0500 Date: Fri, 10 Aug 2001 10:05:53 -0500 From: Nathan Poznick To: linux-xfs@oss.sgi.com Subject: __alloc_pages: 0-order allocation failed. Message-ID: <20010810100553.A25178@conwaycorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Yesterday, I installed the 1.0.1 patch against 2.4.5 on a machine at work. The machine's a 2-cpu, 4gb ram machine (highmem 4gb enabled). I've got 4 disks on a dual-channel megaraid controller, doing hardware raid0 across all 4. I created a single, 273gb partition, and did an mkfs.xfs on it. I then tried to create a 20gb file with: dd if=/dev/zero of=/u01/bigassfile bs=4096 count=5242880 This gave me messages like: Aug 9 14:59:10 dpdred2 kernel: __alloc_pages: 0-order allocation failed. Aug 9 14:59:14 dpdred2 last message repeated 113 times Aug 9 15:01:51 dpdred2 last message repeated 90 times Aug 9 15:01:51 dpdred2 kernel: ed. Aug 9 15:01:51 dpdred2 kernel: __alloc_pages: 0-order allocation failed. Aug 9 15:02:32 dpdred2 last message repeated 364 times Aug 9 15:02:54 dpdred2 last message repeated 3 times Aug 9 15:02:54 dpdred2 last message repeated 11 times Aug 9 15:05:47 dpdred2 kernel: ed. Aug 9 15:05:47 dpdred2 kernel: __alloc_pages: 0-order allocation failed. The file was created successfully though...but the messages do tend to put me on edge a bit. Copying a 64gb file from an NFS share to the filesystem doesn't show any problems. I got the feeling from a message in the archives that this might be a problem with the mainline kernel's highmem code... would that be a reasonable assumption, or is this an XFS issue? If it's related to the highmem issues, then I'd need to upgrade to 2.4.7...are there release 1.0.1 patches against 2.4.7, or will I have to upgrade to the latest development snapshot? If I have to upgrade to the latest development snapshot, is it stable enough to use? Thanks, Nathan Poznick -- Nathan PGP Key: http://drunkmonkey.org/pgpkey.txt "Looks like that jelly donut got away from him." -Crow. #202 From owner-linux-xfs@oss.sgi.com Fri Aug 10 08:34:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AFYqO15962 for linux-xfs-outgoing; Fri, 10 Aug 2001 08:34:52 -0700 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 f7AFYoV15942 for ; Fri, 10 Aug 2001 08:34:50 -0700 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 f7AFdKS16284 for ; Fri, 10 Aug 2001 08:39:20 -0700 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 KAA2675443; Fri, 10 Aug 2001 10:33:28 -0500 (CDT) Received: from sgi.com (eagdhcp-187-24.americas.sgi.com [128.162.187.174]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA80156; Fri, 10 Aug 2001 10:33:28 -0500 (CDT) Message-ID: <3B73F68D.7D9ABC61@sgi.com> Date: Fri, 10 Aug 2001 09:58:21 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Poznick CC: linux-xfs@oss.sgi.com Subject: Re: __alloc_pages: 0-order allocation failed. References: <20010810100553.A25178@conwaycorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Poznick wrote: > The file was created successfully though...but the messages do tend to > put me on edge a bit. Copying a 64gb file from an NFS share to the > filesystem doesn't show any problems. I got the feeling from a > message in the archives that this might be a problem with the mainline > kernel's highmem code... would that be a reasonable assumption, or is > this an XFS issue? I'm not an authority on this (Steve?) but I think it's a mainline kernel problem, possibly aggravated by XFS. > If it's related to the highmem issues, then I'd > need to upgrade to 2.4.7...are there release 1.0.1 patches against > 2.4.7, or will I have to upgrade to the latest development snapshot? There's no 1.0.1 for 2.4.7 since as the kernel changes, XFS has to change, and it's no longer "1.0.1" :) So the devel patch for 2.4.7 is what you would need. > If I have to upgrade to the latest development snapshot, is it stable > enough to use? Depends on your definition of "use" - I'm not aware of any problems with it, but it has not had rigorous testing. My expectation is that it will be fine, you should convince yourself of this before you decide to use it for production, of course. -Eric From owner-linux-xfs@oss.sgi.com Fri Aug 10 08:45:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AFjCn16281 for linux-xfs-outgoing; Fri, 10 Aug 2001 08:45:12 -0700 Received: from mydomain.com (1Cust175.tnt2.cph3.da.uu.net [213.116.21.175]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AFj9V16260; Fri, 10 Aug 2001 08:45:09 -0700 Message-Id: <200108101545.f7AFj9V16260@oss.sgi.com> Date: Fri, 10 Aug 2001 17:45:23 +0100 From: MEGASITE To: MEGASITE@oss.sgi.com Subject: WORLDS NO.1 .. JUST INCREDIBLE! Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear Ladies & Gentlemen, Welcome to the GREATEST SEX SHOW on the ENTIRE NET ! We now offer you to ENTER the worldŽs No.1 voted SEX-SERVER on the WEB ! By far the largest and most incredible content of LIVE SEX is now served to users WORLDWIDE! EVERYTHING is offered 100% ANONOMOUSLY & you donŽt need to sign-up or have a creditcard ... The way it should be ! PLUGIN RIGHT HERE AT: http://siam.to/getitnow ... If this Site does not open properly ... please try http://hottestweb.hk.st Or this one, if you just love true LESBIAN SEX, CHAT and MORE from Sunny Ibiza in Spain: http://siam.to/hottestbabes Or http://siam.to/sohot and get access to something you with guarantee NEVER have seen before ! Enjoy the BEST! Yours truly, MEGASITE-WEB Inc. From owner-linux-xfs@oss.sgi.com Fri Aug 10 09:14:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AGELe17172 for linux-xfs-outgoing; Fri, 10 Aug 2001 09:14:21 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AGEIV17151 for ; Fri, 10 Aug 2001 09:14:18 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA13301; Fri, 10 Aug 2001 18:14:16 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA16662; Fri, 10 Aug 2001 18:14:16 +0200 (CEST) Date: Fri, 10 Aug 2001 18:14:16 +0200 (CEST) From: Seth Mos To: Nathan Poznick cc: linux-xfs@oss.sgi.com Subject: Re: __alloc_pages: 0-order allocation failed. In-Reply-To: <20010810100553.A25178@conwaycorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 10 Aug 2001, Nathan Poznick wrote: > > Hello, > > Yesterday, I installed the 1.0.1 patch against 2.4.5 on a machine at > work. The machine's a 2-cpu, 4gb ram machine (highmem 4gb enabled). > I've got 4 disks on a dual-channel megaraid controller, doing hardware > raid0 across all 4. I created a single, 273gb partition, and did an > mkfs.xfs on it. I then tried to create a 20gb file with: > > dd if=/dev/zero of=/u01/bigassfile bs=4096 count=5242880 > > This gave me messages like: > > Aug 9 14:59:10 dpdred2 kernel: __alloc_pages: 0-order allocation failed. > Aug 9 14:59:14 dpdred2 last message repeated 113 times > Aug 9 15:01:51 dpdred2 last message repeated 90 times > Aug 9 15:01:51 dpdred2 kernel: ed. > Aug 9 15:01:51 dpdred2 kernel: __alloc_pages: 0-order allocation failed. > Aug 9 15:02:32 dpdred2 last message repeated 364 times > Aug 9 15:02:54 dpdred2 last message repeated 3 times > Aug 9 15:02:54 dpdred2 last message repeated 11 times > Aug 9 15:05:47 dpdred2 kernel: ed. > Aug 9 15:05:47 dpdred2 kernel: __alloc_pages: 0-order allocation failed. > > The file was created successfully though...but the messages do tend to > put me on edge a bit. Copying a 64gb file from an NFS share to the > filesystem doesn't show any problems. Probably because it does not push the system as much. > I got the feeling from a > message in the archives that this might be a problem with the mainline > kernel's highmem code... would that be a reasonable assumption, It is, other people are seeing it too. > or is > this an XFS issue? If it's related to the highmem issues, then I'd > need to upgrade to 2.4.7...are there release 1.0.1 patches against > 2.4.7, Not quite 1.0.1 patches but yes there are patches for 2.4.7 on the FTP site. > or will I have to upgrade to the latest development snapshot? Not neccesarily. The cvs tree is at 2.4.8-pre7 > If I have to upgrade to the latest development snapshot, is it stable > enough to use? Using the 2.4.7 patch is probably safer. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 10 09:35:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AGZb817506 for linux-xfs-outgoing; Fri, 10 Aug 2001 09:35:37 -0700 Received: from mail.corbett-msc.com (mail.corbett-msc.com [4.21.114.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AGZWV17487 for ; Fri, 10 Aug 2001 09:35:32 -0700 Received: (qmail 7211 invoked from network); 10 Aug 2001 16:35:26 -0000 Received: from unknown (HELO jenteal) (apendlet@4.21.114.113) by mail.corbett-msc.com with SMTP; 10 Aug 2001 16:35:26 -0000 From: "Adam H. Pendleton" To: "'Gonyou, Austin'" , "'Steven Tower'" , "'Nathan Scott'" Cc: "'Linux XFS \(E-mail\)'" Subject: RE: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer Date: Fri, 10 Aug 2001 12:34:10 -0400 Message-ID: <000401c121ba$487e6080$644da8c0@corbettmsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 In-Reply-To: <85063BBE668FD411944400D0B744267A64368C@AUSMAIL> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have had this same problem, but I figured it out. The problem is not an XFS problem, per se. The problem has to do with the permissions problems that the 1.0.1 XFS installer created. A fix-perms script was released to this list. Make sure you run it. It fixes the errors that are causing runInstaller to fail. Make sure that you follow all the instructions in the install guide, but here is the short version: As the oracle user, type: Export LD_ASSUME_KERNEL=2.2.5 . /usr/i386-glibc21-linux/bin/i386-glibc21-linux-env.sh Then you can run ./runInstaller. If you have done the above three steps, Oracle will install properly. Incidentally, you do not need to download and install the IBM jdk unless you are installing the Oracle HTTP Server. The above information on the LD_ASSUME_KERNEL and the i386-glibc21-linux-env came from the RedHat 7.1 release notes. The IBM jdk info is from the Oracle Installation Guide. The fix-perms script was released to the list a couple of weeks ago. If you cannot get a copy of it, e-mail me and I will send it to you. If you have any more questions, feel free to e-mail me. Adam H. Pendleton Operations Manager Security Operations Center Corbett Technologies, Inc. Alexandria, Virginia USA http://www.corbett-tech.com -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com] On Behalf Of Gonyou, Austin Sent: Friday, August 10, 2001 10:31 To: 'Steven Tower'; 'Nathan Scott'; Gonyou, Austin Cc: 'Linux XFS (E-mail)' Subject: RE: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer I had already gone through that. One thing that did help is the LD_ASSUME_KERNEL bit. But, it still won't run properly. I agree that it's not an XFS issue..but I wasn't sure and wanted to come here for confirmation as well. Anyone running this type of config on an SMP machine and has it working, I'd like to talk to that person. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Steven Tower [mailto:tower@towerhome.cx] > Sent: Thursday, August 09, 2001 7:03 PM > To: 'Nathan Scott'; 'Gonyou, Austin' > Cc: 'Linux XFS (E-mail)' > Subject: RE: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer > > > The problem is almost certainly a problem with the Oracle > Java version, > there is a mention of oracle install problems with Redhat 7.1 in the > redhat readme (and the SGI Redhat readme) do too glibc and the jdk. > Take a look at the Redhat readme for a fix. > > Steven > > -----Original Message----- > From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com] > On Behalf Of Nathan Scott > Sent: Thursday, August 09, 2001 7:38 PM > To: Gonyou, Austin > Cc: Linux XFS (E-mail) > Subject: Re: Oracle 8.1.7_03 on RH 7.1 XFS 1.0 installer > > hi, > > On Thu, Aug 09, 2001 at 05:14:12PM -0500, Gonyou, Austin wrote: > > Currently on my desktop, this works fine for installing with no real > > modifications etc. But, on 2 scsi systems, The ./runInstaller will > segfault > > several hundred times a second and the cpu utilization is > at 99.8% on > 1 of > > the CPUs. Any information in this regard to get it to work on an SMP > setup > > would be very helpful. > > > > This seems unlikely to be an XFS problem - I'd suggest using gdb to > figure out where in ./runInstaller your segfault initially happens, > and then get in touch with the Oracle folk about the problem. > > If you're seeing a recursive segfault (which it sounds like you are), > that would account for the high CPU utilization on 1 cpu. > > cheers. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Fri Aug 10 09:38:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AGcw617656 for linux-xfs-outgoing; Fri, 10 Aug 2001 09:38:58 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AGcuV17637 for ; Fri, 10 Aug 2001 09:38:56 -0700 Received: from thebarn.com ([63.231.179.33]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7AGcrXi033138; Fri, 10 Aug 2001 11:38:54 -0500 (CDT) Message-ID: <3B740D4A.89383DF2@thebarn.com> Date: Fri, 10 Aug 2001 11:35:23 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.3-xfs-1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Bram Moolenaar , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. References: <4.3.2.7.2.20010810150353.034c08f8@pop.xs4all.nl> <4.3.2.7.2.20010810161950.032a4c68@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > The Nulls come from the fact that XFS supports extents. The metadata is > written out to disk and xfs allocates the extents for this file. a truncate > is done on the file to start writing the data. > Because this never happend you are seeing the NULLS from the "empty" extents. > Note there is a performance trade off going on here; file size update are NOT logged which is why the file has a size but no extents... if the size update was logged the meta data update to the size field would only happen after extents had been allocated, (part of the same transaction) and indeed this was how it was originally. But creating a new transaction for each size update was a lot of overhead and thus a performance hit. At some point along the way it size updates were de-coupled from the logging. From owner-linux-xfs@oss.sgi.com Fri Aug 10 10:40:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AHe0w18462 for linux-xfs-outgoing; Fri, 10 Aug 2001 10:40:00 -0700 Received: from acmey.gatech.edu (acmey.gatech.edu [130.207.165.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AHduV18443 for ; Fri, 10 Aug 2001 10:39:56 -0700 Received: from [130.207.197.237] ([130.207.197.237]) by acmey.gatech.edu (8.9.2/8.9.2) with ESMTP id NAA04165; Fri, 10 Aug 2001 13:39:55 -0400 (EDT) Subject: Re: NFS problems From: Rob Myers To: Dave Sill Cc: linux-xfs@oss.sgi.com In-Reply-To: <15219.62457.8652.45747@sws5.ctd.ornl.gov> References: <15219.62457.8652.45747@sws5.ctd.ornl.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12.99 (Preview Release) Date: 10 Aug 2001 13:43:00 -0400 Message-Id: <997465381.30504.77.camel@ransom> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dave- [warning long on data, short on answers] i've got a similar setup on a uniprocessor linux box serving to 3 IRIX 6.5.12m clients. i have not seen that behavior, but the nfs server is hardly loaded. i did use all of trond's nfs patches from http://www.fys.uio.no/~trondmy/src/2.4.6/linux-2.4.6-NFS_ALL.dif a simple test seems to work okay: irix-nfs-client$ dd if=/dev/zero of=irixnfstest bs=1048576 count=500 xfs-nfs-server$ uname -a Linux xfs-nfs-server 2.4.7-pre3-xfs #7 Thu Jul 5 20:38:47 EDT 2001 i686 unknown xfs-nfs-server$ uptime 11:18am up 35 days, 14:27, 1 user, load average: 0.00, 0.00, 0.01 now for the interesting part. i DO see similar behavior with a stock 2.4.3 kernel exporting only ext2 filesystems. i have seen both the "burstiness" and the NFS server hiccups. this nfs server is heavily loaded, and serves a software raid 0. there are 96 linux 2.4.x nfs clients attached to this nfs server. this server does not have trond's patches applied. ext2-nfs-server$ uname -a Linux ext2-nfs-server 2.4.3 #3 SMP Thu Apr 5 18:49:58 EDT 2001 i686 unknown ext2-nfs-server$ uptime 11:26am up 8 days, 18:07, 6 users, load average: 4.31, 4.47, 4.47 i was thinking it had more to do with me eepro100 drivers screwing up than anything. because i would get "eth1: card reports no resources." messages preceeding those nfs errors. i never really worried about it because its a production machine so i couldnt do any real testing on it, furthermore it seems to heal itself after a little while. also, i am currently testing an smp dell poweredge 2500 box with a large dell hw raid volume, so if that matches your hardware i may be able to see if i can reproduce your problem? hope this helps or at least doesn't hurt. ;) rob. On 10 Aug 2001 10:47:21 -0400, Dave Sill wrote: > I'm running 2.4.7-pre3-xfs checked out from CVS on July 11 on a > 2-processor Dell server. I'm serving a 200 GB hardware RAID XFS > filesystem to a couple of Origin 200 servers. (I had to apply a small > patch to the kernel to work around an IRIX NFS bug having to do with > getting the current working directory.) > > When I'm writing to the file system via NFS, performance is very > bursty--it'll copy 200-300 MB pretty quickly, then stop for 2-3 > minutes--during which any attempt to access the RAID, even locally, > hangs. > > The IRIX systems also frequently report that the Linux NFS server > isn't responding. For example: > > Aug 10 08:41:15 6A:daacl unix: NFS server daacsnfs not responding still trying > Aug 10 08:41:39 6A:daacl unix: NFS server daacsnfs ok > Aug 10 08:42:13 6A:daacl unix: NFS server daacsnfs not responding still trying > Aug 10 08:42:18 6A:daacl unix: NFS server daacsnfs ok > Aug 10 08:42:24 6A:daacl unix: NFS server daacsnfs not responding still trying > Aug 10 08:42:24 6A:daacl unix: NFS server daacsnfs ok > Aug 10 08:45:11 6A:daacl unix: NFS server daacsnfs not responding still trying > Aug 10 08:45:15 6A:daacl unix: NFS server daacsnfs ok > > (daacsnfs is the Linux box, daacl is an IRIX box) > > Any ideas about what's wrong? > > The Linux server also has a 200 GB e2fs filesystem that doesn't > exhibit the same behavior. > > -Dave From owner-linux-xfs@oss.sgi.com Fri Aug 10 11:28:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AISEO19478 for linux-xfs-outgoing; Fri, 10 Aug 2001 11:28:14 -0700 Received: from monmouth.edu (227e.dmz.monmouth.edu [206.30.71.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AISCV19459 for ; Fri, 10 Aug 2001 11:28:12 -0700 Received: by monmouth.edu; id OAA06002; Fri, 10 Aug 2001 14:29:02 -0400 (EDT) Received: from cc247150-a.union1.nj.home.com(24.6.72.45) by webshield.monmouth.edu via csmap (V4.1) id srcAAAupaiUl; Fri, 10 Aug 01 14:29:00 -0400 From: "Robert Carsey" To: Subject: NFS locking ? Date: Fri, 10 Aug 2001 14:28:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a peculiar problem.. I am running a 2.4.7 machine as an NFS server. Under an LVM disk group, I created two logical drives -- one formatted with XFS, the other with EXT2. I then exported these two drives to my Tru64 v5.1 machine. I made two user accounts, one having a homedir on the nfs mounted ext2 share, the other's homedir on the XFS share. On each account, I went into ELM, read a message, hit > to save the message to a folder. On the account that was using NFS mounted XFS, I got this error message: Couldn't lock folder /ua/rcarsey/Mail/rcarsey! While the account whose homedir on EXT2 over NFS worked fine. This is how I exported the filesystems: [root@netapp2 moncol]# exportfs -v /data/moncol-ext moncol.monmouth.edu(rw,async,wdelay,insecure,no_root_squash) /data/moncol/ua moncol.monmouth.edu(rw,async,wdelay,insecure,no_root_squash) From owner-linux-xfs@oss.sgi.com Fri Aug 10 11:31:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AIVjY19629 for linux-xfs-outgoing; Fri, 10 Aug 2001 11:31:45 -0700 Received: from mail1.home.nl (mail1.home.nl [213.51.129.225]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AIVfV19610 for ; Fri, 10 Aug 2001 11:31:42 -0700 Received: from moolenaar.net ([212.120.77.84]) by mail1.home.nl (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010810183132.OVSP10892.mail1.home.nl@moolenaar.net>; Fri, 10 Aug 2001 20:31:32 +0200 Received: from masaka.moolenaar.net (localhost.moolenaar.net [127.0.0.1]) by moolenaar.net (8.11.1/8.11.1) with ESMTP id f7AIVUK06594; Fri, 10 Aug 2001 20:31:30 +0200 (CEST) (envelope-from Bram@moolenaar.net) Message-Id: <200108101831.f7AIVUK06594@moolenaar.net> To: Seth Mos In-Reply-To: <4.3.2.7.2.20010810161950.032a4c68@pop.xs4all.nl> Subject: Re: vim file write mode on journaling fs. Cc: Linux XFS Mailing List From: Bram Moolenaar Date: Fri, 10 Aug 2001 20:31:30 +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > >Calling fsync() after writing a file would reduce the chance to lose data, > >but it also makes Vim slower and increase the system load. > > Is there an option within vi to use this as a "Safe mode". Not at the moment. > Observation has revealed that the data is only pushed out to disk after 30 > seconds or so by the VM. The metadata (size and timestamp) was pushed out > to disk on exit. 30 seconds? Quite a big chance to accidentally switch off the machine then. Why doesn't it write the data out within a second or so? Assuming the harddisk is idle. > >When Vim exits the file has already been closed. It would have to be done > >each time you write a file, just before closing it. It actually doesn't > >matter if you exit Vim or not, you might just use ":w" when you go off for > >lunch and trip over the power cord. > > This produces the exact same pattern. > I opened minicom.log which had one line of text and was 35Bytes. > Added a line "test" > wrote it with :w > unplug. I suppose you do this while the system isn't busy with other things. The FS should be smart enough to use this idle time to start writing data to the disk. > After reboot the file is: > > [seth@lsautom seth]$ ll minicom.log > -rw-r--r-- 1 seth staff 42 Aug 10 17:37 minicom.log > > [seth@lsautom seth]$ cat -v minicom.log > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@[seth@lsautom > seth]$ > > So the metadata was written but the data never got there. And the old data also isn't there. I suppose the FS assigns another disk block to the file. That is actually part of the problem: The FS flushes the meta data, and thereby clears the file. Until the time the data is actually written, you have a very big danger of losing your data. I would call this "taking a risk" in the FS. The time between the writing of the meta data and the file contents should be minimized to reduce the risk. > vi -r minicom.log did contain the valid data. So why was the .swp written > out but the original file not! The swap file is synced, because Vim assumes that using the original file plus the swap file is enough to restore the text at the point you are editing. The swap file only stores the changes, thus it wouldn't need to be as big as the original file (unless you do a ":preserve" or Vim discovers the original file is gone). Thus syncing the swap file is less of a performance hit (on average). I wonder why the swap file wasn't deleted. Vim must have deleted it, and if the metadata for the text file was flushed, why wasn't the swap file metadata flushed? Vim assumes that as soon as the file has been written, it's safe to delete the swap file. And when you didn't set the 'backup' option, the backup file is also removed at that point. For when you have a "risky" FS a sync would indeed be useful. Or make sure you use a backup file (although, if you write the file twice within those 30 seconds the backup file probably also isn't useful). I doubt that adding the sync in Vim will be that helpful. You have the same problem with doing "cp" and then deleting the original file. In fact, any program that writes a file would run into this problem. Are you going to suggest every relevant application has to call fsync()? You might want to add a call to fsync() inside close(). Well, wouldn't need it for temp files. > calling sync manually after exit gets it to disk for sure. > > Waiting 10 seconds before pulling the power was not enough to get it to disk. That should be solved by the filesystem. Doesn't make sense to keep dirty data while the system is idle. -- A computer programmer is a device for turning requirements into undocumented features. It runs on cola, pizza and Dilbert cartoons. Bram Moolenaar /// Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// From owner-linux-xfs@oss.sgi.com Fri Aug 10 11:46:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AIkGV19965 for linux-xfs-outgoing; Fri, 10 Aug 2001 11:46:16 -0700 Received: from mail.levigo.de (mail.levigo.de [193.197.156.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AIkCV19946 for ; Fri, 10 Aug 2001 11:46:12 -0700 Received: from levigo.de (zoidberg.cogito.de [193.197.156.88]) by mail.levigo.de (Postfix) with ESMTP id AF8567E0E for ; Fri, 10 Aug 2001 20:44:50 +0200 (CEST) Message-ID: <3B742BF2.4443EE06@levigo.de> Date: Fri, 10 Aug 2001 20:46:10 +0200 From: Klaus Rein Organization: levigo systems gmbh X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: strange nfs... References: <3B704280.AF4A482F@levigo.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A few self comments: 1.) when the files have been written via nfs 'du' reports the wrong sizes also on the server file system 2.) after copying such a wrong reported file the size of the copy is reported ok 3.) it seems that the wrong reported file sizes are always multiples of 64k. Below is an example from ./linux.pass.15/Documentation I do not have any idea whhat the problem might be... Klaus. ----------8<--------------------8<--------------------8<---------- # du -sk linux.pass.15/Documentation/* 64 linux.pass.15/Documentation/00-INDEX 64 linux.pass.15/Documentation/BUG-HUNTING 192 linux.pass.15/Documentation/CVS 64 linux.pass.15/Documentation/Changes 64 linux.pass.15/Documentation/CodingStyle 844 linux.pass.15/Documentation/Configure.help 64 linux.pass.15/Documentation/DMA-mapping.txt 1476 linux.pass.15/Documentation/DocBook 64 linux.pass.15/Documentation/IO-mapping.txt 64 linux.pass.15/Documentation/IRQ-affinity.txt 64 linux.pass.15/Documentation/LVM-HOWTO 64 linux.pass.15/Documentation/README.DAC960 64 linux.pass.15/Documentation/README.moxa 64 linux.pass.15/Documentation/README.nsp_cs.eng 64 linux.pass.15/Documentation/SAK.txt 64 linux.pass.15/Documentation/SubmittingDrivers 64 linux.pass.15/Documentation/SubmittingPatches 64 linux.pass.15/Documentation/VGA-softcursor.txt 2244 linux.pass.15/Documentation/arm 64 linux.pass.15/Documentation/binfmt_misc.txt 64 linux.pass.15/Documentation/cachetlb.txt 64 linux.pass.15/Documentation/cciss.txt 1156 linux.pass.15/Documentation/cdrom 64 linux.pass.15/Documentation/computone.txt 64 linux.pass.15/Documentation/cpqarray.txt 256 linux.pass.15/Documentation/cris 128 linux.pass.15/Documentation/devices.txt 64 linux.pass.15/Documentation/digiboard.txt 64 linux.pass.15/Documentation/digiepca.txt 64 linux.pass.15/Documentation/dnotify.txt 64 linux.pass.15/Documentation/exception.txt 900 linux.pass.15/Documentation/fb 2244 linux.pass.15/Documentation/filesystems 64 linux.pass.15/Documentation/floppy.txt 64 linux.pass.15/Documentation/ftape.txt 64 linux.pass.15/Documentation/hayes-esp.txt 64 linux.pass.15/Documentation/highuid.txt 708 linux.pass.15/Documentation/i2c 384 linux.pass.15/Documentation/i386 64 linux.pass.15/Documentation/i810_rng.txt 320 linux.pass.15/Documentation/ia64 64 linux.pass.15/Documentation/ide.txt 64 linux.pass.15/Documentation/initrd.txt 64 linux.pass.15/Documentation/ioctl-number.txt 64 linux.pass.15/Documentation/isapnp.txt 1668 linux.pass.15/Documentation/isdn 64 linux.pass.15/Documentation/java.txt 64 linux.pass.15/Documentation/joystick-api.txt 64 linux.pass.15/Documentation/joystick-parport.txt 64 linux.pass.15/Documentation/joystick.txt 512 linux.pass.15/Documentation/kbuild 704 linux.pass.15/Documentation/kdb 64 linux.pass.15/Documentation/kernel-doc-nano-HOWTO.txt 64 linux.pass.15/Documentation/kernel-docs.txt 64 linux.pass.15/Documentation/kernel-parameters.txt 64 linux.pass.15/Documentation/kmod.txt 64 linux.pass.15/Documentation/locks.txt 64 linux.pass.15/Documentation/logo.gif 64 linux.pass.15/Documentation/logo.txt 384 linux.pass.15/Documentation/m68k 64 linux.pass.15/Documentation/magic-number.txt 64 linux.pass.15/Documentation/mandatory.txt 64 linux.pass.15/Documentation/mca.txt 64 linux.pass.15/Documentation/md.txt 64 linux.pass.15/Documentation/memory.txt 320 linux.pass.15/Documentation/mips 64 linux.pass.15/Documentation/mkdev.cciss 64 linux.pass.15/Documentation/mkdev.ida 64 linux.pass.15/Documentation/modules.txt 64 linux.pass.15/Documentation/moxa-smartio 64 linux.pass.15/Documentation/mtrr.txt 64 linux.pass.15/Documentation/nbd.txt 4484 linux.pass.15/Documentation/networking 64 linux.pass.15/Documentation/nfsroot.txt 64 linux.pass.15/Documentation/nmi_watchdog.txt 64 linux.pass.15/Documentation/oops-tracing.txt 64 linux.pass.15/Documentation/paride.txt 512 linux.pass.15/Documentation/parisc 64 linux.pass.15/Documentation/parport-lowlevel.txt 64 linux.pass.15/Documentation/parport.txt 64 linux.pass.15/Documentation/pci.txt 64 linux.pass.15/Documentation/pcwd-watchdog.txt 64 linux.pass.15/Documentation/pm.txt 256 linux.pass.15/Documentation/power 576 linux.pass.15/Documentation/powerpc 64 linux.pass.15/Documentation/ramdisk.txt 64 linux.pass.15/Documentation/riscom8.txt 64 linux.pass.15/Documentation/rtc.txt 836 linux.pass.15/Documentation/s390 64 linux.pass.15/Documentation/scsi-generic.txt 64 linux.pass.15/Documentation/scsi.txt 64 linux.pass.15/Documentation/serial-console.txt 64 linux.pass.15/Documentation/sgi-visws.txt 64 linux.pass.15/Documentation/smart-config.txt 64 linux.pass.15/Documentation/smp.tex 64 linux.pass.15/Documentation/smp.txt 64 linux.pass.15/Documentation/sonypi.txt 3076 linux.pass.15/Documentation/sound 256 linux.pass.15/Documentation/sparc 64 linux.pass.15/Documentation/specialix.txt 64 linux.pass.15/Documentation/spinlocks.txt 64 linux.pass.15/Documentation/stallion.txt 64 linux.pass.15/Documentation/svga.txt 64 linux.pass.15/Documentation/sx.txt 512 linux.pass.15/Documentation/sysctl 64 linux.pass.15/Documentation/sysrq.txt 256 linux.pass.15/Documentation/telephony 64 linux.pass.15/Documentation/unicode.txt 1476 linux.pass.15/Documentation/usb 1736 linux.pass.15/Documentation/video4linux 384 linux.pass.15/Documentation/vm 64 linux.pass.15/Documentation/watchdog.txt 64 linux.pass.15/Documentation/xterm-linux.xpm 64 linux.pass.15/Documentation/zorro.txt From owner-linux-xfs@oss.sgi.com Fri Aug 10 11:58:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AIwBH20224 for linux-xfs-outgoing; Fri, 10 Aug 2001 11:58:11 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AIw7V20205 for ; Fri, 10 Aug 2001 11:58:08 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA15848; Fri, 10 Aug 2001 20:58:03 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id UAA27161; Fri, 10 Aug 2001 20:58:02 +0200 (CEST) Date: Fri, 10 Aug 2001 20:58:02 +0200 (CEST) From: Seth Mos To: Bram Moolenaar cc: Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. In-Reply-To: <200108101831.f7AIVUK06594@moolenaar.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 10 Aug 2001, Bram Moolenaar wrote: > Seth Mos wrote: > > 30 seconds? Quite a big chance to accidentally switch off the machine then. > Why doesn't it write the data out within a second or so? Assuming the > harddisk is idle. It was completely idle and no disk IO at all. > > >When Vim exits the file has already been closed. It would have to be done > > >each time you write a file, just before closing it. It actually doesn't > > >matter if you exit Vim or not, you might just use ":w" when you go off for > > >lunch and trip over the power cord. > > > > This produces the exact same pattern. > > I opened minicom.log which had one line of text and was 35Bytes. > > Added a line "test" > > wrote it with :w > > unplug. > > I suppose you do this while the system isn't busy with other things. The FS > should be smart enough to use this idle time to start writing data to the disk. Well, if I am correct the VM should push harder. But this would be masking the problem. > > After reboot the file is: > > > > [seth@lsautom seth]$ ll minicom.log > > -rw-r--r-- 1 seth staff 42 Aug 10 17:37 minicom.log > > > > [seth@lsautom seth]$ cat -v minicom.log > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@[seth@lsautom > > seth]$ > > > > So the metadata was written but the data never got there. > > And the old data also isn't there. I suppose the FS assigns another disk > block to the file. That is actually part of the problem: The FS flushes the > meta data, and thereby clears the file. Until the time the data is actually > written, you have a very big danger of losing your data. I would call this > "taking a risk" in the FS. The time between the writing of the meta data and > the file contents should be minimized to reduce the risk. > > > vi -r minicom.log did contain the valid data. So why was the .swp written > > out but the original file not! > > The swap file is synced, because Vim assumes that using the original file plus > the swap file is enough to restore the text at the point you are editing. The > swap file only stores the changes, thus it wouldn't need to be as big as the > original file (unless you do a ":preserve" or Vim discovers the original file > is gone). Thus syncing the swap file is less of a performance hit (on > average). One sync exit wouldn't make that much of difference, You can only exit a program once :-) > I wonder why the swap file wasn't deleted. Vim must have deleted it, and if > the metadata for the text file was flushed, why wasn't the swap file metadata > flushed? I don't know but the swapfile had not the changes but was a exact copy of the same file. > Vim assumes that as soon as the file has been written, it's safe to delete the > swap file. And when you didn't set the 'backup' option, the backup file is > also removed at that point. For when you have a "risky" FS a sync would > indeed be useful. Or make sure you use a backup file (although, if you write > the file twice within those 30 seconds the backup file probably also isn't > useful). So the deletion of the swap file probably is buffered. That might be the reason it was not deleted. Although XFS uses synchronous delete operations. > I doubt that adding the sync in Vim will be that helpful. You have the same > problem with doing "cp" and then deleting the original file. In fact, any > program that writes a file would run into this problem. Are you going to > suggest every relevant application has to call fsync()? You might want to add > a call to fsync() inside close(). Well, wouldn't need it for temp files. The thing is that the only application that people have managed to produce NULL character files with so far has been vim :-/ If I edit a file with pico it is in one piece if I save it. I will scavenge the pine sources to see what pico is doing. No others files on the system are damaged in this same way. > > calling sync manually after exit gets it to disk for sure. > > > > Waiting 10 seconds before pulling the power was not enough to get it to disk. > > That should be solved by the filesystem. Doesn't make sense to keep dirty > data while the system is idle. Weird eh. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 10 12:01:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AJ1EZ20421 for linux-xfs-outgoing; Fri, 10 Aug 2001 12:01:14 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AJ1CV20402 for ; Fri, 10 Aug 2001 12:01:12 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA16427; Fri, 10 Aug 2001 21:01:11 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA27369; Fri, 10 Aug 2001 21:01:11 +0200 (CEST) Date: Fri, 10 Aug 2001 21:01:10 +0200 (CEST) From: Seth Mos To: Klaus Rein cc: linux-xfs@oss.sgi.com Subject: Re: strange nfs... In-Reply-To: <3B742BF2.4443EE06@levigo.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 10 Aug 2001, Klaus Rein wrote: > A few self comments: > > 1.) when the files have been written via nfs 'du' reports the wrong > sizes also on the server file system > > 2.) after copying such a wrong reported file the size of the copy > is reported ok > > 3.) it seems that the wrong reported file sizes are always multiples > of 64k. Below is an example from ./linux.pass.15/Documentation > > I do not have any idea whhat the problem might be... XFS pre allocates pieces of disk to reduce fragmentation. After time this will be returned. It is a feature :-) Can't come up with the exact message, try the searchable mail archive. It has come up before. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 10 13:43:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AKhcS26021 for linux-xfs-outgoing; Fri, 10 Aug 2001 13:43:38 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AKhZV26001 for ; Fri, 10 Aug 2001 13:43:36 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA00484; Fri, 10 Aug 2001 22:43:34 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA03962; Fri, 10 Aug 2001 22:43:34 +0200 (CEST) Date: Fri, 10 Aug 2001 22:43:34 +0200 (CEST) From: Seth Mos To: Bram Moolenaar cc: Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. In-Reply-To: <200108101958.f7AJwmv07495@moolenaar.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 10 Aug 2001, Bram Moolenaar wrote: > > Seth Mos wrote: > > > One sync exit wouldn't make that much of difference, You can only exit a > > program once :-) > > You wouldn't want to sync the whole disk, just the files that Vim wrote. > Would require remembering which files were written. And you would want the > sync to happen when Vim doesn't exit anyway. No, if the syncing is to be > done, it's better to do it immediately when the file was written. I agree. > > > I wonder why the swap file wasn't deleted. Vim must have deleted it, and > > > if the metadata for the text file was flushed, why wasn't the swap file > > > metadata flushed? > > > > I don't know but the swapfile had not the changes but was a exact copy of > > the same file. > > Do you mean after recovery, or did you look in the swapfile itself? When Vim > overwrites the original file, the swap file is flushed, because it can't use > the original file to recover from then. That does create overhead, I don't > see how that can be avoided. In this case it indeed helps to recover your > text. After recovery. I can recover the whole file with vi -r. So somehow the entire buffer ended up there iinstead of the changes. > > The thing is that the only application that people have managed to > > produce NULL character files with so far has been vim :-/ > > If I edit a file with pico it is in one piece if I save it. I will > > scavenge the pine sources to see what pico is doing. > > Does it only happen when overwriting an existing file? I would expect the > same to happen when writing a new file. E.g. when using: I asume this is the case. > cp file1 file2 > rm file1 > > Could you end up with an invalid file2 while file1 has been deleted already? I will try this in a moment. Quiting my ssh session first :-) No journaling fs can recover that. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 10 14:00:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AL08H26836 for linux-xfs-outgoing; Fri, 10 Aug 2001 14:00:08 -0700 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 f7AL06V26817 for ; Fri, 10 Aug 2001 14:00:06 -0700 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 f7AL5eW01152 for ; Fri, 10 Aug 2001 14:05:40 -0700 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 PAA2598274 for ; Fri, 10 Aug 2001 15:58:45 -0500 (CDT) 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 PAA08788 for ; Fri, 10 Aug 2001 15:58:45 -0500 (CDT) From: eric@sgi.com Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7AKtTq12079; Fri, 10 Aug 2001 15:55:29 -0500 Message-Id: <200108102055.f7AKtTq12079@stout.americas.sgi.com> Date: Fri, 10 Aug 2001 15:55:29 -0500 Subject: TAKE - set inode ops in xfs_attrctl_by_handle Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Apparently it's possible to get a fresh inode via xfs_attrctl_by_handle, that has no inode->i_op->attrctl set. This would cause xfsdump to segfault (to try this, attrctl a device file, unmount & remount the filesystem, then xfsdump this filesystem - thanks to Harrison Xing). I've added linvfs_set_inode_ops and linvfs_revalidate_core calls on the inode in xfs_attrctl_by_handle to avoid this. Note that this may set the ops twice in some cases, though, since for example xfsdump calls xfs_open_by_handle on regular files before xfs_attrctl_by_handle, and the inode ops get set in both places. I don't think this is the end of the world, though, and it's certainly better than never setting it. :) Date: Fri Aug 10 13:49:41 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100561a linux/fs/xfs/linux/xfs_ioctl.c - 1.45 - set inode ops in xfs_attrctl_by_handle From owner-linux-xfs@oss.sgi.com Fri Aug 10 14:20:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ALKMM27883 for linux-xfs-outgoing; Fri, 10 Aug 2001 14:20:22 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ALKJV27857 for ; Fri, 10 Aug 2001 14:20:19 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA16606; Fri, 10 Aug 2001 23:20:15 +0200 (CEST) Message-Id: <4.3.2.7.2.20010810231323.03370de0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Aug 2001 23:19:46 +0200 To: Bram Moolenaar From: Seth Mos Subject: Re: vim file write mode on journaling fs. Cc: Linux XFS Mailing List In-Reply-To: References: <200108101958.f7AJwmv07495@moolenaar.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:43 10-8-2001 +0200, Seth Mos wrote: > > Does it only happen when overwriting an existing file? I would expect the > > same to happen when writing a new file. E.g. when using: > >I asume this is the case. > > > cp file1 file2 > > rm file1 > > > > Could you end up with an invalid file2 while file1 has been deleted > already? The following script was used. #!/bin/sh echo Test > file1 cp file1 file2 rm file1 When the script completes I hit the big red switch and sure enough. After recovery the file1 does not exist (that is ok) but file2 is empty and does not have data but it does have a size of 5 bytes. So something is biting us. I would expect file2 to be non existant (because it didn't get written yet or the correct file. This is in between. My brain is starting to hurt. Cheers Seth -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Aug 10 14:24:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ALOGB28193 for linux-xfs-outgoing; Fri, 10 Aug 2001 14:24:16 -0700 Received: from neutral.verbum.org (postfix@dhcp233054.columbus.rr.com [204.210.233.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ALOEV28171 for ; Fri, 10 Aug 2001 14:24:14 -0700 Received: from space-ghost.verbum.org (space-ghost.verbum.org [192.168.5.90]) by neutral.verbum.org (Postfix (Debian/GNU)) with ESMTP id 20248F5A2 for ; Fri, 10 Aug 2001 17:22:30 -0400 (EDT) Received: by space-ghost.verbum.org (Postfix (Debian/GNU), from userid 1000) id 4E8F0622EE0; Fri, 10 Aug 2001 17:24:05 -0400 (EDT) To: linux-xfs@oss.sgi.com Subject: Re: vim file write mode on journaling fs. References: X-Attribution: Colin X-Face: %'w-_>8Mj2_'=;I$myE#]G"'D>x3CY_rk,K06:mXFUvWy>;3I"BW3_-MAiUby{O(mn"wV@m dd`)Vk[27^^Sa Date: Fri, 10 Aug 2001 17:24:04 -0400 In-Reply-To: (Seth Mos's message of "Fri, 10 Aug 2001 20:58:02 +0200 (CEST)") Message-ID: <87lmkrbocr.church.of.emacs@space-ghost.verbum.org> Lines: 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos writes: > The thing is that the only application that people have managed to > produce NULL character files with so far has been vim :-/ It happens to me with Emacs, as well. See: From owner-linux-xfs@oss.sgi.com Fri Aug 10 15:00:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AM0aA30230 for linux-xfs-outgoing; Fri, 10 Aug 2001 15:00:36 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AM0XV30211 for ; Fri, 10 Aug 2001 15:00:33 -0700 Received: from thebarn.com ([63.231.179.33]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7AM0RXi035204; Fri, 10 Aug 2001 17:00:27 -0500 (CDT) Message-ID: <3B7458A6.7020202@thebarn.com> Date: Fri, 10 Aug 2001 16:56:54 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: Seth Mos CC: Bram Moolenaar , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. References: <200108101958.f7AJwmv07495@moolenaar.net> <4.3.2.7.2.20010810231323.03370de0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > At 22:43 10-8-2001 +0200, Seth Mos wrote: > >> > Does it only happen when overwriting an existing file? I would >> expect the >> > same to happen when writing a new file. E.g. when using: >> >> I asume this is the case. >> >> > cp file1 file2 >> > rm file1 >> > >> > Could you end up with an invalid file2 while file1 has been deleted >> already? > > > The following script was used. > > #!/bin/sh > echo Test > file1 > cp file1 file2 > rm file1 > > When the script completes I hit the big red switch and sure enough. > After recovery the file1 does not exist (that is ok) but file2 is > empty and does not have data but it does have a size of 5 bytes. > > So something is biting us. I would expect file2 to be non existant > (because it didn't get written yet or the correct file. This is in > between. > Actually this is exactly what should happen. The remove transaction was commited to log before the rm returned (probably) upon running recovery at mount time the log was replayed and the delete recorded in all appropiate meta data. File2 was created and committed to disk thus creating an inode with 0 bytes, cp then came along and wrote 5 bytes to the file, which ofcourse is was allocated "delayed" by default BUT the size update (being not logged... see previous email) was written directly to the inode, now you have an inode with size but no extents. Normally the flush daemons eventually come along and convert all "delayed" allocations to real extents and write them to disk, but when you wack the power before this happens you end up with a file with no extents thus a "hole". This is not an inconsitency in the FS just an inconsitency in file data, which as we all know is not something that can be guarenteed without data logging. From owner-linux-xfs@oss.sgi.com Fri Aug 10 16:14:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ANEKD02293 for linux-xfs-outgoing; Fri, 10 Aug 2001 16:14:20 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ANEIV02274 for ; Fri, 10 Aug 2001 16:14:18 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA10398 for ; Fri, 10 Aug 2001 16:14:03 -0700 (PDT) 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 QAA97383 for ; Fri, 10 Aug 2001 16:13:45 -0700 (PDT) Message-ID: <3B7469F5.71CF1257@sgi.com> Date: Fri, 10 Aug 2001 18:10:45 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: TAKE - set inode ops in xfs_attrctl_by_handle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk For some reason my workstation doesn't like to send take messages... sorry if this shows up 2x. If we get into xfs_attrctl_by_handle from scratch, and wind up with a brand new inode, inode->i_op->attrctl isn't getting set. You can see this by attrctl-ing a device special file on a filesystem, remount the filesystem, and then xfsdump it - xfsdump will segfault because there's no i_op->attrctl. (Thanks to Harrison Xing.) This didn't show up on regular files, perhaps because xfsdump calls xfs_open_by_handle first on it, which sets the inode ops. Adding a call to linvfs_set_inode_ops in xfs_attrctl_by_handle may be redundant, but it's better than never setting it at all. :) Also added a sanity check for inode->i_op && inode->i_op->attrctl before trying to do anything with it. Date: Fri Aug 15:49:32 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100561a linux/fs/xfs/linux/xfs_ioctl.c - 1.45 - set inode ops in xfs_attrctl_by_handle -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Aug 10 16:17:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ANHOl02603 for linux-xfs-outgoing; Fri, 10 Aug 2001 16:17:24 -0700 Received: from mustang.centralnet.ch (mustang.centralnet.ch [193.135.146.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ANHMV02583 for ; Fri, 10 Aug 2001 16:17:22 -0700 Received: from vollmann.ch (luz33.centralnet.ch [193.246.195.33]) by mustang.centralnet.ch (8.9.3/8.9.3) with ESMTP id BAA452362 for ; Sat, 11 Aug 2001 01:17:10 +0200 (MES) Received: from two.vollmann.ch (localhost [127.0.0.1]) by vollmann.ch (8.8.6/8.8.5) with SMTP id XAA04389; Fri, 10 Aug 2001 23:16:19 GMT Message-ID: <3B746B43.41845CCC@vollmann.ch> Date: Fri, 10 Aug 2001 23:16:19 +0000 From: Detlef Vollmann Organization: vollmann engineering gmbh X-Mailer: Mozilla 3.04 (X11; U; Linux 2.2.14-5.0 i586) MIME-Version: 1.0 To: XFS list Subject: Mode of symbolic link Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, if I create a symbolic link on an XFS filesystem, it gets its mode from umask, instead of 777. I think this is wrong (on all other filesystems I tested its always 777). The problem is specially annoying as you can't change the mode of the link later, always the mode of the target gets changed :-( cheers, Detlef [dv@dwarf q]$ umask 022 [dv@dwarf q]$ echo > a [dv@dwarf q]$ ln -s a b [dv@dwarf q]$ ls -l total 4 -rw-r--r-- 1 dv users 1 Aug 11 01:18 a lrwxr-xr-x 1 dv users 1 Aug 11 01:18 b -> a [dv@dwarf q]$ chmod 777 b [dv@dwarf q]$ ls -l total 4 -rwxrwxrwx 1 dv users 1 Aug 11 01:18 a lrwxr-xr-x 1 dv users 1 Aug 11 01:18 b -> a -- Detlef Vollmann vollmann engineering gmbh Tel: +41-41-4120911 P.O. Box 5106 Fax: +41-41-4120912 CH-6000 Luzern 5 / Switzerland eMail: dv@vollmann.ch From owner-linux-xfs@oss.sgi.com Fri Aug 10 17:13:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7B0DdP06527 for linux-xfs-outgoing; Fri, 10 Aug 2001 17:13:39 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7B0DbV06507 for ; Fri, 10 Aug 2001 17:13:37 -0700 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA08345 for ; Fri, 10 Aug 2001 17:12:23 -0700 (PDT) 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 RAA72076; Fri, 10 Aug 2001 17:13:02 -0700 (PDT) Message-ID: <3B7477D8.8C2F1855@sgi.com> Date: Fri, 10 Aug 2001 19:10:00 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Detlef Vollmann CC: XFS list Subject: Re: Mode of symbolic link References: <3B746B43.41845CCC@vollmann.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Detlef Vollmann wrote: > > Hi, > if I create a symbolic link on an XFS filesystem, it gets its > mode from umask, instead of 777. I think this is wrong (on > all other filesystems I tested its always 777). > The problem is specially annoying as you can't change the > mode of the link later, always the mode of the target gets changed :-( While this may differ from other filesystems, [sandeen@Liberator sandeen]$ man symlink | grep permissions The permissions of a symbolic link are irrelevant; -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 Aug 10 17:43:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7B0hI408249 for linux-xfs-outgoing; Fri, 10 Aug 2001 17:43:18 -0700 Received: from mustang.centralnet.ch (mustang.centralnet.ch [193.135.146.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7B0hGV08228 for ; Fri, 10 Aug 2001 17:43:16 -0700 Received: from vollmann.ch (luz53.centralnet.ch [193.246.195.53]) by mustang.centralnet.ch (8.9.3/8.9.3) with ESMTP id CAA455341; Sat, 11 Aug 2001 02:43:05 +0200 (MES) Received: from two.vollmann.ch (localhost [127.0.0.1]) by vollmann.ch (8.8.6/8.8.5) with SMTP id AAA04964; Sat, 11 Aug 2001 00:36:54 GMT Message-ID: <3B747E25.69FAC55A@vollmann.ch> Date: Sat, 11 Aug 2001 00:36:53 +0000 From: Detlef Vollmann Organization: vollmann engineering gmbh X-Mailer: Mozilla 3.04 (X11; U; Linux 2.2.14-5.0 i586) MIME-Version: 1.0 To: Eric Sandeen CC: XFS list Subject: Re: Mode of symbolic link References: <3B746B43.41845CCC@vollmann.ch> <3B7477D8.8C2F1855@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: > While this may differ from other filesystems, > > [sandeen@Liberator sandeen]$ man symlink | grep permissions > The permissions of a symbolic link are irrelevant; Oops, sorry. I thought I had a test case where the permissions of the link were evaluated, but this turned out to be my mistake. Sorry again. Detlef -- Detlef Vollmann vollmann engineering gmbh Tel: +41-41-4120911 P.O. Box 5106 Fax: +41-41-4120912 CH-6000 Luzern 5 / Switzerland eMail: dv@vollmann.ch From owner-linux-xfs@oss.sgi.com Fri Aug 10 17:50:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7B0okI08803 for linux-xfs-outgoing; Fri, 10 Aug 2001 17:50:46 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7B0oiV08783 for ; Fri, 10 Aug 2001 17:50:44 -0700 Received: from there (localhost.localdomain [127.0.0.1]) by wwweasel.geeksrus.net (8.11.4/8.11.4) with SMTP id f7B0ocX06776 for ; Fri, 10 Aug 2001 20:50:38 -0400 Message-Id: <200108110050.f7B0ocX06776@wwweasel.geeksrus.net> Content-Type: text/plain; charset="iso-8859-1" From: Alan Eldridge Reply-To: alane@geeksrus.net Organization: a local lack of entropy To: XFS list Subject: Re: Mode of symbolic link Date: Fri, 10 Aug 2001 20:50:38 -0400 X-Mailer: KMail [version 1.3.1] References: <3B746B43.41845CCC@vollmann.ch> <3B7477D8.8C2F1855@sgi.com> <3B747E25.69FAC55A@vollmann.ch> In-Reply-To: <3B747E25.69FAC55A@vollmann.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Friday August 10 2001 20:36, you wrote: > Eric Sandeen wrote: > > While this may differ from other filesystems, > > > > [sandeen@Liberator sandeen]$ man symlink | grep permissions > > The permissions of a symbolic link are irrelevant; > > Oops, sorry. I thought I had a test case where the permissions > of the link were evaluated, but this turned out to be my mistake. > > OK, I know they don't matter, but I'm working with automake tonight and feel like adding fuel to the fire. Any fire. He he he. RPM's verify mode wouldn't possibly look at this, would it? Could RPM possibly be so brain damaged as to check the permissions on a symbolic link, which are defined to be meaningless?[1] [1]Could RPM be brain damaged? Does a bear ... -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sat Aug 11 12:58:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BJwYt01139 for linux-xfs-outgoing; Sat, 11 Aug 2001 12:58:34 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BJwVj01120 for ; Sat, 11 Aug 2001 12:58:31 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA25359; Sat, 11 Aug 2001 21:58:28 +0200 (CEST) Message-Id: <4.3.2.7.2.20010811215648.03d143e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 11 Aug 2001 21:58:00 +0200 To: Knut J Bjuland , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: is oss.sgi.com down In-Reply-To: <3B75DC12.AE33D7FB@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:29 11-8-2001 -0400, Knut J Bjuland wrote: >I have not been able to reach oss.sgi.com this weekend. It is down? No, if you have tcp_ecn enabled you might switch off with echo 0 >/proc/sys/net/ipv4/tcp_ecn If this is the case, a router of the ISP where oss lives needs to be upgraded. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Aug 11 13:17:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BKHFa01820 for linux-xfs-outgoing; Sat, 11 Aug 2001 13:17:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BKFuj01788 for ; Sat, 11 Aug 2001 13:15:56 -0700 Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA03146 for ; Sat, 11 Aug 2001 12:39:03 -0700 (PDT) mail_from (knutjbj@online.no) Received: from online.no (217-13-10-85.dd.nextgentel.com [217.13.10.85]) by mail.broadpark.no (Postfix) with ESMTP id 0E1797E20; Sat, 11 Aug 2001 21:35:25 +0200 (MET DST) Message-ID: <3B75DC12.AE33D7FB@online.no> Date: Sat, 11 Aug 2001 21:29:54 -0400 From: Knut J Bjuland X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-pre4-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, Seth Mos Subject: is oss.sgi.com down Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have not been able to reach oss.sgi.com this weekend. It is down? From owner-linux-xfs@oss.sgi.com Sat Aug 11 13:20:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BKK3d02037 for linux-xfs-outgoing; Sat, 11 Aug 2001 13:20:03 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BKJxj02016 for ; Sat, 11 Aug 2001 13:20:00 -0700 Received: from mail3.home.nl (mail3.home.nl [213.51.129.227]) 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 DAA02660 for ; Sat, 11 Aug 2001 03:44:04 -0700 (PDT) mail_from (Bram@moolenaar.net) Received: from moolenaar.net ([212.120.77.84]) by mail3.home.nl (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010811114134.EJQD23099.mail3.home.nl@moolenaar.net>; Sat, 11 Aug 2001 12:41:34 +0100 Received: from masaka.moolenaar.net (localhost.moolenaar.net [127.0.0.1]) by moolenaar.net (8.11.1/8.11.1) with ESMTP id f7BAgLt00682; Sat, 11 Aug 2001 12:42:21 +0200 (CEST) (envelope-from Bram@moolenaar.net) Message-Id: <200108111042.f7BAgLt00682@moolenaar.net> To: Russell Cattelan In-Reply-To: <3B7458A6.7020202@thebarn.com> Cc: Seth Mos CC: Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. From: Bram Moolenaar Date: Sat, 11 Aug 2001 12:42:21 +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > > The following script was used. > > > > #!/bin/sh > > echo Test > file1 > > cp file1 file2 > > rm file1 > > > > When the script completes I hit the big red switch and sure enough. > > After recovery the file1 does not exist (that is ok) but file2 is > > empty and does not have data but it does have a size of 5 bytes. > > > > So something is biting us. I would expect file2 to be non existant > > (because it didn't get written yet or the correct file. This is in > > between. I'm glad Seth found an example with basic commands which shows Vim isn't really doing something strange. > Actually this is exactly what should happen. > The remove transaction was commited to log before the rm returned > (probably) upon running recovery at mount time the log was replayed and the > delete recorded in all appropiate meta data. > > > File2 was created and committed to disk thus creating an inode with 0 bytes, > cp then came along and wrote 5 bytes to the file, which ofcourse is was > allocated "delayed" > by default BUT the size update (being not logged... see previous email) > was written directly > to the inode, now you have an inode with size but no extents. > Normally the flush daemons eventually come along and convert all > "delayed" allocations > to real extents and write them to disk, but when you wack the power > before this happens > you end up with a file with no extents thus a "hole". > > > This is not an inconsitency in the FS just an inconsitency in file data, > which as we all know is not something that can be guarenteed without data > logging. Of course I wouldn't expect data to be restored when I switch off a system while it's busy with something. But when I copy a file, wait a couple of seconds and then switch off the system, there is no reason the file is gone. That the FS causes reordering of disk actions is understandable, but it should take care that the negative effects of this are minimized. It should detect that the disk isn't doing anything and that there is a perfect chance to start writing dirty data in the cache. A fixed timeout of 30 seconds or even 1 second sounds like a lazy programmer that didn't want to implement a satisfactory solution. Summary: I consider this to be a problem with the filesystem, not with Vim. For people that want to be sure their file is synced, the ":!sync" command can be used. -- I'm sure that I asked CBuilder to do a "full" install. Looks like I got a "fool" install, instead. Charles E Campbell, Jr, PhD /// Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// From owner-linux-xfs@oss.sgi.com Sat Aug 11 13:30:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BKU3Y02392 for linux-xfs-outgoing; Sat, 11 Aug 2001 13:30:03 -0700 Received: from gwyn.tux.org (ident-user@gwyn.tux.org [207.96.122.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BKU0j02361 for ; Sat, 11 Aug 2001 13:30:00 -0700 Received: (from timball@localhost) by gwyn.tux.org (8.9.3/8.9.1) id QAA26582; Sat, 11 Aug 2001 16:29:57 -0400 Date: Sat, 11 Aug 2001 16:29:57 -0400 From: Timothy Ball To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: is oss.sgi.com down Message-ID: <20010811162957.F13253@gwyn.tux.org> References: <3B75DC12.AE33D7FB@online.no> <4.3.2.7.2.20010811215648.03d143e8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20010811215648.03d143e8@pop.xs4all.nl> User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Aug 11, 2001 at 09:58:00PM +0200, Seth Mos wrote: > At 21:29 11-8-2001 -0400, Knut J Bjuland wrote: > >I have not been able to reach oss.sgi.com this weekend. It is down? > > No, if you have tcp_ecn enabled you might switch off with > > echo 0 >/proc/sys/net/ipv4/tcp_ecn > > If this is the case, a router of the ISP where oss lives needs to be > upgraded. Uhh... I can't ping it either from any network I'm on including different OS'ed machines. --timball -- GPG key available on pgpkeys.mit.edu pub 1024R/CFF85605 1999-06-10 Timothy L. Ball Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD From owner-linux-xfs@oss.sgi.com Sat Aug 11 13:31:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BKVXT02519 for linux-xfs-outgoing; Sat, 11 Aug 2001 13:31:33 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BKVVj02496 for ; Sat, 11 Aug 2001 13:31:31 -0700 Received: from mail1.home.nl (mail1.home.nl [213.51.129.225]) 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 WAA03471 for ; Fri, 10 Aug 2001 22:33:25 -0700 (PDT) mail_from (Bram@moolenaar.net) Received: from moolenaar.net ([212.120.77.84]) by mail1.home.nl (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010810195752.PIES10892.mail1.home.nl@moolenaar.net>; Fri, 10 Aug 2001 21:57:52 +0200 Received: from masaka.moolenaar.net (localhost.moolenaar.net [127.0.0.1]) by moolenaar.net (8.11.1/8.11.1) with ESMTP id f7AJwmv07495; Fri, 10 Aug 2001 21:58:48 +0200 (CEST) (envelope-from Bram@moolenaar.net) Message-Id: <200108101958.f7AJwmv07495@moolenaar.net> To: Seth Mos cc: Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. In-Reply-To: From: Bram Moolenaar Date: Fri, 10 Aug 2001 21:58:48 +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > One sync exit wouldn't make that much of difference, You can only exit a > program once :-) You wouldn't want to sync the whole disk, just the files that Vim wrote. Would require remembering which files were written. And you would want the sync to happen when Vim doesn't exit anyway. No, if the syncing is to be done, it's better to do it immediately when the file was written. > > I wonder why the swap file wasn't deleted. Vim must have deleted it, and > > if the metadata for the text file was flushed, why wasn't the swap file > > metadata flushed? > > I don't know but the swapfile had not the changes but was a exact copy of > the same file. Do you mean after recovery, or did you look in the swapfile itself? When Vim overwrites the original file, the swap file is flushed, because it can't use the original file to recover from then. That does create overhead, I don't see how that can be avoided. In this case it indeed helps to recover your text. > The thing is that the only application that people have managed to > produce NULL character files with so far has been vim :-/ > If I edit a file with pico it is in one piece if I save it. I will > scavenge the pine sources to see what pico is doing. Does it only happen when overwriting an existing file? I would expect the same to happen when writing a new file. E.g. when using: cp file1 file2 rm file1 Could you end up with an invalid file2 while file1 has been deleted already? -- ARTHUR: I am your king! WOMAN: Well, I didn't vote for you. ARTHUR: You don't vote for kings. WOMAN: Well, 'ow did you become king then? The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// From owner-linux-xfs@oss.sgi.com Sat Aug 11 13:48:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BKmoa02879 for linux-xfs-outgoing; Sat, 11 Aug 2001 13:48:50 -0700 Received: from mailout02.sul.t-online.de (mailout02.sul.t-online.com [194.25.134.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BKmlj02860 for ; Sat, 11 Aug 2001 13:48:47 -0700 Received: from fwd05.sul.t-online.de by mailout02.sul.t-online.de with smtp id 15VfgZ-0000hx-04; Sat, 11 Aug 2001 22:48:43 +0200 Received: from there (340024412816-0001@[217.230.5.38]) by fwd05.sul.t-online.com with smtp id 15VfgQ-14X0euC; Sat, 11 Aug 2001 22:48:34 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Hasch@t-online.de (Juergen Hasch) To: Timothy Ball Subject: Re: is oss.sgi.com down Date: Sat, 11 Aug 2001 22:49:11 +0200 X-Mailer: KMail [version 1.2.9] Cc: linux-xfs@oss.sgi.com References: <3B75DC12.AE33D7FB@online.no> <4.3.2.7.2.20010811215648.03d143e8@pop.xs4all.nl> <20010811162957.F13253@gwyn.tux.org> In-Reply-To: <20010811162957.F13253@gwyn.tux.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <15VfgQ-14X0euC@fwd05.sul.t-online.com> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am Samstag, 11. August 2001 22:29 schrieb Timothy Ball: > On Sat, Aug 11, 2001 at 09:58:00PM +0200, Seth Mos wrote: > > At 21:29 11-8-2001 -0400, Knut J Bjuland wrote: > > >I have not been able to reach oss.sgi.com this weekend. It is down? > > > > No, if you have tcp_ecn enabled you might switch off with > > > > echo 0 >/proc/sys/net/ipv4/tcp_ecn > > > > If this is the case, a router of the ISP where oss lives needs to be > > upgraded. > > Uhh... I can't ping it either from any network I'm on including > different OS'ed machines. Seems to be a DNS problem, try 216.32.174.27. ...Juergen From owner-linux-xfs@oss.sgi.com Sat Aug 11 13:50:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BKoGW03025 for linux-xfs-outgoing; Sat, 11 Aug 2001 13:50:16 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BKoCj03003 for ; Sat, 11 Aug 2001 13:50:13 -0700 Received: from mail3.home.nl (mail3.home.nl [213.51.129.227]) 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 LAA05917 for ; Sat, 11 Aug 2001 11:49:34 -0700 (PDT) mail_from (Bram@moolenaar.net) Received: from moolenaar.net ([212.120.77.84]) by mail3.home.nl (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010811194706.GLWV23099.mail3.home.nl@moolenaar.net>; Sat, 11 Aug 2001 20:47:06 +0100 Received: from masaka.moolenaar.net (localhost.moolenaar.net [127.0.0.1]) by moolenaar.net (8.11.1/8.11.1) with ESMTP id f7BIm1704198; Sat, 11 Aug 2001 20:48:01 +0200 (CEST) (envelope-from Bram@moolenaar.net) Message-Id: <200108111848.f7BIm1704198@moolenaar.net> To: Russell Cattelan In-Reply-To: <3B75549D.96EEE5EB@thebarn.com> CC: Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. From: Bram Moolenaar Date: Sat, 11 Aug 2001 20:48:01 +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > You have the scenario backwards, the idea of delayed allocation/write is > to reduce the amount of disk activity and to aggregate disk writes together > thus by making disk transfers more efficient. Making disk I/O more efficient is only relevant if there is quite a bit of I/O going on. In the (many) periods with little disk I/O delaying writes doesn't make much sense. This is especially relevant on a workstation. > The is no way for the kernel/filesystem to predict the type of IO a user app > is going to do, streaming, random, fast random slow random... the kernel and > FS make best guess real world average behavior predictions. Everything is > tune able of course but that requires the person running the app understands > the app's io behavior. What tools do I have that indicate to the FS how it should handle the data I have written? Can I somehow tell it to flush my data soon, but not as drastic as syncing? > > It's certainly worth the effort to implement this. > > It is implemented it's called O_SYNC. Where is this documented? I don't have it on my FreeBSD system, is this Linux specific? > > The tests done by Seth > > show that this is a real, existing problem. > > Every file system that does buffering has this problem XFS included. That's not true. Only filesystems with delayed data writes have this problem. a "normal" file system doesn't do reordering of writes and/or doesn't delay writing dirty data blocks. > > Don't look at this from the point of view of a person that knows what > > "delayed allocation/write" means, look at it from the point of view of a > > user. > > Maybe so but as a user sometimes you must understand your system to > understand why it does things, and not assume it's a bug. OK. Since I now understand how it works I will recommend every user NOT to use this kind of filesystem. The risk of losing your work is too big. Perhaps that's why FreeBSD doesn't use a journalling file system. -- ARTHUR: I command you as King of the Britons to stand aside! BLACK KNIGHT: I move for no man. The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:04:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BL4vt03306 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:04:57 -0700 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 f7BL4uj03285 for ; Sat, 11 Aug 2001 14:04:56 -0700 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 f7BGhHW17001 for ; Sat, 11 Aug 2001 09:43:17 -0700 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 LAA2684964 for ; Sat, 11 Aug 2001 11:36:19 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA35695 for ; Sat, 11 Aug 2001 11:36:18 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f7BGZMJ13527; Sat, 11 Aug 2001 11:35:22 -0500 Message-Id: <200108111635.f7BGZMJ13527@jen.americas.sgi.com> Date: Sat, 11 Aug 2001 11:35:22 -0500 Subject: TAKE - fix powerpc xfs_db output Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sat Aug 11 09:34:26 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100588a cmd/xfsprogs/db/bit.c - 1.3 - Fix big endian platform problem From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:07:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BL7Wh03478 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:07:32 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BL7Uj03433 for ; Sat, 11 Aug 2001 14:07:30 -0700 Received: from gwyn.tux.org (gwyn.tux.org [207.96.122.8]) 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 IAA01961 for ; Sat, 11 Aug 2001 08:15:05 -0700 (PDT) mail_from (timball@tux.org) Received: (from timball@localhost) by gwyn.tux.org (8.9.3/8.9.1) id LAA11620 for linux-xfs@oss.sgi.com; Sat, 11 Aug 2001 11:15:50 -0400 Date: Sat, 11 Aug 2001 11:15:50 -0400 From: Timothy Ball To: XFS Mailing List Subject: cvs down? nvidia drivers w/ devfs + xfs? Message-ID: <20010811111550.D13253@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk First off oss.sgi.com seems "not there" Second I'm having issues making the nvidia drivers work w/ devfs I don't know if this is specific to the xfs tree but since I don't use the normal kernel tree anymore it's a bit of an issue. I already editted my nvidia sources to use devfs but the compile complains about unresolved symbols... --timball -- GPG key available on pgpkeys.mit.edu pub 1024R/CFF85605 1999-06-10 Timothy L. Ball Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:07:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BL7Xj03505 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:07:33 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BL7Vj03449 for ; Sat, 11 Aug 2001 14:07:31 -0700 Received: from mail1.home.nl (mail1.home.nl [213.51.129.225]) 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 IAA02412 for ; Sat, 11 Aug 2001 08:23:10 -0700 (PDT) mail_from (Bram@moolenaar.net) Received: from moolenaar.net ([212.120.77.84]) by mail1.home.nl (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010811152031.SXBJ10892.mail1.home.nl@moolenaar.net>; Sat, 11 Aug 2001 17:20:31 +0200 Received: from masaka.moolenaar.net (localhost.moolenaar.net [127.0.0.1]) by moolenaar.net (8.11.1/8.11.1) with ESMTP id f7BFLTS03169; Sat, 11 Aug 2001 17:21:29 +0200 (CEST) (envelope-from Bram@moolenaar.net) Message-Id: <200108111521.f7BFLTS03169@moolenaar.net> To: Russell Cattelan In-Reply-To: <3B7546E0.4F491201@thebarn.com> CC: Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. From: Bram Moolenaar Date: Sat, 11 Aug 2001 17:21:29 +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > This isn't a matter of laziness or poor design it's a trade off. > If you want the benefits of delayed allocation/write then there has to > be a DELAY otherwise there would be much point, > if you want better data integrity in the event of a crash > then mount your filesystems O_SYNC and loose the performance. There is no need for such a trade-off. It is not difficult to detect that the harddisk isn't very busy and start writing out dirty data blocks then. This doesn't cause a performance drop and greatly increases reliability. It's certainly worth the effort to implement this. The tests done by Seth show that this is a real, existing problem. Don't look at this from the point of view of a person that knows what "delayed allocation/write" means, look at it from the point of view of a user. -- f y cn rd ths thn y cn hv grt jb n cmptr prgrmmng /// Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:07:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BL7Zf03549 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:07:35 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BL7Vj03460 for ; Sat, 11 Aug 2001 14:07:31 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) 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 IAA05208 for ; Sat, 11 Aug 2001 08:52:03 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7BFq2Xi043048; Sat, 11 Aug 2001 10:52:02 -0500 (CDT) Message-ID: <3B75549D.96EEE5EB@thebarn.com> Date: Sat, 11 Aug 2001 10:51:57 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bram Moolenaar CC: Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. References: <200108111521.f7BFLTS03169@moolenaar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bram Moolenaar wrote: > Russell Cattelan wrote: > > > This isn't a matter of laziness or poor design it's a trade off. > > If you want the benefits of delayed allocation/write then there has to > > be a DELAY otherwise there would be much point, > > if you want better data integrity in the event of a crash > > then mount your filesystems O_SYNC and loose the performance. > > There is no need for such a trade-off. It is not difficult to detect that the > harddisk isn't very busy and start writing out dirty data blocks then. This > doesn't cause a performance drop and greatly increases reliability. You have the scenario backwards, the idea of delayed allocation/write is to reduce the amount of disk activity and to aggregate disk writes together thus by making disk transfers more efficient. The is no way for the kernel/filesystem to predict the type of IO a user app is going to do, streaming, random, fast random slow random... the kernel and FS make best guess real world average behavior predictions. Everything is tune able of course but that requires the person running the app understands the app's io behavior. > > > It's certainly worth the effort to implement this. It is implemented it's called O_SYNC. > The tests done by Seth > show that this is a real, existing problem. Every file system that does buffering has this problem XFS included. > > > Don't look at this from the point of view of a person that knows what "delayed > allocation/write" means, look at it from the point of view of a user. Maybe so but as a user sometimes you must understand your system to understand why it does things, and not assume it's a bug. > > > -- > f y cn rd ths thn y cn hv grt jb n cmptr prgrmmng > > /// Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net \\\ > ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) > \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:12:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BLC6i03914 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:12:06 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BLC3j03839 for ; Sat, 11 Aug 2001 14:12:03 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) 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 HAA05379 for ; Sat, 11 Aug 2001 07:53:27 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7BErPXi042645; Sat, 11 Aug 2001 09:53:26 -0500 (CDT) Message-ID: <3B7546E0.4F491201@thebarn.com> Date: Sat, 11 Aug 2001 09:53:20 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bram Moolenaar CC: Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. References: <200108111042.f7BAgLt00682@moolenaar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bram Moolenaar wrote: > Russell Cattelan wrote: > > > > The following script was used. > > > > > > #!/bin/sh > > > echo Test > file1 > > > cp file1 file2 > > > rm file1 > > > > > > When the script completes I hit the big red switch and sure enough. > > > After recovery the file1 does not exist (that is ok) but file2 is > > > empty and does not have data but it does have a size of 5 bytes. > > > > > > So something is biting us. I would expect file2 to be non existant > > > (because it didn't get written yet or the correct file. This is in > > > between. > > I'm glad Seth found an example with basic commands which shows Vim isn't > really doing something strange. > > > Actually this is exactly what should happen. > > The remove transaction was commited to log before the rm returned > > (probably) upon running recovery at mount time the log was replayed and the > > delete recorded in all appropiate meta data. > > > > > > File2 was created and committed to disk thus creating an inode with 0 bytes, > > cp then came along and wrote 5 bytes to the file, which ofcourse is was > > allocated "delayed" > > by default BUT the size update (being not logged... see previous email) > > was written directly > > to the inode, now you have an inode with size but no extents. > > Normally the flush daemons eventually come along and convert all > > "delayed" allocations > > to real extents and write them to disk, but when you wack the power > > before this happens > > you end up with a file with no extents thus a "hole". > > > > > > This is not an inconsitency in the FS just an inconsitency in file data, > > which as we all know is not something that can be guarenteed without data > > logging. > > Of course I wouldn't expect data to be restored when I switch off a system > while it's busy with something. But when I copy a file, wait a couple of > seconds and then switch off the system, there is no reason the file is > gone. That the FS causes reordering of disk actions is understandable, > but it should take care that the negative effects of this are minimized. It > should detect that the disk isn't doing anything and that there is a perfect > chance to start writing dirty data in the cache. A fixed timeout of 30 > seconds or even 1 second sounds like a lazy programmer that didn't want to > implement a satisfactory solution. This isn't a matter of laziness or poor design it's a trade off. If you want the benefits of delayed allocation/write then there has to be a DELAY otherwise there would be much point, if you want better data integrity in the event of a crash then mount your filesystems O_SYNC and loose the performance. > > > Summary: I consider this to be a problem with the filesystem, not with Vim. > For people that want to be sure their file is synced, the ":!sync" command can > be used. > > -- > I'm sure that I asked CBuilder to do a "full" install. Looks like I got > a "fool" install, instead. Charles E Campbell, Jr, PhD > > /// Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net \\\ > ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) > \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:13:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BLDOq04030 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:13:24 -0700 Received: from smtp7.xs4all.nl (smtp7.xs4all.nl [194.109.127.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BLDMj04009 for ; Sat, 11 Aug 2001 14:13:22 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp7.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA28956; Sat, 11 Aug 2001 23:13:15 +0200 (CEST) Message-Id: <4.3.2.7.2.20010811231032.03d15020@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 11 Aug 2001 23:12:45 +0200 To: Hasch@t-online.de (Juergen Hasch), Timothy Ball From: Seth Mos Subject: Re: is oss.sgi.com down Cc: linux-xfs@oss.sgi.com In-Reply-To: <15VfgQ-14X0euC@fwd05.sul.t-online.com> References: <20010811162957.F13253@gwyn.tux.org> <3B75DC12.AE33D7FB@online.no> <4.3.2.7.2.20010811215648.03d143e8@pop.xs4all.nl> <20010811162957.F13253@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:49 11-8-2001 +0200, Juergen Hasch wrote: >Am Samstag, 11. August 2001 22:29 schrieb Timothy Ball: > > On Sat, Aug 11, 2001 at 09:58:00PM +0200, Seth Mos wrote: > > > At 21:29 11-8-2001 -0400, Knut J Bjuland wrote: > > > >I have not been able to reach oss.sgi.com this weekend. It is down? > > > > > > No, if you have tcp_ecn enabled you might switch off with > > > > > > echo 0 >/proc/sys/net/ipv4/tcp_ecn > > > > > > If this is the case, a router of the ISP where oss lives needs to be > > > upgraded. > > > > Uhh... I can't ping it either from any network I'm on including > > different OS'ed machines. > >Seems to be a DNS problem, try 216.32.174.27. It works for me. Note: The router they have probably does not pass icmp packets. You can't ping it but you can telnet to port 80 :-) Groet -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:24:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BLOWA04258 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:24:32 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BLOUj04239 for ; Sat, 11 Aug 2001 14:24:30 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA18550 for ; Sat, 11 Aug 2001 14:24:16 -0700 (PDT) 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 OAA72516; Sat, 11 Aug 2001 14:23:58 -0700 (PDT) Message-ID: <3B75A1B9.EE21AEC9@sgi.com> Date: Sat, 11 Aug 2001 16:20:57 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Timothy Ball CC: XFS Mailing List Subject: Re: cvs down? nvidia drivers w/ devfs + xfs? References: <20010811111550.D13253@gwyn.tux.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I had it working once w/ the devfs patch (well... as much as nvidia's binary-only driver ever worked for me...) if you have trouble w/ unresolved symbols, I'd suggest a "make mrproper" and start all over again. You can also turn devfs off if you like, of course. -Eric Timothy Ball wrote: > > First off oss.sgi.com seems "not there" > > Second I'm having issues making the nvidia drivers work w/ devfs I don't > know if this is specific to the xfs tree but since I don't use the > normal kernel tree anymore it's a bit of an issue. > > I already editted my nvidia sources to use devfs but the compile > complains about unresolved symbols... -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:28:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BLSv604399 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:28:57 -0700 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 f7BLSsj04380 for ; Sat, 11 Aug 2001 14:28:54 -0700 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 f7BLXSS17878 for ; Sat, 11 Aug 2001 14:33:29 -0700 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 QAA2660560; Sat, 11 Aug 2001 16:27:32 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA34044; Sat, 11 Aug 2001 16:27:31 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7BLQWe26468; Sat, 11 Aug 2001 16:26:32 -0500 Message-Id: <200108112126.f7BLQWe26468@jen.americas.sgi.com> To: Bram Moolenaar cc: Russell Cattelan , Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. References: <200108111848.f7BIm1704198@moolenaar.net> Comments: In-reply-to Bram Moolenaar message dated "Sat, 11 Aug 2001 20:48:01 +0200." Date: Sat, 11 Aug 2001 16:26:32 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, just picking a message to respond to from this thread. 1. It is not XFS which is deciding when to write the file data out to disk, it is Linux. The bdflush daemon is responsible for this, that 30 seconds is one of its control parameters. 2. An individual thread doing a write in XFS has no way of knowing or predicting what else may just of happened, or be about to happen on the system. You cannot say 'I will write my data now because the system is idle', there may be a couple of Gbytes of I/O about to come in from another source. 3. O_SYNC is a fairly standard flag on file open, if freebsd does not have it then it is missing a fairly major feature of filesystems. Having said that, I do not recommend using O_SYNC, it is more expensive than an fsync. 4. Anyone who is shutting down their system by pulling the plug rather than doing an orderly shutdown is asking for trouble. Yes, it is a situation we want to deal with fairly gracefully, but filesystem recovery in journaling filesystems and fsck in others is there to 'recover' from problems, not to cater to lazy users. umount is there for a reason. 5. The delayed write you talk about is the norm for ALL filesystems operating on spinning disks. If you don't delay writes in a filesystem then you will be here until Christmas responding to this email. Now XFS has delayed allocation which is different. The normal process of a write in linux is something like this: o write system call comes in, looks for space in the file, if there is none it asks the filesystem to allocate some, the data is copied into a buffer which has the disk address of this data and which is marked dirty. The write then returns - the data is NOT written to disk, nor in the case of ext2 would any of the metadata changes be written to disk. o The bdflush daemon comes along and sees buffers as being suitable for flushing, the data and metadata gets written out to disk. With XFS it looks like this: o write system call comes in looks for space in the file, if there is none it asks the filesystem for some, the filesystem records the fact that space was requested at this point in the file. A buffer is allocated as before, it is marked dirty, it is also marked delayed allocate. The write returns. o Possibly an inode flush or a log flush pushes the new inode out to disk. o The bdflush daemon comes along and sees the buffers as being delayed allocate, it calls the filesystem to allocate the space. The allocate is done, and the buffers are written out to disk. The transaction which records the extents is still in memory and will not be flushed for a few seconds yet. This last sentence is the major difference, and is probably what is biting here, the write has not really happened until this metadata makes it out to disk. We may be having some issues with how long this is taking in Linux. So the upshot of all of this is that I suspect we do have an issue, and we will get to it at some point. In the mean time there is no need to start discarding filesystems which do not behave as you want them to do if you pull the plug. Steve From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:35:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BLZNe04571 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:35:23 -0700 Received: from mailout06.sul.t-online.de (mailout06.sul.t-online.com [194.25.134.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BLZLj04552 for ; Sat, 11 Aug 2001 14:35:21 -0700 Received: from fwd05.sul.t-online.de by mailout06.sul.t-online.de with smtp id 15VgPd-0000il-01; Sat, 11 Aug 2001 23:35:17 +0200 Received: from there (340024412816-0001@[217.230.5.38]) by fwd05.sul.t-online.com with smtp id 15VgPb-2C7l44C; Sat, 11 Aug 2001 23:35:15 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Hasch@t-online.de (Juergen Hasch) To: Seth Mos , Hasch@t-online.de (Juergen Hasch), Timothy Ball Subject: Re: is oss.sgi.com down Date: Sat, 11 Aug 2001 23:35:50 +0200 X-Mailer: KMail [version 1.2.9] Cc: linux-xfs@oss.sgi.com References: <20010811162957.F13253@gwyn.tux.org> <4.3.2.7.2.20010811231032.03d15020@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20010811231032.03d15020@pop.xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <15VgPb-2C7l44C@fwd05.sul.t-online.com> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am Samstag, 11. August 2001 23:12 schrieb Seth Mos: > At 22:49 11-8-2001 +0200, Juergen Hasch wrote: > >Am Samstag, 11. August 2001 22:29 schrieb Timothy Ball: > > > On Sat, Aug 11, 2001 at 09:58:00PM +0200, Seth Mos wrote: > > > > At 21:29 11-8-2001 -0400, Knut J Bjuland wrote: > > > > >I have not been able to reach oss.sgi.com this weekend. It is down? > > > > > > > > No, if you have tcp_ecn enabled you might switch off with > > > > > > > > echo 0 >/proc/sys/net/ipv4/tcp_ecn > > > > > > > > If this is the case, a router of the ISP where oss lives needs to be > > > > upgraded. > > > > > > Uhh... I can't ping it either from any network I'm on including > > > different OS'ed machines. > > > >Seems to be a DNS problem, try 216.32.174.27. > > It works for me. Note: The router they have probably does not pass icmp > packets. You can't ping it but you can telnet to port 80 :-) It works again here, too. I tried traceroute, but the output is not very conclusive. I guess Code Red is working its way through the Internet and eats all bandwith it can get ;-) ...Juergen From owner-linux-xfs@oss.sgi.com Sat Aug 11 14:52:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BLqXH04895 for linux-xfs-outgoing; Sat, 11 Aug 2001 14:52:33 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BLqTj04875 for ; Sat, 11 Aug 2001 14:52:30 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA06962; Sat, 11 Aug 2001 23:52:22 +0200 (CEST) Message-Id: <4.3.2.7.2.20010811234247.03264d38@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 11 Aug 2001 23:51:54 +0200 To: Steve Lord , Bram Moolenaar From: Seth Mos Subject: Re: vim file write mode on journaling fs. Cc: Russell Cattelan , Linux XFS Mailing List In-Reply-To: <200108112126.f7BLQWe26468@jen.americas.sgi.com> References: <200108111848.f7BIm1704198@moolenaar.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:26 11-8-2001 -0500, Steve Lord wrote: >OK, just picking a message to respond to from this thread. snipping > 4. Anyone who is shutting down their system by pulling the plug > rather than doing an orderly shutdown is asking for trouble. > Yes, it is a situation we want to deal with fairly gracefully, > but filesystem recovery in journaling filesystems and fsck in > others is there to 'recover' from problems, not to cater to > lazy users. umount is there for a reason. Yes, but crashes can ocur in a perfect world. > 5. With XFS it looks like this: > > o write system call comes in looks for space in the file, if > there is none it asks the filesystem for some, the filesystem > records the fact that space was requested at this point in the > file. A buffer is allocated as before, it is marked dirty, it > is also marked delayed allocate. The write returns. > > o Possibly an inode flush or a log flush pushes the new inode > out to disk. > > o The bdflush daemon comes along and sees the buffers as being > delayed allocate, it calls the filesystem to allocate the space. > The allocate is done, and the buffers are written out to disk. > The transaction which records the extents is still in memory > and will not be flushed for a few seconds yet. > > This last sentence is the major difference, and is probably what is > biting here, the write has not really happened until this metadata > makes it out to disk. We may be having some issues with how long > this is taking in Linux. Weird, I expected the data to get written first and then the metadata. If that would happen you would have no file, or in our case, the old file. >So the upshot of all of this is that I suspect we do have an issue, and we >will get to it at some point. In the mean time there is no need to start >discarding filesystems which do not behave as you want them to do if you >pull the plug. Hey, we have lot's of time to fix it. I could have used all those 30 minutes of time that I saved from fscking my filesystem but I used it to play Quake 3 instead. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Aug 11 15:02:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BM2wo05182 for linux-xfs-outgoing; Sat, 11 Aug 2001 15:02:58 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BM2rj05163 for ; Sat, 11 Aug 2001 15:02:53 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA21017 for ; Sat, 11 Aug 2001 15:02:38 -0700 (PDT) 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 PAA08919; Sat, 11 Aug 2001 15:02:19 -0700 (PDT) Message-ID: <3B75AAB7.F07806AF@sgi.com> Date: Sat, 11 Aug 2001 16:59:19 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Bram Moolenaar CC: Russell Cattelan , Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. References: <200108111042.f7BAgLt00682@moolenaar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bram Moolenaar wrote: > > Russell Cattelan wrote: > > > > The following script was used. > > > > > > #!/bin/sh > > > echo Test > file1 > > > cp file1 file2 > > > rm file1 > I'm glad Seth found an example with basic commands which shows Vim isn't > really doing something strange. > Summary: I consider this to be a problem with the filesystem, not with Vim. > For people that want to be sure their file is synced, the ":!sync" command can > be used. I'll chime in and say I never thought vim was doing anything strange... :) However... regarding broken filesystems... let's try this with ext2: [root@lite /root]# cat testit #!/bin/sh mke2fs -q /dev/sda2 mount /dev/sda2 /mnt/sda2 echo Test > /mnt/sda2/file1 cp /mnt/sda2/file1 /mnt/sda2/file2 rm /mnt/sda2/file1 [root@lite /root]# ./testit [root@lite /root]# ls -aR /mnt/sda2 /mnt/sda2: . .. file2 lost+found /mnt/sda2/lost+found: . .. [root@lite /root]# e2fck /dev/sda2 e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 /dev/sda2 was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda2: 11/340032 files (0.0% non-contiguous), 10685/678746 blocks [root@lite /root]# mount /dev/sda2 /mnt/sda2 [root@lite /root]# ls -aR /mnt/sda2 /mnt/sda2: . .. lost+found /mnt/sda2/lost+found: . .. Nada... zip... zilch... Hey, at least with XFS you get to see a filename. :) -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Aug 11 15:08:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BM8Uh05327 for linux-xfs-outgoing; Sat, 11 Aug 2001 15:08:30 -0700 Received: from mustang.centralnet.ch (mustang.centralnet.ch [193.135.146.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BM8Rj05305 for ; Sat, 11 Aug 2001 15:08:27 -0700 Received: from vollmann.ch (luz19.centralnet.ch [193.246.195.19]) by mustang.centralnet.ch (8.9.3/8.9.3) with ESMTP id AAA487154; Sun, 12 Aug 2001 00:08:14 +0200 (MES) Received: from two.vollmann.ch (localhost [127.0.0.1]) by vollmann.ch (8.8.6/8.8.5) with SMTP id WAA01341; Sat, 11 Aug 2001 22:08:02 GMT Message-ID: <3B75ACC1.7E339436@vollmann.ch> Date: Sat, 11 Aug 2001 22:08:01 +0000 From: Detlef Vollmann Organization: vollmann engineering gmbh X-Mailer: Mozilla 3.04 (X11; U; Linux 2.2.14-5.0 i586) MIME-Version: 1.0 To: alane@geeksrus.net CC: XFS list Subject: Re: Mode of symbolic link References: <3B746B43.41845CCC@vollmann.ch> <3B7477D8.8C2F1855@sgi.com> <3B747E25.69FAC55A@vollmann.ch> <200108110050.f7B0ocX06776@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > RPM's verify mode wouldn't possibly look at this, would it? Well, don't know about rpm, but tar produces all (well, nearly all) symbolic links with mode 777, though the tarfile itself contains the true original modes. There is no problem for a C program to set the mode of a symbolic link, so if rpm verifies it, it will probably also set it correctly according to the package contents. But as I said, I can't really tell about rpm. cheers, Detlef -- Detlef Vollmann vollmann engineering gmbh Tel: +41-41-4120911 P.O. Box 5106 Fax: +41-41-4120912 CH-6000 Luzern 5 / Switzerland eMail: dv@vollmann.ch From owner-linux-xfs@oss.sgi.com Sat Aug 11 16:32:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BNWF106205 for linux-xfs-outgoing; Sat, 11 Aug 2001 16:32:15 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BNWCj06186 for ; Sat, 11 Aug 2001 16:32:12 -0700 Received: (qmail 1047 invoked by uid 8); 11 Aug 2001 23:32:08 -0000 From: Juri Haberland Reply-To: Juri Haberland X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: cvs down? nvidia drivers w/ devfs + xfs? Date: Sat, 11 Aug 2001 23:32:06 +0000 (UTC) Organization: spoiled dot org Lines: 17 Distribution: local Message-ID: References: <20010811111550.D13253@gwyn.tux.org> X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (OpenBSD/2.9 (i386)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Timothy Ball wrote: > Second I'm having issues making the nvidia drivers work w/ devfs I don't > know if this is specific to the xfs tree but since I don't use the > normal kernel tree anymore it's a bit of an issue. AFAIK the Nvidia drivers do not work well with devfs. I think you have to create a special device entry in /dev every time you boot, though I can't remember which one it was... Did you look into the documentation that came with the drivers? I think they mention the devfs problem. Juri -- Juri Haberland From owner-linux-xfs@oss.sgi.com Sat Aug 11 16:37:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7BNbZD06357 for linux-xfs-outgoing; Sat, 11 Aug 2001 16:37:35 -0700 Received: from ente.berdmann.de (frnk-d5141ab6.dsl.mediaWays.net [213.20.26.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7BNbXj06338 for ; Sat, 11 Aug 2001 16:37:33 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15ViJk-0005bo-00; Sun, 12 Aug 2001 01:37:20 +0200 Message-ID: <3B75C1B0.C299483C@berdmann.de> Date: Sun, 12 Aug 2001 01:37:20 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Bram Moolenaar CC: Russell Cattelan , Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. References: <200108111521.f7BFLTS03169@moolenaar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bram Moolenaar wrote: > > Russell Cattelan wrote: > > > This isn't a matter of laziness or poor design it's a trade off. > > If you want the benefits of delayed allocation/write then there has to > > be a DELAY otherwise there would be much point, > > if you want better data integrity in the event of a crash > > then mount your filesystems O_SYNC and loose the performance. > > There is no need for such a trade-off. It is not difficult to detect that the > harddisk isn't very busy and start writing out dirty data blocks then. This > doesn't cause a performance drop and greatly increases reliability. > > It's certainly worth the effort to implement this. The tests done by Seth > show that this is a real, existing problem. > > Don't look at this from the point of view of a person that knows what "delayed > allocation/write" means, look at it from the point of view of a user. Look what Steve Best from IBM's JFS group wrote about it: Several other aspects of log-based recovery are of interest. First, JFS only logs operations on meta-data, so replaying the log only restores the consistency of structural relationships and resource allocation states within the file system. It does not log file data or recover this data to consistent state. Consequently, some file data may be lost or stale after recovery, and customers with a critical need for data consistency should use synchronous I/O. (http://www-106.ibm.com/developerworks/library/jfs.html) From owner-linux-xfs@oss.sgi.com Sat Aug 11 19:44:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7C2iVb08081 for linux-xfs-outgoing; Sat, 11 Aug 2001 19:44:31 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7C2iSj08062 for ; Sat, 11 Aug 2001 19:44:28 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 966C01E46D; Sun, 12 Aug 2001 04:44:22 +0200 (MEST) Date: Sun, 12 Aug 2001 04:44:02 +0200 From: Andi Kleen To: Bram Moolenaar Cc: Russell Cattelan , Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. Message-ID: <20010812044402.A23422@gruyere.muc.suse.de> References: <3B75549D.96EEE5EB@thebarn.com> <200108111848.f7BIm1704198@moolenaar.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108111848.f7BIm1704198@moolenaar.net>; from Bram@moolenaar.net on Sat, Aug 11, 2001 at 08:48:01PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Aug 11, 2001 at 08:48:01PM +0200, Bram Moolenaar wrote: > What tools do I have that indicate to the FS how it should handle the data I > have written? Can I somehow tell it to flush my data soon, but not as drastic > as syncing? You could use fsync before the close. Then the write will be async, but at the end there is a flush forced. This should also give you efficient extent allocation on XFS. For ext2 you should also fdatasync the directory to make sure that the filename really has reached disk and won't hit lost+found. BTW while at it you could also make vim use rename+unlink of the old file instead of O_TRUNC for file writing, then it would do COW in hardlinked trees, not requiring me to keep a clumpsy wrapper around for that. -Andi From owner-linux-xfs@oss.sgi.com Sat Aug 11 22:49:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7C5nKT09379 for linux-xfs-outgoing; Sat, 11 Aug 2001 22:49:20 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7C5nGj09359 for ; Sat, 11 Aug 2001 22:49:16 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0D770C00FC0 for ; Sun, 12 Aug 2001 13:49:14 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id AAF02C00FBD for ; Sun, 12 Aug 2001 13:49:12 +0800 (PHT) Date: Sun, 12 Aug 2001 13:49:12 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. In-Reply-To: <4.3.2.7.2.20010811234247.03264d38@pop.xs4all.nl> 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, 11 Aug 2001 at 23:51, Seth Mos wrote: > Weird, I expected the data to get written first and then the metadata. > If that would happen you would have no file, or in our case, the old > file. Does anybody at all remember my post regarding bdflush settings? I repeat two contents of /proc/sys/vm/bdflush that seem to be related: age_buffer = 3000 age_super = 60 These are the defaults, and are in jiffies. Here is a quote from /usr/src/linux/Documentation/filesystems/proc.txt: -----[ proc.txt ]----- age_buffer and age_super ------------------------ Finally, the age_buffer and age_super parameters govern the maximum time Linux waits before writing out a dirty buffer to disk. The value is expressed in jiffies (clockticks), the number of jiffies per second is 100. Age_buffer is the maximum age for data blocks, while age_super is for filesystems meta data. -----[ end proc.txt ]----- You cannot set age_buffer to be < 100, I don't know why (didn't find documentation for this but learned experimentally that it won't accept anything < 100), but still, 100 jiffies is 1 second. Now my still unanswered question: isn't this all that we need to make sure data gets on to disk in an idle system? I've already set my server's /proc/sys/vm/bdflush to have an age_buffer = 100, although I haven't done similar tests pulling the plug because I just don't do that with the server. I will find time to simulate such tests with the two different bdflush settings on a non-production machine. I _think_ that setting bdflush with age_buffer == 100 will give us "the best of both worlds". On an active system you still don't get O_SYNC performance as you still get to use the buffer, and yet on an idle system you don't wait 3000 jiffies to flush dirty buffers to disk. Perhaps someone more into testing can do this very simple comparison, although I hope to send the list follow up information soon. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sat Aug 11 22:59:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7C5xpr09533 for linux-xfs-outgoing; Sat, 11 Aug 2001 22:59:51 -0700 Received: from HAL.vedge.net (extern170.atou.qc.ca [207.96.201.170]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7C5xmj09514 for ; Sat, 11 Aug 2001 22:59:48 -0700 Received: by atou.qc.ca via sendmail from stdin id (Debian Smail3.2.0.111) for linux-xfs@oss.sgi.com; Sun, 12 Aug 2001 02:00:04 -0400 (EDT) Date: Sun, 12 Aug 2001 02:00:04 -0400 From: Jean-Francois Landry To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: __alloc_pages: 0-order allocation failed. Message-ID: <20010812020003.A15371@atou.qc.ca> Reply-To: jflandry@atou.qc.ca References: <20010810100553.A25178@conwaycorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: ; from knuffie@xs4all.nl on Fri, Aug 10, 2001 at 06:14:16PM +0200 X-Operating-System: Linux HAL 2.4.7 i586 X-Uptime: 1:50am up 2 days, 11:54, 1 user, load average: 1.03, 1.13, 1.08 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 06:14:16PM +0200, Seth Mos wrote: <> > > The file was created successfully though...but the messages do tend to > > put me on edge a bit. Copying a 64gb file from an NFS share to the > > filesystem doesn't show any problems. > > Probably because it does not push the system as much. > Not quite entirely on topic but I got similar kernel messages once when extracting a largish tarball (about 70000 files, my ~/mail in Maildir format) on a reiserfs partition on kernel 2.4.7, so I'd say this is a generic kernel MM problem. Nothing bad happened though. Jean-Francois Landry -- UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. Doug Gwyn -- From owner-linux-xfs@oss.sgi.com Sat Aug 11 23:47:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7C6lJe10004 for linux-xfs-outgoing; Sat, 11 Aug 2001 23:47:19 -0700 Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7C6lHj09985 for ; Sat, 11 Aug 2001 23:47:17 -0700 Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id IAA29990 for ; Sun, 12 Aug 2001 08:47:14 +0200 (MEST) Message-ID: <3B76268D.7030508@dumballah.tvnet.hu> Date: Sun, 12 Aug 2001 08:47:41 +0200 From: Sipos Ferenc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: cvs down? nvidia drivers w/ devfs + xfs? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Nvidia drivers works well for me with devfs, if you do the following: patch the driver with the unofficial devfs patch, install the driver as in the documetation, and put the following lines into modules.conf: alias /dev/nvidia0 NVdriver alias /dev/nvidiactl NVdriver and that's all, you won't have to recreate anything in dev after reboot. Paco From owner-linux-xfs@oss.sgi.com Sun Aug 12 00:08:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7C78BJ10241 for linux-xfs-outgoing; Sun, 12 Aug 2001 00:08:11 -0700 Received: from gwyn.tux.org (ident-user@gwyn.tux.org [207.96.122.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7C789j10222 for ; Sun, 12 Aug 2001 00:08:09 -0700 Received: (from timball@localhost) by gwyn.tux.org (8.9.3/8.9.1) id DAA31801 for linux-xfs@oss.sgi.com; Sun, 12 Aug 2001 03:08:08 -0400 Date: Sun, 12 Aug 2001 03:08:08 -0400 From: Timothy Ball To: XFS Mailing List Subject: Re: cvs down? nvidia drivers w/ devfs + xfs? Message-ID: <20010812030808.K13253@gwyn.tux.org> References: <20010811111550.D13253@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010811111550.D13253@gwyn.tux.org> User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Wow thanks for all the responses. Everythings working the way it should now... :) Though I had to run xfs_repair on /home. It seems this was triggered: --snip--snip--snip-- Aug 12 00:37:47 jane kernel: xfs_force_shutdown(ide0(3,7),0x1) called from line 1013 of file xfs_trans.c. Return address = 0xc01a8ad6 Aug 12 00:37:47 jane kernel: I/O Error Detected. Shutting down filesystem: ide0(3,7) Aug 12 00:37:47 jane kernel: Please umount the filesystem, and rectify the problem(s) --snip--snip--snip-- Reading the code around it makes me think I should mkfs.xfs again on /home is this an accurate assessment? --timball -- GPG key available on pgpkeys.mit.edu pub 1024R/CFF85605 1999-06-10 Timothy L. Ball Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD From owner-linux-xfs@oss.sgi.com Sun Aug 12 03:49:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CAnSW12108 for linux-xfs-outgoing; Sun, 12 Aug 2001 03:49:28 -0700 Received: from mail2.home.nl (mail2.home.nl [213.51.129.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CAnPj12089 for ; Sun, 12 Aug 2001 03:49:26 -0700 Received: from moolenaar.net ([212.120.77.84]) by mail2.home.nl (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010812114926.IORL3161.mail2.home.nl@moolenaar.net>; Sun, 12 Aug 2001 12:49:26 +0100 Received: from masaka.moolenaar.net (localhost.moolenaar.net [127.0.0.1]) by moolenaar.net (8.11.1/8.11.1) with ESMTP id f7CAnxP01513; Sun, 12 Aug 2001 12:49:59 +0200 (CEST) (envelope-from Bram@moolenaar.net) Message-Id: <200108121049.f7CAnxP01513@moolenaar.net> To: Andi Kleen Cc: Russell Cattelan , Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. In-Reply-To: <20010812044402.A23422@gruyere.muc.suse.de> From: Bram Moolenaar Date: Sun, 12 Aug 2001 12:49:58 +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andi Kleen wrote: > On Sat, Aug 11, 2001 at 08:48:01PM +0200, Bram Moolenaar wrote: > > What tools do I have that indicate to the FS how it should handle the data > > I have written? Can I somehow tell it to flush my data soon, but not as > > drastic as syncing? > > You could use fsync before the close. Then the write will be async, but at > the end there is a flush forced. This should also give you efficient > extent allocation on XFS. For ext2 you should also fdatasync the directory > to make sure that the filename really has reached disk and won't hit > lost+found. I don't like the idea of an application having to fsync() every file that it has written and wants to avoid that it gets lost in a crash. In my opinion it's not the task of the application to decide that it's time to flush data to the disk. Only applications that must know for sure that the data has been written (such as when receiving e-mail, where the protocol requires it). After all, you would want settings in the filesystem for tuning the performance, not settings in every application that uses this filesystem. > BTW while at it you could also make vim use rename+unlink of the old file > instead of O_TRUNC for file writing, then it would do COW in hardlinked > trees, not requiring me to keep a clumpsy wrapper around for that. I don't understand this remark. Perhaps the 'backupcopy' option is what you need? It's new in Vim 6.0. -- -rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed -rwxr-xr-t 4 root 131720 Jan 1 1970 /usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs /// Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// From owner-linux-xfs@oss.sgi.com Sun Aug 12 03:49:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CAnb712136 for linux-xfs-outgoing; Sun, 12 Aug 2001 03:49:37 -0700 Received: from mail2.home.nl (mail2.home.nl [213.51.129.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CAnYj12114 for ; Sun, 12 Aug 2001 03:49:34 -0700 Received: from moolenaar.net ([212.120.77.84]) by mail2.home.nl (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010812114935.IORW3161.mail2.home.nl@moolenaar.net>; Sun, 12 Aug 2001 12:49:35 +0100 Received: from masaka.moolenaar.net (localhost.moolenaar.net [127.0.0.1]) by moolenaar.net (8.11.1/8.11.1) with ESMTP id f7CAnxP01518; Sun, 12 Aug 2001 12:49:59 +0200 (CEST) (envelope-from Bram@moolenaar.net) Message-Id: <200108121049.f7CAnxP01518@moolenaar.net> To: Steve Lord In-Reply-To: <200108112126.f7BLQWe26468@jen.americas.sgi.com> cc: Russell Cattelan , Seth Mos , Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. From: Bram Moolenaar Date: Sun, 12 Aug 2001 12:49:59 +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > OK, just picking a message to respond to from this thread. > > 1. It is not XFS which is deciding when to write the file data out > to disk, it is Linux. The bdflush daemon is responsible for this, > that 30 seconds is one of its control parameters. > > 2. An individual thread doing a write in XFS has no way of knowing > or predicting what else may just of happened, or be about to happen > on the system. You cannot say 'I will write my data now because > the system is idle', there may be a couple of Gbytes of I/O about > to come in from another source. These two are technical reasons. I like to look at it from the POV of the user or system administrator. The technical implementation needs to match what they want to do. The implementation may need to be changed to make it work properly. Yes, that would be work. > 3. O_SYNC is a fairly standard flag on file open, if freebsd does not > have it then it is missing a fairly major feature of filesystems. > Having said that, I do not recommend using O_SYNC, it is more > expensive than an fsync. Does O_SYNC mean every single write() is synced? We don't need that. > 4. Anyone who is shutting down their system by pulling the plug > rather than doing an orderly shutdown is asking for trouble. > Yes, it is a situation we want to deal with fairly gracefully, > but filesystem recovery in journaling filesystems and fsck in > others is there to 'recover' from problems, not to cater to > lazy users. umount is there for a reason. The "pulling the plug" test is a very good way to check what would happen if the power fails unexpectedly. E.g., when a fuse blows. > 5. The delayed write you talk about is the norm for ALL filesystems > operating on spinning disks. If you don't delay writes in a filesystem > then you will be here until Christmas responding to this email. > Now XFS has delayed allocation which is different. More technical reasons, which explain why it works this way, but give no reason to want it that way. > This last sentence is the major difference, and is probably what is > biting here, the write has not really happened until this metadata > makes it out to disk. We may be having some issues with how long > this is taking in Linux. There appears to be a problem: There is only a fixed delay, no clever mechanism that starts flushing data when the disk isn't very busy. > So the upshot of all of this is that I suspect we do have an issue, and we > will get to it at some point. In the mean time there is no need to start > discarding filesystems which do not behave as you want them to do if you > pull the plug. I think the main issue is that I would expect the system to flush data when the system isn't doing anything. Scenario: I'm editing a file, write it out and go for coffee. Switching on the coffee machine blows a fuse, and the computer was on the same one. Now, how big is the chance that my work was saved? If it takes 30 seconds before the data gets written, I probably lost it. If the system recognized that I stopped typing and decided it has some time to write to disk, I would have probably lost nothing. If I started running make and caused a lot of disk I/O, I would not be surprised some data is lost. One specific issue is when I copy a file (or in Vim: make a small change to a file and write the new version). You want to end up with either the old version or the new version. You might lose your most recent changes, but that's only a small problem. It's a big problem when both are lost. Technically this probably means that the meta data shouldn't be updated before the data has been written. This is probably very complicated, but that is what I see as an important issue for data safety. -- 5 out of 4 people have trouble with fractions. /// Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// From owner-linux-xfs@oss.sgi.com Sun Aug 12 04:35:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CBZGn17685 for linux-xfs-outgoing; Sun, 12 Aug 2001 04:35:16 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CBZDj17665 for ; Sun, 12 Aug 2001 04:35:13 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id NAA03353; Sun, 12 Aug 2001 13:34:52 +0200 (CEST) Message-Id: <4.3.2.7.2.20010812133316.0345ae20@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Aug 2001 13:34:22 +0200 To: Timothy Ball , XFS Mailing List From: Seth Mos Subject: Re: cvs down? nvidia drivers w/ devfs + xfs? In-Reply-To: <20010812030808.K13253@gwyn.tux.org> References: <20010811111550.D13253@gwyn.tux.org> <20010811111550.D13253@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 03:08 12-8-2001 -0400, Timothy Ball wrote: >Wow thanks for all the responses. Everythings working the way it should >now... :) Though I had to run xfs_repair on /home. It seems this was >triggered: >--snip--snip--snip-- >Aug 12 00:37:47 jane kernel: xfs_force_shutdown(ide0(3,7),0x1) called >from line >1013 of file xfs_trans.c. Return address = 0xc01a8ad6 >Aug 12 00:37:47 jane kernel: I/O Error Detected. Shutting down >filesystem: ide0(3,7) >Aug 12 00:37:47 jane kernel: Please umount the filesystem, and rectify >the problem(s) >--snip--snip--snip-- > >Reading the code around it makes me think I should mkfs.xfs again on >/home is this an accurate assessment? xfs_repair does not fix it? Reformating you partition would be silly unless it looks like /dev/random. 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 Sun Aug 12 05:43:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CChVX18413 for linux-xfs-outgoing; Sun, 12 Aug 2001 05:43:31 -0700 Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CChTj18394 for ; Sun, 12 Aug 2001 05:43:29 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 15VuaP-000Ks3-0W for linux-xfs@oss.sgi.com; Sun, 12 Aug 2001 13:43:22 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 07D2827EF for ; Sun, 12 Aug 2001 13:42:54 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id 63F85125E6; Sun, 12 Aug 2001 13:42:53 +0100 (BST) Date: Sun, 12 Aug 2001 13:42:52 +0100 (BST) From: Keith Matthews Subject: Re[2]: vim file write mode on journaling fs. To: linux-xfs@oss.sgi.com In-Reply-To: <200108121049.f7CAnxP01518@moolenaar.net> References: <200108121049.f7CAnxP01518@moolenaar.net> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010812124253.63F85125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f7CChTj18395 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 12 Aug 2001 12:49:59 +0200 Bram Moolenaar > wrote: > The "pulling the plug" test is a very good way to check what would happen if > the power fails unexpectedly. E.g., when a fuse blows. > > 5. The delayed write you talk about is the norm for ALL filesystems > > operating on spinning disks. If you don't delay writes in a filesystem > > then you will be here until Christmas responding to this email. > > Now XFS has delayed allocation which is different. > More technical reasons, which explain why it works this way, but give no > reason to want it that way. If you feel this way then I suggest you stay with MSDOS which always uses synchronous writes and suffers performance accordingly. Every multi-user system I've ever come across works the way you are objecting to - they have to to get adequate performance, and it does not matter whether the wait 100 seconds or 10 mSec - there is still a chance of failure between the OS saying 'OK, I've done' and the data actually being written to disc. The only practical way to achieve what you want in a multi-user OS is to use transaction mechanisms as used in database systems, and that would require a redesign of all relevant applications because they would have to pass 'start of transaction' and 'end of transaction' messages to the OS. -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Sun Aug 12 10:37:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CHbda21317 for linux-xfs-outgoing; Sun, 12 Aug 2001 10:37:39 -0700 Received: from neutral.verbum.org (postfix@dhcp233054.columbus.rr.com [204.210.233.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CHbbj21298 for ; Sun, 12 Aug 2001 10:37:37 -0700 Received: from space-ghost.verbum.org (space-ghost.verbum.org [192.168.5.90]) by neutral.verbum.org (Postfix (Debian/GNU)) with ESMTP id 6FEDFF57E for ; Sun, 12 Aug 2001 13:35:25 -0400 (EDT) Received: by space-ghost.verbum.org (Postfix (Debian/GNU), from userid 1000) id C1EEC622EE0; Sun, 12 Aug 2001 13:37:22 -0400 (EDT) To: linux-xfs@oss.sgi.com Subject: Re: vim file write mode on journaling fs. References: <200108111848.f7BIm1704198@moolenaar.net> <200108112126.f7BLQWe26468@jen.americas.sgi.com> X-Attribution: Colin X-Face: %'w-_>8Mj2_'=;I$myE#]G"'D>x3CY_rk,K06:mXFUvWy>;3I"BW3_-MAiUby{O(mn"wV@m dd`)Vk[27^^Sa Date: Sun, 12 Aug 2001 13:37:22 -0400 In-Reply-To: <200108112126.f7BLQWe26468@jen.americas.sgi.com> (Steve Lord's message of "Sat, 11 Aug 2001 16:26:32 -0500") Message-ID: <87y9opyyb1.church.of.emacs@space-ghost.verbum.org> Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord writes: > 2. An individual thread doing a write in XFS has no way of knowing > or predicting what else may just of happened, or be about to > happen on the system. You cannot say 'I will write my data now > because the system is idle', there may be a couple of Gbytes of > I/O about to come in from another source. Why couldn't the kernel keep some statistics about disk usage, and use those to make an educated guess as to whether or not we should write out the data immediately? I appreciate that XFS can deal with gigabytes of I/O, but such an event is very unlikely on my laptop :) From owner-linux-xfs@oss.sgi.com Sun Aug 12 10:49:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CHnpM21542 for linux-xfs-outgoing; Sun, 12 Aug 2001 10:49:51 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CHnnj21523 for ; Sun, 12 Aug 2001 10:49:49 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA07537 for ; Sun, 12 Aug 2001 10:48:25 -0700 (PDT) mail_from (sandeen@sgi.com) 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 TAA1024313 for ; Sun, 12 Aug 2001 19:44:31 +0200 (CEST) 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 KAA87032; Sun, 12 Aug 2001 10:45:13 -0700 (PDT) Message-ID: <3B76BFEB.92B60647@sgi.com> Date: Sun, 12 Aug 2001 12:42:03 -0500 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: Colin Walters CC: linux-xfs@oss.sgi.com Subject: Re: vim file write mode on journaling fs. References: <200108111848.f7BIm1704198@moolenaar.net> <200108112126.f7BLQWe26468@jen.americas.sgi.com> <87y9opyyb1.church.of.emacs@space-ghost.verbum.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Colin Walters wrote: > > Steve Lord writes: > > > 2. An individual thread doing a write in XFS has no way of knowing > > or predicting what else may just of happened, or be about to > > happen on the system. You cannot say 'I will write my data now > > because the system is idle', there may be a couple of Gbytes of > > I/O about to come in from another source. > > Why couldn't the kernel keep some statistics about disk usage, and use > those to make an educated guess as to whether or not we should write > out the data immediately? > > I appreciate that XFS can deal with gigabytes of I/O, but such an > event is very unlikely on my laptop :) Again, this really isn't XFS-specific. The bdflush daemon pushes out metadata every 5 seconds, data every 30 (by default). You'll see this same behavior with ext2. I think a big reason that people are seeing it "more" with XFS is that after recovery, a file exists with "nulls" in it, which looks like corruption. Based on the quick experiment in my previous email, I think the difference is that with ext2, the user would never even see the file, so they may not notice. "Blissfully unaware" as they say. :) Regarding prediction for when to write, that's a whole different ballpark. It would be pretty tough to "predict" that there will be no other I/O's happening in the next 2 seconds, so now is a good time to write that 5 byte file... -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 Aug 12 10:50:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CHohi21633 for linux-xfs-outgoing; Sun, 12 Aug 2001 10:50:43 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CHoej21614 for ; Sun, 12 Aug 2001 10:50:41 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA02765 for ; Sun, 12 Aug 2001 10:49:16 -0700 (PDT) mail_from (lord@sgi.com) 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 TAA1024977 for ; Sun, 12 Aug 2001 19:45:24 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2692566; Sun, 12 Aug 2001 12:45:30 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA45972; Sun, 12 Aug 2001 12:45:30 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7CHiNI06840; Sun, 12 Aug 2001 12:44:23 -0500 Message-Id: <200108121744.f7CHiNI06840@jen.americas.sgi.com> To: Colin Walters cc: linux-xfs@oss.sgi.com Subject: Re: vim file write mode on journaling fs. References: <200108111848.f7BIm1704198@moolenaar.net> <200108112126.f7BLQWe26468@jen.americas.sgi.com> <87y9opyyb1.church.of.emacs@space-ghost.verbum.org> Comments: In-reply-to Colin Walters message dated "Sun, 12 Aug 2001 13:37:22 -0400." Date: Sun, 12 Aug 2001 12:44:22 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Steve Lord writes: > > > 2. An individual thread doing a write in XFS has no way of knowing > > or predicting what else may just of happened, or be about to > > happen on the system. You cannot say 'I will write my data now > > because the system is idle', there may be a couple of Gbytes of > > I/O about to come in from another source. > > Why couldn't the kernel keep some statistics about disk usage, and use > those to make an educated guess as to whether or not we should write > out the data immediately? This is a main kernel thing, not an XFS thing. Look at all the back and forth about the VM subsystem in 2.4, people are writing code which works in their environment, it gets into the kernel, then someone else says their performance tanked. It is the same sort of issue, this type of thing is very hard to get right in a manner which pleases everyone. Steve From owner-linux-xfs@oss.sgi.com Sun Aug 12 12:21:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CJLhX22744 for linux-xfs-outgoing; Sun, 12 Aug 2001 12:21:43 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CJLfj22725 for ; Sun, 12 Aug 2001 12:21:41 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 1B92D1AB12 for ; Sun, 12 Aug 2001 15:21:39 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id EEEB184D; Sun, 12 Aug 2001 15:21:38 -0400 (EDT) Date: Sun, 12 Aug 2001 15:21:38 -0400 From: Andrew Klaassen To: XFS list Subject: Re: Mode of symbolic link Message-ID: <20010812152138.A17945@dkp.com> Mail-Followup-To: XFS list References: <3B746B43.41845CCC@vollmann.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B746B43.41845CCC@vollmann.ch> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 11:16:19PM +0000, Detlef Vollmann wrote: > ...you can't change the mode of the link later, always the > mode of the target gets changed :-( ln -n Andrew Klaassen From owner-linux-xfs@oss.sgi.com Sun Aug 12 12:32:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CJWkg23001 for linux-xfs-outgoing; Sun, 12 Aug 2001 12:32:46 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CJWij22982 for ; Sun, 12 Aug 2001 12:32:45 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 2E05A1AB12 for ; Sun, 12 Aug 2001 15:32:44 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id DA5F784D; Sun, 12 Aug 2001 15:32:43 -0400 (EDT) Date: Sun, 12 Aug 2001 15:32:43 -0400 From: Andrew Klaassen To: Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. Message-ID: <20010812153243.B17945@dkp.com> Mail-Followup-To: Linux XFS Mailing List References: <200108111848.f7BIm1704198@moolenaar.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200108111848.f7BIm1704198@moolenaar.net> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Aug 11, 2001 at 08:48:01PM +0200, Bram Moolenaar wrote: > OK. Since I now understand how it works I will recommend > every user NOT to use this kind of filesystem. I hate to sound like a jerk, but you just finished demonstrating that you do *not* understand "how it works". As others have pointed out, this is a core kernel issue, *not* a filesystem issue. The best place to raise your concerns would be on the main Linux mailing list. (You probably wouldn't get a very good reception, but that's the right place to discuss this issue.) XFS has little or nothing to do with what you're troubled by. > The risk of losing your work is too big. Perhaps that's why > FreeBSD doesn't use a journalling file system. However, FreeBSD *does* use delayed writes (AFAIK - it's not a dark ages OS, after all), which means that you should be able to make your file disappear on FreeBSD as easily as you did on Linux, by unplugging at an inopportune time. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Sun Aug 12 14:00:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CL0Kh24308 for linux-xfs-outgoing; Sun, 12 Aug 2001 14:00:20 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CL0Ij24289 for ; Sun, 12 Aug 2001 14:00:18 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id A81AD1AB13 for ; Sun, 12 Aug 2001 17:00:17 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 5AA2784D; Sun, 12 Aug 2001 17:00:17 -0400 (EDT) Date: Sun, 12 Aug 2001 17:00:17 -0400 From: Andrew Klaassen To: Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. Message-ID: <20010812170017.C17945@dkp.com> Mail-Followup-To: Linux XFS Mailing List References: <200108111848.f7BIm1704198@moolenaar.net> <20010812153243.B17945@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010812153243.B17945@dkp.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Aug 12, 2001 at 03:32:43PM -0400, I wrote: > I hate to sound like a jerk, but you just finished > demonstrating... Ehn. That was a little harsh. Apologies. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Sun Aug 12 15:22:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CMMr425315 for linux-xfs-outgoing; Sun, 12 Aug 2001 15:22:53 -0700 Received: from ulrich.med.virginia.edu (ulrich.med.Virginia.EDU [128.143.16.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CMMoj25296 for ; Sun, 12 Aug 2001 15:22:50 -0700 Received: (qmail 8823 invoked from network); 12 Aug 2001 22:23:26 -0000 Received: from ketling.med.virginia.edu (128.143.16.121) by ulrich.med.virginia.edu with SMTP; 12 Aug 2001 22:23:26 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Jakub Otwinowski To: linux-xfs@oss.sgi.com Subject: redhat 7.1 xfs installer Date: Sun, 12 Aug 2001 18:17:57 -0400 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01081121051700.04708@ketling.med.virginia.edu> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have found a few bugs with this redhat 7.1 xfs installer. They have caused me much anguish as I spent some 8+ hours working on this. Here is the system: Tyan 25HSEL mobo 2 3ware escalade 6800 (can connect 8 disks each) 16 80 gig disks short story: after installation fstab is blank and kudzu hangs and the disks work very very slowly (could be unrelated to xfs) cd rescue mode crashes long story: I installed the system with the xfs redhat 7.1 installer. It took very long, almost 2 hours. On the first boot it doesn't get past "checking for new hardware" although the disks seem to be active. I reboot and I notice a message that it mounted / with ext2 and after that it tries to fsck it, fails, and gives me a maintenance shell. This doesn't help because whatever i try to do it says / is mounted read only. I notice fstab is completely blank. Eventually i put in the cd again and ran "linux rescue". It crashed giving me some errors about raid. I had 8 disks in a hardware raid 5 array and the other 8 were marked as linux raid partitions but no software array was actually made. It was like this because i was going to do software raid but then changed my mind. I reinstalled the system this time deleting the raid partitions which were not in use. It was very slow again. I booted with the same problems as before. So i ran the cd in rescue mode. This time it didn't crash. I saw a message that it mounted / and repaired it. I mount / myself and take out kudzu so it doesn't load on boot. I don't know much about mtab but i noticed it is what fstab should look like so i 'cp /etc/mtab /etc/fstab' and everything works well except reading and writing. We have another machine which is identical that was installed with regular redhat 7.1 and supposedly it was really slow with reading and writing for its first few days or weeks and then it got better. I wasn't around then but now I'm writing this email from it. It has 2 hardware raid 5 arrays. But this new machine's disks are really slow. I don't know much about hdparm -t but i ran it on both. Old machine: 66 Mb/sec New machine: ~200 Kb/sec >From writing files through the network it seems to write faster than 200 Kb/sec. Kudzu still hangs when i run it and it mounts fine after a hard reset. -Jakub O. From owner-linux-xfs@oss.sgi.com Sun Aug 12 16:00:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CN0qm25676 for linux-xfs-outgoing; Sun, 12 Aug 2001 16:00:52 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CN0nj25657 for ; Sun, 12 Aug 2001 16:00:49 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.31 #1) id 15W4Dv-0004oh-00; Mon, 13 Aug 2001 01:00:48 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f7CN1DK24769; Sun, 12 Aug 2001 19:01:13 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: Jakub Otwinowski Cc: linux-xfs@oss.sgi.com Subject: Re: redhat 7.1 xfs installer References: <01081121051700.04708@ketling.med.virginia.edu> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 12 Aug 2001 19:01:13 -0400 In-Reply-To: <01081121051700.04708@ketling.med.virginia.edu> Message-ID: Lines: 32 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 >>>>> "Jakub" == Jakub Otwinowski writes: Jakub> long story: I installed the system with the xfs redhat 7.1 Jakub> installer. It took very long, almost 2 hours. This is usually the case when the 3ware controller is busy resyncing the disks. You can't really tell, because they don't ignite the drive LED during resync, but the disks are indeed churning. And you can't tell how far along the the resync process it is either. Most annoying. It takes 3 hours+ here to resync a RAID1 with two 60GB disks, and the machine is completely unusable during this period. Despite the fact that I have given host I/O priority over resync. In your case with 8 80GB disks in a RAID5, that is likely to take a significant amount of time to sync. Hours and hours. Perhaps even days if you're doing I/O on the box simultaneously. I initially used a 3ware in a development box, but the firmware forces a resync every time you haven't shut down the machine cleanly. So after a hang my box would be stalled for hours. I ended up ripping out the 3ware and put it on the shelf where it belongs. And given the recent reports about bad voodoo with Escalade 6800 and RAID5, I wonder why people still bother with these cards... -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sun Aug 12 16:36:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CNaoQ26023 for linux-xfs-outgoing; Sun, 12 Aug 2001 16:36:50 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CNamj26004 for ; Sun, 12 Aug 2001 16:36:48 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 555DBC00FC3 for ; Mon, 13 Aug 2001 07:36:45 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id EA4F3C00FBA for ; Mon, 13 Aug 2001 07:36:43 +0800 (PHT) Date: Mon, 13 Aug 2001 07:36:43 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. In-Reply-To: <3B76BFEB.92B60647@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 On Sun, 12 Aug 2001 at 12:42, Eric Sandeen wrote: > Again, this really isn't XFS-specific. The bdflush daemon pushes out > metadata every 5 seconds, data every 30 (by default). You'll see this > same behavior with ext2. Eric, where did you get these values? I agree it's the bdflush daemon, but my own research on the 2.4 kernels leads me to believe that metadata is flushed out every 0.6 seconds. You correctly mention that data is flushed out every 30 seconds by default, though. And like my two previous messages on bdflush say: I wonder how setting it to 1 second (100 jiffies) will affect performance. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sun Aug 12 18:40:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D1eGS27092 for linux-xfs-outgoing; Sun, 12 Aug 2001 18:40:16 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D1eEj27073 for ; Sun, 12 Aug 2001 18:40:14 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA09850 for ; Sun, 12 Aug 2001 18:38:13 -0700 (PDT) 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 SAA18503; Sun, 12 Aug 2001 18:39:41 -0700 (PDT) Message-ID: <3B772F20.F2960A32@sgi.com> Date: Sun, 12 Aug 2001 20:36:32 -0500 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: Federico Sevilla III CC: Linux XFS Mailing List Subject: Re: vim file write mode on journaling fs. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III wrote: > Eric, where did you get these values? >From the bdflush man page, but then I just saw the "1994" at the bottom, so YMMV. :) -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 Aug 12 22:42:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D5g3Q29753 for linux-xfs-outgoing; Sun, 12 Aug 2001 22:42:03 -0700 Received: from exocore.com (PPP-178-206.bng.vsnl.net.in [203.197.178.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D5fxj29734 for ; Sun, 12 Aug 2001 22:41:59 -0700 Received: (from shanu@localhost) by exocore.com (8.11.2/8.8.7) id f7D5fuS08887 for linux-xfs@oss.sgi.com; Mon, 13 Aug 2001 11:11:56 +0530 Date: Mon, 13 Aug 2001 11:11:56 +0530 From: Shanker Balan To: Linux-XFS Subject: XFS patch for stable kernel 2.4.8 Message-ID: <20010813111156.A8862@exocore.com> Reply-To: Shanker Balan Mail-Followup-To: Linux-XFS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organisation: Exocore Consulting (P) Ltd Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello: Have the Linux-XFS maintainers put out a XFS CVS patch against kernel 2.4.8 yet? ftp://oss.sgi.com/projects/xfs/download/patches/ is only up to 2.4.8pre4. -- Shanu -- ------------------------------------------( Shanu )----- Shanker Balan http://people.exocore.com/shanu God is silent. Now if we can only get Man to shut up. From owner-linux-xfs@oss.sgi.com Sun Aug 12 23:25:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D6PdI30564 for linux-xfs-outgoing; Sun, 12 Aug 2001 23:25:39 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D6Pcj30543 for ; Sun, 12 Aug 2001 23:25:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA14317 for ; Sun, 12 Aug 2001 23:25:21 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08239; Mon, 13 Aug 2001 16:24:14 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Shanker Balan cc: Linux-XFS Subject: Re: XFS patch for stable kernel 2.4.8 In-reply-to: Your message of "Mon, 13 Aug 2001 11:11:56 +0530." <20010813111156.A8862@exocore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Aug 2001 16:24:14 +1000 Message-ID: <11189.997683854@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 13 Aug 2001 11:11:56 +0530, Shanker Balan wrote: >Have the Linux-XFS maintainers put out a XFS CVS patch against kernel >2.4.8 yet? > >ftp://oss.sgi.com/projects/xfs/download/patches/ is only up to >2.4.8pre4. Not yet. The CVS tree is up to 2.4.8-pre7 but tracking the recent VM changes requires a bit of time to ensure that the code works correctly. Besides, it is still the weekend in USA. From owner-linux-xfs@oss.sgi.com Mon Aug 13 02:16:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D9Gdw01537 for linux-xfs-outgoing; Mon, 13 Aug 2001 02:16:39 -0700 Received: from noc1.BelWue.DE (noc1.BelWue.DE [129.143.2.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D9Gaj01518 for ; Mon, 13 Aug 2001 02:16:36 -0700 Received: from obiwankenobi.science-computing.de (blackhole.science-computing.de [193.197.16.3]) by noc1.BelWue.DE with SMTP id LAA11383 for ; Mon, 13 Aug 2001 11:16:33 +0200 (MET DST) env-from (M.Arndt@science-computing.de) Received: from badefix.science-computing.de (micha@badefix.science-computing.de [10.148.25.35]) by obiwankenobi.science-computing.de (8.9.3/8.8.8) with ESMTP id LAA25797 for ; Mon, 13 Aug 2001 11:16:32 +0200 Received: (from micha@localhost) by badefix.science-computing.de (8.6.10/8.6.9) id LAA04171 for linux-xfs@oss.sgi.com; Mon, 13 Aug 2001 11:16:32 +0200 Date: Mon, 13 Aug 2001 11:16:32 +0200 From: Michael Arndt To: linux-xfs@oss.sgi.com Subject: XFS Development Message-ID: <20010813111632.B4137@badefix.science-computing.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, a query for an article: -how many developers are active at the actual XFS development ? -is XFS proting still supported by SGI ? please answer directly to M.Arndt@science-computing.de thx Micha Arndt reason for this question: cited rumours that most of the XFS porting people have left SGI If recommending a FS for productive environments further support is an issue and i want to cite only facts not unconfirmed rumors thanks for any help/info From owner-linux-xfs@oss.sgi.com Mon Aug 13 02:33:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D9XXC02029 for linux-xfs-outgoing; Mon, 13 Aug 2001 02:33:33 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D9XUj02010 for ; Mon, 13 Aug 2001 02:33:30 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id LAA12178 for ; Mon, 13 Aug 2001 11:33:28 +0200 (CEST) Message-Id: <4.3.2.7.2.20010813113221.03e4e600@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 11:32:58 +0200 To: Linux XFS Mailing List From: Seth Mos Subject: Re: xfs development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Other mail, same related info. This one was sent personally At 11:00 13-8-2001 +0200, you wrote: >Hello, > >i am writing an article about journaling FS. One Question: > >Some of the XFS developers have left SGI. They did yes, but they are far from gone. A lot of them are still around on the list but you don;t see them as frequent. >Will they continue to develop XFS, resp. will SGI continue the development. Some of them do, although they can't spend as much time on it as they used to since they now have another job. SGI has no plans of dropping XFS since they are moving to Linux for al their IA64 machines (Intel Unobtanium). Irix doesn't run on ia64 machines so the only platform that SGI has for those machines is linux. And since al lot of customers already have TeraBytes of data on XFS systems you don't just ask them to reformat their systems and copy all the data. Regardless of SGI supporting the XFS development, the source is now GPL and out there in use. I am not a SGI employee but I am active on the list answering questions and maintaining the FAQ. If they would go bankrupt, I don't see XFS dissapearing since it is a very nice full featured filesystem and it's available. It is also extremely well suited for large systems. The community aspect comes into play here. SGI has a good reputation in the opensource community so they will have some support. 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 Aug 13 02:56:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D9u3U02519 for linux-xfs-outgoing; Mon, 13 Aug 2001 02:56:03 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D9u0j02500 for ; Mon, 13 Aug 2001 02:56:00 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id CAA05660 for ; Mon, 13 Aug 2001 02:55:44 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA09025; Mon, 13 Aug 2001 19:54:41 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA93328; Mon, 13 Aug 2001 19:54:40 +1000 (AEST) Date: Mon, 13 Aug 2001 19:54:40 +1000 From: Nathan Scott To: Michael Arndt Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Development Message-ID: <20010813195440.D295821@wobbly.melbourne.sgi.com> References: <20010813111632.B4137@badefix.science-computing.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813111632.B4137@badefix.science-computing.de>; from M.Arndt@science-computing.de on Mon, Aug 13, 2001 at 11:16:32AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Aug 13, 2001 at 11:16:32AM +0200, Michael Arndt wrote: > Hello, a query for an article: > > -how many developers are active at the actual XFS > development ? > That's a hard number to quantify ... across both IRIX and Linux, at least twenty people I would guess, in a number of geographies. [counts on fingers]... at least 5 on core Linux/XFS right now. If you count CXFS, that number balloons out much further. > -is XFS proting still supported by SGI ? > proting? do you mean... porting? or promoting? yes for both. > please answer directly to M.Arndt@science-computing.de > > reason for this question: > > cited rumours that most of the XFS porting people > have left SGI > Three/four people from the 1.0 Linux/XFS team left during/just after the recent SGI headcount reductions. And some of these folk still contribute in answering list email, coding as time permits, etc; so its not even as bad as that. It was certainly not "most" of the team though. > If recommending a FS for productive environments > further support is an issue > and i want to cite only facts not unconfirmed rumors > The rumours are largely untrue, although there were some people leave recently. People also get pulled onto other SGI projects at various times and later return, or just for a time have less involvement, so at any one time its often hard to tell exactly how many people are working full time on XFS. > thanks for any help/info > hope this helps clear things up a bit. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 13 03:42:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DAgDN03585 for linux-xfs-outgoing; Mon, 13 Aug 2001 03:42:13 -0700 Received: from pipe.aspec.ru (nobody@relay1.aspec.ru [217.14.198.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DAgAj03565 for ; Mon, 13 Aug 2001 03:42:10 -0700 Received: from belkam.com (dm.p100.belkam.com [192.168.21.111]) by pipe.aspec.ru (8.11.1/8.11.1) with ESMTP id f7DAg4v15412 for ; Mon, 13 Aug 2001 15:42:04 +0500 (SAMST) Message-ID: <3B782D8B.3269DD9A@belkam.com> Date: Mon, 13 Aug 2001 15:42:03 -0400 From: Dmitry Melekhov X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.7-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: copy with acl Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello! Is it possible to copy files preserving acls? btw, is it possible to store acls into text file and then restore them (we use tar for backup) ? From owner-linux-xfs@oss.sgi.com Mon Aug 13 05:27:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DCREm06311 for linux-xfs-outgoing; Mon, 13 Aug 2001 05:27:14 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DCRBj06284 for ; Mon, 13 Aug 2001 05:27:11 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA17224 for ; Mon, 13 Aug 2001 05:16:50 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA2683006 for ; Mon, 13 Aug 2001 07:15:48 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA74472 for ; Mon, 13 Aug 2001 07:15:48 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f7DCEYc08509; Mon, 13 Aug 2001 07:14:34 -0500 Message-Id: <200108131214.f7DCEYc08509@jen.americas.sgi.com> Date: Mon, 13 Aug 2001 07:14:34 -0500 Subject: TAKE - merge upto 2.4.8 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A little more painful than usual, the super block locking changes took a little while to work out. The way xfs syncs inodes out to disk has changed a little, how it is triggered, not how it is implemented. If you see anything odd in this area let me know. Steve Date: Mon Aug 13 05:12:07 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100592a linux/drivers/sound/emu10k1/joystick.c - 1.1 linux/drivers/sound/emu10k1/passthrough.c - 1.1 linux/drivers/sound/emu10k1/passthrough.h - 1.1 linux/mm/vmscan.c - 1.68 linux/mm/swapfile.c - 1.34 linux/mm/swap.c - 1.11 linux/mm/page_alloc.c - 1.50 linux/mm/memory.c - 1.54 linux/kernel/sysctl.c - 1.38 linux/kernel/ksyms.c - 1.99 linux/include/linux/swap.h - 1.34 linux/include/linux/pagemap.h - 1.27 linux/include/linux/mount.h - 1.16 linux/include/linux/fs.h - 1.107 linux/include/asm-ppc/processor.h - 1.26 linux/fs/super.c - 1.50 linux/fs/inode.c - 1.47 linux/fs/dquot.c - 1.29 linux/fs/buffer.c - 1.77 linux/fs/block_dev.c - 1.23 linux/drivers/sound/Makefile - 1.30 linux/Makefile - 1.112 linux/drivers/char/drm/Makefile - 1.12 linux/drivers/char/agp/agpgart_be.c - 1.18 linux/Documentation/DocBook/parportbook.tmpl - 1.5 linux/drivers/sound/emu10k1/voicemgr.h - 1.3 linux/drivers/sound/emu10k1/voicemgr.c - 1.3 linux/drivers/sound/emu10k1/recmgr.c - 1.3 linux/drivers/sound/emu10k1/mixer.c - 1.5 linux/drivers/sound/emu10k1/midi.c - 1.7 linux/drivers/sound/emu10k1/main.c - 1.10 linux/drivers/sound/emu10k1/irqmgr.h - 1.3 linux/drivers/sound/emu10k1/irqmgr.c - 1.3 linux/drivers/sound/emu10k1/icardwav.h - 1.3 linux/drivers/sound/emu10k1/hwaccess.h - 1.3 linux/drivers/sound/emu10k1/hwaccess.c - 1.3 linux/drivers/sound/emu10k1/emu_wrapper.h - 1.5 linux/drivers/sound/emu10k1/efxmgr.h - 1.2 linux/drivers/sound/emu10k1/efxmgr.c - 1.3 linux/drivers/sound/emu10k1/cardwo.h - 1.3 linux/drivers/sound/emu10k1/cardwo.c - 1.4 linux/drivers/sound/emu10k1/cardwi.h - 1.3 linux/drivers/sound/emu10k1/cardwi.c - 1.3 linux/drivers/sound/emu10k1/cardmo.c - 1.4 linux/drivers/sound/emu10k1/cardmi.h - 1.4 linux/drivers/sound/emu10k1/cardmi.c - 1.4 linux/drivers/sound/emu10k1/audio.c - 1.9 linux/drivers/sound/emu10k1/Makefile - 1.4 linux/drivers/sound/emu10k1/8010.h - 1.3 linux/fs/xfs/xfs_vfsops.c - 1.322 linux/fs/xfs/linux/xfs_vfs.c - 1.24 linux/fs/xfs/linux/xfs_super.c - 1.132 linux/fs/xfs/linux/xfs_iops.c - 1.112 linux/fs/xfs/linux/xfs_vnode.h - 1.22 linux/drivers/sound/emu10k1/ecard.h - 1.4 linux/drivers/sound/emu10k1/ecard.c - 1.2 linux/arch/parisc/hpux/sys_hpux.c - 1.2 linux/mm/shmem.c - 1.11 From owner-linux-xfs@oss.sgi.com Mon Aug 13 05:27:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DCRCg06306 for linux-xfs-outgoing; Mon, 13 Aug 2001 05:27:12 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DCRAj06267 for ; Mon, 13 Aug 2001 05:27:10 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA17040 for ; Mon, 13 Aug 2001 05:13:45 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA2698722; Mon, 13 Aug 2001 07:12:40 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA94699; Mon, 13 Aug 2001 07:12:40 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7DCBPJ08419; Mon, 13 Aug 2001 07:11:25 -0500 Message-Id: <200108131211.f7DCBPJ08419@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Keith Owens cc: Shanker Balan , Linux-XFS Subject: Re: XFS patch for stable kernel 2.4.8 In-Reply-To: Message from Keith Owens of "Mon, 13 Aug 2001 16:24:14 +1000." <11189.997683854@kao2.melbourne.sgi.com> Date: Mon, 13 Aug 2001 07:11:25 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Mon, 13 Aug 2001 11:11:56 +0530, > Shanker Balan wrote: > >Have the Linux-XFS maintainers put out a XFS CVS patch against kernel > >2.4.8 yet? > > > >ftp://oss.sgi.com/projects/xfs/download/patches/ is only up to > >2.4.8pre4. > > Not yet. The CVS tree is up to 2.4.8-pre7 but tracking the recent VM > changes requires a bit of time to ensure that the code works correctly. > Besides, it is still the weekend in USA. 2.4.8 is on its way (I see 2.4.9-pre2 is out, ho hum) this one has proved more difficult due to changes from Al Viro, these basically meant I needed to rework how we trigger syncing inodes to disk in XFS. The cvs tree is currently at 2.4.8-pre7, I have pushed out a 2.4.8-pre7 patch in case 2.4.8 has issues. All this should be showing up on oss today. Steve From owner-linux-xfs@oss.sgi.com Mon Aug 13 10:41:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DHfJ714482 for linux-xfs-outgoing; Mon, 13 Aug 2001 10:41:19 -0700 Received: from mail.corbett-msc.com (mail.corbett-msc.com [4.21.114.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DHfEj14460 for ; Mon, 13 Aug 2001 10:41:14 -0700 Received: (qmail 21489 invoked from network); 13 Aug 2001 17:41:08 -0000 Received: from 24-163-96-233.ff.cox.rr.com (HELO adampc) (apendlet@24.163.96.233) by mail.corbett-msc.com with SMTP; 13 Aug 2001 17:41:08 -0000 From: "Adam H. Pendleton" To: Subject: XFS Program Tarballs Date: Mon, 13 Aug 2001 13:41:03 -0400 Message-ID: <000701c1241f$1fbdc0c0$650aa8c0@vauntmure.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C123FD.98AC20C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C123FD.98AC20C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am doing a XFS install onto a Slackware 8 machine, and I am looking for the command tarballs to configure and install. In the cmd_tars directory, there is no quota.tar.gz. There is an .rpm for it, but I would like a source tarball for quota. I do need one, correct? = What=92s up? =20 Adam Pendleton ------=_NextPart_000_0008_01C123FD.98AC20C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I am doing a XFS install onto a Slackware 8 machine, and I am looking for the command tarballs to configure and install.  = In the cmd_tars directory, there is no quota.tar.gz.  There is an .rpm for it, but I = would like a source tarball for quota.  I do need one, correct?  What=92s = up?

 

Adam Pendleton

------=_NextPart_000_0008_01C123FD.98AC20C0-- From owner-linux-xfs@oss.sgi.com Mon Aug 13 10:49:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DHn6u14715 for linux-xfs-outgoing; Mon, 13 Aug 2001 10:49:06 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DHn4j14696 for ; Mon, 13 Aug 2001 10:49:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA09952 for ; Mon, 13 Aug 2001 10:47:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2701232; Mon, 13 Aug 2001 12:47:47 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA42757; Mon, 13 Aug 2001 12:47:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7DHkUc19411; Mon, 13 Aug 2001 12:46:30 -0500 Message-Id: <200108131746.f7DHkUc19411@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Adam H. Pendleton" cc: linux-xfs@oss.sgi.com Subject: Re: XFS Program Tarballs In-Reply-To: Message from "Adam H. Pendleton" of "Mon, 13 Aug 2001 13:41:03 EDT." <000701c1241f$1fbdc0c0$650aa8c0@vauntmure.com> Date: Mon, 13 Aug 2001 12:46:30 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > This is a multi-part message in MIME format. > > ------=_NextPart_000_0008_01C123FD.98AC20C0 > Content-Type: text/plain; > charset="Windows-1252" > Content-Transfer-Encoding: quoted-printable > > I am doing a XFS install onto a Slackware 8 machine, and I am looking > for the command tarballs to configure and install. In the cmd_tars > directory, there is no quota.tar.gz. There is an .rpm for it, but I > would like a source tarball for quota. I do need one, correct? = > What=92s > up? > =20 > Adam Pendleton > Basically, you need to go to the quota project on sourceforge and get the latest quota package from there. Steve Hey no writing email from microsoft machines! > ------=_NextPart_000_0008_01C123FD.98AC20C0 > Content-Type: text/html; > charset="Windows-1252" > Content-Transfer-Encoding: quoted-printable > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> > From owner-linux-xfs@oss.sgi.com Mon Aug 13 10:49:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DHnVX14840 for linux-xfs-outgoing; Mon, 13 Aug 2001 10:49:31 -0700 Received: from mail.corbett-msc.com (mail.corbett-msc.com [4.21.114.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DHnTj14810 for ; Mon, 13 Aug 2001 10:49:29 -0700 Received: (qmail 21578 invoked from network); 13 Aug 2001 17:49:23 -0000 Received: from 24-163-96-233.ff.cox.rr.com (HELO adampc) (apendlet@24.163.96.233) by mail.corbett-msc.com with SMTP; 13 Aug 2001 17:49:23 -0000 From: "Adam H. Pendleton" To: "'Steve Lord'" Cc: Subject: RE: XFS Program Tarballs Date: Mon, 13 Aug 2001 13:49:18 -0400 Message-ID: <000c01c12420$471b2800$650aa8c0@vauntmure.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 In-Reply-To: <200108131746.f7DHkUc19411@jen.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If it weren't for EverQuest and CounterStrike, I would never use a Windows machine. :) Adam -----Original Message----- From: Steve Lord [mailto:lord@sgi.com] Sent: Monday, August 13, 2001 1:47 PM To: Adam H. Pendleton Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Program Tarballs > This is a multi-part message in MIME format. > > ------=_NextPart_000_0008_01C123FD.98AC20C0 > Content-Type: text/plain; > charset="Windows-1252" > Content-Transfer-Encoding: quoted-printable > > I am doing a XFS install onto a Slackware 8 machine, and I am looking > for the command tarballs to configure and install. In the cmd_tars > directory, there is no quota.tar.gz. There is an .rpm for it, but I > would like a source tarball for quota. I do need one, correct? = > What=92s > up? > =20 > Adam Pendleton > Basically, you need to go to the quota project on sourceforge and get the latest quota package from there. Steve Hey no writing email from microsoft machines! > ------=_NextPart_000_0008_01C123FD.98AC20C0 > Content-Type: text/html; > charset="Windows-1252" > Content-Transfer-Encoding: quoted-printable > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> > From owner-linux-xfs@oss.sgi.com Mon Aug 13 10:50:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DHoNR14969 for linux-xfs-outgoing; Mon, 13 Aug 2001 10:50:23 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DHoLj14948 for ; Mon, 13 Aug 2001 10:50:21 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA02815 for ; Mon, 13 Aug 2001 10:48:21 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2701174; Mon, 13 Aug 2001 12:49:05 -0500 (CDT) Received: from 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 MAA69966; Mon, 13 Aug 2001 12:49:04 -0500 (CDT) Message-ID: <3B781232.D4283A9B@sgi.com> Date: Mon, 13 Aug 2001 12:45:22 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Adam H. Pendleton" CC: linux-xfs@oss.sgi.com Subject: Re: XFS Program Tarballs References: <000701c1241f$1fbdc0c0$650aa8c0@vauntmure.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Adam - You can get the quota package from http://sourceforge.net/projects/linuxquota/ - all xfs-specific bits have now been incorporated into their latest release. Also, the cmd_tars/ dir is a bit out of date; there are some newer packages in cvs now. I'll update those, and you can grab them in a bit. -Eric From owner-linux-xfs@oss.sgi.com Mon Aug 13 10:53:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DHrQq15133 for linux-xfs-outgoing; Mon, 13 Aug 2001 10:53:26 -0700 Received: from twain.franken.de (mail@dsl-213-023-054-084.arcor-ip.net [213.23.54.84]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DHrNj15113 for ; Mon, 13 Aug 2001 10:53:23 -0700 Received: from smoki by twain.franken.de with local (Exim 3.22 #1 (Debian)) id 15WLsg-0000NT-00 for ; Mon, 13 Aug 2001 19:52:02 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Christian Mueller" To: Linux XFS Mailing List Subject: Adding Posix - ACL Support for S/390 Date: Mon, 13 Aug 2001 19:52:01 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01081319520100.01360@twain> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, if tried to get acl's working on s390 plattform, and i hope this is the right(?) place to post my experiance in this mailing-list. The following have i done to get acl working, for my linux/390 system.: i have add to "arch/s390/kernel/entry.S" to get posix-acl's work: .long sys_getdents64 /* 220 */ .long sys_fcntl64 + .long sys_attrctl /* 222 - Attrctrl */ + .long sys_acl_get /* 223 - ACL Syscall for get */ + .long sys_acl_set /* 224 - ACL Syscall for set */ - .rept 255-221 .rept 255-224 .long sys_ni_syscall .endr and in the "include/asm-s390/unistd.h": #define __NR_getdents64 220 +#define __NR__attrctl 222 +#define __NR__acl_get 223 +#define __NR__acl_set 224 In the "libacl/acl.c" the right syscall's for the kernel: +#define HAVE_ACL_SYSCALL 1 +# ifndef SYS__acl_get +# define SYS__acl_get 223 +# endif +# ifndef SYS__acl_set +# define SYS__acl_set 224 +# endif This is the first time, i try to but a patch(?) to something, and i dont know how i have to do this. Have i somewhere to ask to get offical SYSCALL Numbers for s/390, if yes, where? have i post this, to this mailing-list or somewhere else (IBM?) Thanks and i hope, i have done right, if not, tell me :-) Christian Mueller From owner-linux-xfs@oss.sgi.com Mon Aug 13 11:02:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DI2bH15383 for linux-xfs-outgoing; Mon, 13 Aug 2001 11:02:37 -0700 Received: from mail.levigo.de (mail.levigo.de [193.197.156.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DI2Zj15364 for ; Mon, 13 Aug 2001 11:02:35 -0700 Received: from levigo.de (zoidberg.cogito.de [193.197.156.88]) by mail.levigo.de (Postfix) with ESMTP id 95C857EAE for ; Mon, 13 Aug 2001 20:01:05 +0200 (CEST) Message-ID: <3B781639.41D932EA@levigo.de> Date: Mon, 13 Aug 2001 20:02:33 +0200 From: Klaus Rein Organization: levigo systems gmbh X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: strange nfs... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > XFS pre allocates pieces of disk to reduce fragmentation. After time this > will be returned. It is a feature :-) How long will it take? After six days the space is still not returned. Is there a way to force it? > Can't come up with the exact message, try the searchable mail archive. It > has come up before. I can not find it - I think I tried the wrong key words... :-( Klaus. From owner-linux-xfs@oss.sgi.com Mon Aug 13 11:04:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DI4I615509 for linux-xfs-outgoing; Mon, 13 Aug 2001 11:04:18 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DI4Gj15490 for ; Mon, 13 Aug 2001 11:04:16 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 0F0071E6FD; Mon, 13 Aug 2001 20:04:11 +0200 (MEST) Date: Mon, 13 Aug 2001 20:04:05 +0200 From: Andi Kleen To: Christian Mueller Cc: Linux XFS Mailing List Subject: Re: Adding Posix - ACL Support for S/390 Message-ID: <20010813200405.A14888@gruyere.muc.suse.de> References: <01081319520100.01360@twain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01081319520100.01360@twain>; from smoki@irrenhaus.org on Mon, Aug 13, 2001 at 07:52:01PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Aug 13, 2001 at 07:52:01PM +0200, Christian Mueller wrote: > This is the first time, i try to but a patch(?) to something, and i dont know > how i have to do this. > Have i somewhere to ask to get offical SYSCALL Numbers for s/390, if yes, > where? > have i post this, to this mailing-list or somewhere else (IBM?) Usually it is the architecture maintainer's task to allocate syscall numbers; in this case the maintainer is IBM. Just ask them for reserved slots for these functions. The XFS patch would then turn these reserved slots into the actual calls. -Andi From owner-linux-xfs@oss.sgi.com Mon Aug 13 11:09:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DI9r115714 for linux-xfs-outgoing; Mon, 13 Aug 2001 11:09:53 -0700 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 f7DI9pj15683 for ; Mon, 13 Aug 2001 11:09:51 -0700 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 f7DIEWS30536 for ; Mon, 13 Aug 2001 11:14:32 -0700 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 NAA2701126; Mon, 13 Aug 2001 13:08:30 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA14534; Mon, 13 Aug 2001 13:08:29 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7DI7Cr23106; Mon, 13 Aug 2001 13:07:12 -0500 Message-Id: <200108131807.f7DI7Cr23106@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Klaus Rein cc: linux-xfs@oss.sgi.com Subject: Re: strange nfs... In-Reply-To: Message from Klaus Rein of "Mon, 13 Aug 2001 20:02:33 +0200." <3B781639.41D932EA@levigo.de> Date: Mon, 13 Aug 2001 13:07:12 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Seth Mos wrote: > > > XFS pre allocates pieces of disk to reduce fragmentation. After time this > > will be returned. It is a feature :-) > > How long will it take? After six days the space is still not returned. > Is there a way to force it? > > > Can't come up with the exact message, try the searchable mail archive. It > > has come up before. > > I can not find it - I think I tried the wrong key words... > :-( > > Klaus. Hmm, XFS when running under an nfs server, will keep an extra reference on the last set of files accessed. This prevents xfs from constantly freeing this space and then reallocating it on the next write and is a very major performance win in NFS. Now entries are supposed to get dropped from the cache over time when the system is idle, it should not take many minutes for this to happen, it sounds like this part is broken. If you unmount the filesystem and then remount it the files should report using the correct amount of space again. Steve From owner-linux-xfs@oss.sgi.com Mon Aug 13 11:14:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DIER416005 for linux-xfs-outgoing; Mon, 13 Aug 2001 11:14:27 -0700 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 f7DIEQj15986 for ; Mon, 13 Aug 2001 11:14:26 -0700 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 f7DIJ7S31177 for ; Mon, 13 Aug 2001 11:19:07 -0700 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 NAA2701801 for ; Mon, 13 Aug 2001 13:13:05 -0500 (CDT) Received: from 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 NAA39261 for ; Mon, 13 Aug 2001 13:13:04 -0500 (CDT) Message-ID: <3B7818B0.FEF6356@sgi.com> Date: Mon, 13 Aug 2001 13:13:04 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.8 devel snapshot patch available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A development snapshot patch against 2.4.8 is now available in ftp://oss.sgi.com/projects/xfs/download/patches/ Steve said this merge was a bit trickier, so all the usual dire warnings about development snapshots certainly apply here. -Eric From owner-linux-xfs@oss.sgi.com Mon Aug 13 12:18:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJIeH17110 for linux-xfs-outgoing; Mon, 13 Aug 2001 12:18:40 -0700 Received: from mail.corbett-msc.com (mail.corbett-msc.com [4.21.114.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DJIWj17091 for ; Mon, 13 Aug 2001 12:18:32 -0700 Received: (qmail 796 invoked from network); 13 Aug 2001 19:18:26 -0000 Received: from 24-163-96-233.ff.cox.rr.com (HELO adampc) (apendlet@24.163.96.233) by mail.corbett-msc.com with SMTP; 13 Aug 2001 19:18:26 -0000 From: "Adam H. Pendleton" To: Subject: New tarball error Date: Mon, 13 Aug 2001 15:18:24 -0400 Message-ID: <000001c1242c$b968d220$650aa8c0@vauntmure.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C1240B.32573220" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C1240B.32573220 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One of the new tarballs generated today: =20 -rw-r=97r-- 1 10190 10010 77653 Aug 13 11:28 acl-1.1.2.src.tar.gz =20 Is missing two .h files from facl/. =20 getfacl.c:33: user_group.h: No such file or directory getfacl.c:34: walk_tree.h: No such file or directory. =20 I ended up just making the cmd=92s from the CVS tree, but I just wanted = to let you guys know. =20 Adam Pendleton ------=_NextPart_000_0001_01C1240B.32573220 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

One of the new tarballs = generated today:

 

-rw-r=97r--=A0=A0=A0 = =A01=A0 10190=A0=A0=A0=A0 = 10010=A0=A0=A0=A0=A0=A0=A0=A0=A0 77653 Aug = 13 11:28 = acl-1.1.2.src.tar.gz

 

Is missing two .h files from facl/.

 

getfacl.c:33: user_group.h: No such file or directory

getfacl.c:34: walk_tree.h: No such file or directory.

 

I ended up just making the cmd=92s from the CVS tree, but I just wanted to let you guys = know.

 

Adam Pendleton

------=_NextPart_000_0001_01C1240B.32573220-- From owner-linux-xfs@oss.sgi.com Mon Aug 13 12:24:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJOtJ17295 for linux-xfs-outgoing; Mon, 13 Aug 2001 12:24:55 -0700 Received: from mail.corbett-msc.com (mail.corbett-msc.com [4.21.114.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DJOoj17276 for ; Mon, 13 Aug 2001 12:24:50 -0700 Received: (qmail 816 invoked from network); 13 Aug 2001 19:24:44 -0000 Received: from 24-163-96-233.ff.cox.rr.com (HELO adampc) (apendlet@24.163.96.233) by mail.corbett-msc.com with SMTP; 13 Aug 2001 19:24:44 -0000 From: "Adam H. Pendleton" To: Subject: Another error Date: Mon, 13 Aug 2001 15:24:43 -0400 Message-ID: <000701c1242d$9ae965c0$650aa8c0@vauntmure.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C1240C.13D7C5C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C1240C.13D7C5C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry to be that guy today, but there is another error when compiling the dmapi command tree from CVS, on Slackware 8. The include/dmapi.h file #include()=92s , but in order to pull in the mode_t = on Slackware (don=92t know about any other distro yet), you must also #include . After adding that line, it compiled fine. =20 Adam Pendleton ------=_NextPart_000_0008_01C1240C.13D7C5C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Sorry to be that guy today, but there is another = error when compiling the dmapi command tree from CVS, = on Slackware 8.=A0 = The include/dmapi.h file #include()=92s <linux/types.h>, but in order to pull = in the mode_t on Slackware = (don=92t know about any other distro yet), you must = also #include <sys/types.h>.=A0 After adding that line, it compiled = fine.

 

Adam Pendleton

------=_NextPart_000_0008_01C1240C.13D7C5C0-- From owner-linux-xfs@oss.sgi.com Mon Aug 13 12:33:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJX2f17476 for linux-xfs-outgoing; Mon, 13 Aug 2001 12:33:02 -0700 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 f7DJX1j17455 for ; Mon, 13 Aug 2001 12:33:01 -0700 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 f7DJciW09251 for ; Mon, 13 Aug 2001 12:38:44 -0700 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 OAA2652704; Mon, 13 Aug 2001 14:31:39 -0500 (CDT) Received: from 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 OAA71093; Mon, 13 Aug 2001 14:31:38 -0500 (CDT) Message-ID: <3B782B1B.3F58D8D4@sgi.com> Date: Mon, 13 Aug 2001 14:31:39 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Adam H. Pendleton" CC: linux-xfs@oss.sgi.com Subject: Re: New tarball error References: <000001c1242c$b968d220$650aa8c0@vauntmure.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > One of the new tarballs generated today: > > -rw-r-r-- 1 10190 10010 77653 Aug 13 11:28 acl-1.1.2.src.tar.gz > > Is missing two .h files from facl/. Hm, I just generated them with the automatic build scripts, I'll take a look. (BTW, do you think you could configure your mail client to NOT send HTML mail to the list? It crashes my mailer when I try to reply. :/) Eric -Eric From owner-linux-xfs@oss.sgi.com Mon Aug 13 12:34:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJYJv17625 for linux-xfs-outgoing; Mon, 13 Aug 2001 12:34:19 -0700 Received: from mail.corbett-msc.com (mail.corbett-msc.com [4.21.114.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DJYHj17601 for ; Mon, 13 Aug 2001 12:34:17 -0700 Received: (qmail 854 invoked from network); 13 Aug 2001 19:34:11 -0000 Received: from 24-163-96-233.ff.cox.rr.com (HELO adampc) (apendlet@24.163.96.233) by mail.corbett-msc.com with SMTP; 13 Aug 2001 19:34:11 -0000 From: "Adam H. Pendleton" To: "'Eric Sandeen'" Cc: Subject: RE: New tarball error Date: Mon, 13 Aug 2001 15:34:09 -0400 Message-ID: <000e01c1242e$ecbd2980$650aa8c0@vauntmure.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3B782B1B.3F58D8D4@sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry about that. I noticed that a few minutes ago and corrected it. You would think it would not be the default option in any MUA nowawadys. Hmm... Adam -----Original Message----- From: eric@sgi.com [mailto:eric@sgi.com] On Behalf Of Eric Sandeen Sent: Monday, August 13, 2001 3:32 PM To: Adam H. Pendleton Cc: linux-xfs@oss.sgi.com Subject: Re: New tarball error > One of the new tarballs generated today: > > -rw-r-r-- 1 10190 10010 77653 Aug 13 11:28 acl-1.1.2.src.tar.gz > > Is missing two .h files from facl/. Hm, I just generated them with the automatic build scripts, I'll take a look. (BTW, do you think you could configure your mail client to NOT send HTML mail to the list? It crashes my mailer when I try to reply. :/) Eric -Eric From owner-linux-xfs@oss.sgi.com Mon Aug 13 12:46:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJklt18030 for linux-xfs-outgoing; Mon, 13 Aug 2001 12:46:47 -0700 Received: from kaperfahrt.nebelschwaden.de ([62.16.151.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DJkhj18011 for ; Mon, 13 Aug 2001 12:46:43 -0700 Received: from nazgul.nebelschwaden.de (nazgul.nebelschwaden.de [172.16.36.10]) by kaperfahrt.nebelschwaden.de (Postfix) with ESMTP id B54621284 for ; Mon, 13 Aug 2001 21:46:27 +0200 (CEST) Received: from nebelschwaden.de (nazgul.nebelschwaden.de [172.16.36.10]) by nazgul.nebelschwaden.de (Postfix) with ESMTP id 65E0057AC for ; Mon, 13 Aug 2001 21:46:29 +0200 (CEST) Message-ID: <3B782E95.10205@nebelschwaden.de> Date: Mon, 13 Aug 2001 21:46:29 +0200 From: List Account Reply-To: listac@nebelschwaden.de User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010807 X-Accept-Language: de, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsdump problem (blocksize) References: <11189.997683854@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have run into a slight problem with xfsdump - though it is more of general nature, I hope it not too of topic. That is, how do I determine the correct block size for my tape drive (Exabyte exb-8900 mammoth). Using "mt setblk 0" works (and is recommended) for tar, but not for xfsdump. Setting no blocksize at all does not work, either. Anyway, since I do not really understand the impact of the blocksize (and on what it is dependand) I do not really dare to fool around with it - it is finally about backup. Below is the output, first for no blocksize set and second for variable blocksize: root@kaperfahrt:~/bin# xfsdump -o -l 0 -v trace -F -L test -M test -f /dev/tape /dev/hdg1 xfsdump: version 3.0 - Running single-threaded xfsdump: WARNING: most recent level 0 dump was interrupted, but not resuming that dump since resume (-R) option not specified xfsdump: level 0 dump of kaperfahrt:/mnt/d_hdg1 xfsdump: dump date: Mon Aug 13 21:22:55 2001 xfsdump: session id: e8ec9aa6-dd82-43ce-91f8-655664a5f91a xfsdump: session label: "test" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 11599985152 bytes xfsdump: preparing drive xfsdump: fixed block size tape drive at /dev/tape xfsdump: unable to set block size to 1048576 xfsdump: dump size (non-dir files) : 0 bytes xfsdump: NOTE: dump interrupted: 0 seconds elapsed: may resume later using -R option root@kaperfahrt:~/bin# syslog: Aug 13 21:22:55 kaperfahrt kernel: st0: Block limits 1 - 245760 bytes. Aug 13 21:22:55 kaperfahrt kernel: st0: Illegal block size. -------------- >mt setblk 0 root@kaperfahrt:~/bin# xfsdump -o -l 0 -v trace -F -L test -M test -f /dev/tape /dev/hdg1 xfsdump: version 3.0 - Running single-threaded xfsdump: WARNING: most recent level 0 dump was interrupted, but not resuming that dump since resume (-R) option not specified xfsdump: level 0 dump of kaperfahrt:/mnt/d_hdg1 xfsdump: dump date: Mon Aug 13 21:23:41 2001 xfsdump: session id: a96cd865-e050-4e52-883c-d3a657494e28 xfsdump: session label: "test" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 11599985152 bytes xfsdump: preparing drive xfsdump: variable block size tape drive at /dev/tape xfsdump: WARNING: media may contain data. Overwrite option specified xfsdump: dump size (non-dir files) : 0 bytes xfsdump: NOTE: dump interrupted: 0 seconds elapsed: may resume later using -R option root@kaperfahrt:~/bin# (no syslog entry) From owner-linux-xfs@oss.sgi.com Mon Aug 13 12:54:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJs7g18193 for linux-xfs-outgoing; Mon, 13 Aug 2001 12:54:07 -0700 Received: from homer.mkintl.com (cloven-ext.nks.net [216.139.204.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DJs5j18174 for ; Mon, 13 Aug 2001 12:54:05 -0700 Received: from illusionary.com (two.nks.net [192.168.1.22]) by homer.mkintl.com (8.9.3/8.9.3) with ESMTP id PAA09101 for ; Mon, 13 Aug 2001 15:53:59 -0400 Message-ID: <3B783057.B5A60634@illusionary.com> Date: Mon, 13 Aug 2001 15:53:59 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: problem compiling dmapi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When trying to build the dmapi stuff from CVS on 20010813 on my (mostly) Debian 2.2 box, I get a whole pile of errors, starting with: In file included from dm_attr.c:33: ../include/dmapi.h:308: parse error before `mode_t' ../include/dmapi.h:308: warning: no semicolon at end of struct or union ../include/dmapi.h:314: parse error before `}' ../include/dmapi.h:318: parse error before `mode_t' ../include/dmapi.h:318: warning: no semicolon at end of struct or union ../include/dmapi.h:324: parse error before `}' ../include/dmapi.h:344: parse error before `mode_t' [several hundred more errors deleted......] I know this is an easy one, and usually means include files not in the right places or something, but I have the proper /usr/include/linux and /usr/include/asm in place, kernel source in the "usual" place, etc. Errors pop up if I'm trying to build a debian package (using debian/rules) or by running the ./configure;make by hand. I can't for the life of me figure out what I'm missing... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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.eff.org/ http://www.opendvd.org/ http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ From owner-linux-xfs@oss.sgi.com Mon Aug 13 12:59:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJx0u18341 for linux-xfs-outgoing; Mon, 13 Aug 2001 12:59:00 -0700 Received: from mail.corbett-msc.com (mail.corbett-msc.com [4.21.114.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DJwwj18321 for ; Mon, 13 Aug 2001 12:58:58 -0700 Received: (qmail 920 invoked from network); 13 Aug 2001 19:58:52 -0000 Received: from 24-163-96-233.ff.cox.rr.com (HELO adampc) (apendlet@24.163.96.233) by mail.corbett-msc.com with SMTP; 13 Aug 2001 19:58:52 -0000 From: "Adam H. Pendleton" To: "'Derek Glidden'" , Subject: RE: problem compiling dmapi Date: Mon, 13 Aug 2001 15:58:50 -0400 Message-ID: <000f01c12432$5f310f60$650aa8c0@vauntmure.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3B783057.B5A60634@illusionary.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I actually just sent the fix to the list. In include/dmapi.h, add the line: #include under the line #include and it will compile. Adam Pendleton -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com] On Behalf Of Derek Glidden Sent: Monday, August 13, 2001 3:54 PM To: linux-xfs@oss.sgi.com Subject: problem compiling dmapi When trying to build the dmapi stuff from CVS on 20010813 on my (mostly) Debian 2.2 box, I get a whole pile of errors, starting with: In file included from dm_attr.c:33: ../include/dmapi.h:308: parse error before `mode_t' ../include/dmapi.h:308: warning: no semicolon at end of struct or union ../include/dmapi.h:314: parse error before `}' ../include/dmapi.h:318: parse error before `mode_t' ../include/dmapi.h:318: warning: no semicolon at end of struct or union ../include/dmapi.h:324: parse error before `}' ../include/dmapi.h:344: parse error before `mode_t' [several hundred more errors deleted......] I know this is an easy one, and usually means include files not in the right places or something, but I have the proper /usr/include/linux and /usr/include/asm in place, kernel source in the "usual" place, etc. Errors pop up if I'm trying to build a debian package (using debian/rules) or by running the ./configure;make by hand. I can't for the life of me figure out what I'm missing... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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.eff.org/ http://www.opendvd.org/ http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ From owner-linux-xfs@oss.sgi.com Mon Aug 13 12:59:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJx6118418 for linux-xfs-outgoing; Mon, 13 Aug 2001 12:59:06 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DJx5j18393 for ; Mon, 13 Aug 2001 12:59:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA09870 for ; Mon, 13 Aug 2001 12:59:04 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2682163; Mon, 13 Aug 2001 14:57:48 -0500 (CDT) Received: from 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 OAA75956; Mon, 13 Aug 2001 14:57:47 -0500 (CDT) Message-ID: <3B78313C.6B05BA29@sgi.com> Date: Mon, 13 Aug 2001 14:57:48 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Derek Glidden CC: linux-xfs@oss.sgi.com Subject: Re: problem compiling dmapi References: <3B783057.B5A60634@illusionary.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Derek Glidden wrote: > > When trying to build the dmapi stuff from CVS on 20010813 on my (mostly) > Debian 2.2 box, I get a whole pile of errors, starting with: > > In file included from dm_attr.c:33: > ../include/dmapi.h:308: parse error before `mode_t' Funny you should ask, Adam just ran into this... most likely the same problem? Adam H. Pendleton wrote: > > Sorry to be that guy today, but there is another error when compiling the > dmapi command tree from CVS, on Slackware 8. The > include/dmapi.h file #include()?s , but in order to pull in > the mode_t on Slackware (don?t know about any other distro yet), > you must also #include . After adding that line, it compiled fine. -Eric From owner-linux-xfs@oss.sgi.com Mon Aug 13 13:00:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DK0gQ18650 for linux-xfs-outgoing; Mon, 13 Aug 2001 13:00:42 -0700 Received: from chimta02 (chimta02.algx.net [216.99.233.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DK0ej18631 for ; Mon, 13 Aug 2001 13:00:40 -0700 Received: from jtsdell (66-2-81-28.customer.algx.net [66.2.81.28]) by chimmx02.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GI000COAVIS9D@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Mon, 13 Aug 2001 14:59:17 -0500 (CDT) Date: Mon, 13 Aug 2001 15:59:33 -0400 (EDT) From: John Trostel Subject: libacl.lai vs. libacl.la in cmd/acl To: XFS list Reply-to: John Trostel Message-id: Organization: Connex MIME-version: 1.0 X-Mailer: XFMail 1.5.0 on Linux Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When I make configure, make, make install on the ../cmd/acl directory in the latest CVS of XFS, I get some warnings. They look like this: === libacl === cd ../libacl/.libs; ../../install-sh -o root -g root -m 755 -d /lib; ../../install-sh -o root -g root -m 644 -T so_dot_version libacl.lai /lib; test "SGI XFS" = debian || ../../install-sh -o root -g root -T so_dot_current libacl.lai /lib === chacl === ../install-sh -o root -g root -m 755 -d /bin /usr/bin/libtool --mode=install ../install-sh -o root -g root -m 755 chacl /bin libtool: install: warning: `../libacl/libacl.la' has not been installed in `/lib' ../install-sh -o root -g root -m 755 .libs/chacl /bin/chacl It's this warning about libacl.la not being installed in /lib that caught my eye. If I go back and manually install libacl.la (from the ../cmd/acl/libacl directory) into /lib, I no longer get the warning. My real question is why am I getting the warning? Is it just my setup or is there a problem with the make? -- John M. Trostel Senior Software Engineer Quantum / SnapAppliances jtrostel@mindspring.com From owner-linux-xfs@oss.sgi.com Mon Aug 13 13:24:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DKOmq19230 for linux-xfs-outgoing; Mon, 13 Aug 2001 13:24:48 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DKOjj19211 for ; Mon, 13 Aug 2001 13:24:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA08202 for ; Mon, 13 Aug 2001 13:22:45 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2703604 for ; Mon, 13 Aug 2001 15:23:29 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA76339 for ; Mon, 13 Aug 2001 15:23:29 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id PAA35973; Mon, 13 Aug 2001 15:23:28 -0500 (CDT) Message-Id: <200108132023.PAA35973@slobber.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: libacl.lai vs. libacl.la in cmd/acl Date: Mon, 13 Aug 2001 15:23:28 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: John Trostel >When I make configure, make, make install on the ../cmd/acl directory in the >latest CVS of XFS, I get some warnings. They look like this: > >=== libacl === >cd ../libacl/.libs; ../../install-sh -o root -g root -m 755 -d /lib; >../../install-sh -o root -g root -m 644 -T so_dot_version libacl.lai /lib; tes >t >"SGI XFS" = debian || ../../install-sh -o root -g root -T so_dot_current >libacl.lai /lib >=== chacl === >../install-sh -o root -g root -m 755 -d /bin >/usr/bin/libtool --mode=install ../install-sh -o root -g root -m 755 chacl /bi >n >libtool: install: warning: `../libacl/libacl.la' has not been installed in >`/lib' >../install-sh -o root -g root -m 755 .libs/chacl /bin/chacl > >It's this warning about libacl.la not being installed in /lib that caught my >eye. If I go back and manually install libacl.la (from the ../cmd/acl/libacl >directory) into /lib, I no longer get the warning. > >My real question is why am I getting the warning? Is it just my setup or is >there a problem with the make? It's not a problem. The libacl.la hasn't been installed by that point, and isn't needed by then, either. By the time all the pieces are installed everything will be where it needs to be. Dean From owner-linux-xfs@oss.sgi.com Mon Aug 13 13:41:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DKfoj19630 for linux-xfs-outgoing; Mon, 13 Aug 2001 13:41:50 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DKfmj19611 for ; Mon, 13 Aug 2001 13:41:48 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAB07568 for ; Mon, 13 Aug 2001 13:41:48 -0700 (PDT) mail_from (roehrich@sgi.com) 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 WAA19026 for ; Mon, 13 Aug 2001 22:39:17 +0200 (CEST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2702916; Mon, 13 Aug 2001 15:37:56 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA46876; Mon, 13 Aug 2001 15:37:55 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id PAA35970; Mon, 13 Aug 2001 15:37:54 -0500 (CDT) Message-Id: <200108132037.PAA35970@slobber.americas.sgi.com> To: linux-xfs@oss.sgi.com cc: Derek Glidden , apendlet@corbett-msc.com Subject: Re: problem compiling dmapi Date: Mon, 13 Aug 2001 15:37:54 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adam, Derek, will this solution work if the is #include'd prior to the ? If I do it the way Adam's described it then I run into redefinitions on RH 7.1. (and it does require on RH 7.1) Dean >From: Eric Sandeen >Adam H. Pendleton wrote: >> >> Sorry to be that guy today, but there is another error when compiling the >> dmapi command tree from CVS, on Slackware 8. The >> include/dmapi.h file #include()?s , but in order to pull in >> the mode_t on Slackware (don?t know about any other distro yet), >> you must also #include . After adding that line, it compiled f >ine. > >-Eric > From owner-linux-xfs@oss.sgi.com Mon Aug 13 13:48:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DKmhe19890 for linux-xfs-outgoing; Mon, 13 Aug 2001 13:48:43 -0700 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 f7DKmgj19871 for ; Mon, 13 Aug 2001 13:48:42 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7DKrNS08924 for ; Mon, 13 Aug 2001 13:53:23 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f7DKlZF35939306 for ; Mon, 13 Aug 2001 13:47:35 -0700 (PDT) Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA19024 for ; Mon, 13 Aug 2001 22:42:32 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f7DKfNF34131736 for ; Mon, 13 Aug 2001 13:41:24 -0700 (PDT) Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA18639 for ; Mon, 13 Aug 2001 22:35:02 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2699427; Mon, 13 Aug 2001 15:33:40 -0500 (CDT) Received: from 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 PAA91551; Mon, 13 Aug 2001 15:33:39 -0500 (CDT) Message-ID: <3B7839A3.69A052D2@sgi.com> Date: Mon, 13 Aug 2001 15:33:39 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Adam H. Pendleton" CC: linux-xfs@oss.sgi.com Subject: Re: New tarball error References: <000001c1242c$b968d220$650aa8c0@vauntmure.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > One of the new tarballs generated today: > > -rw-r-r-- 1 10190 10010 77653 Aug 13 11:28 acl-1.1.2.src.tar.gz > > Is missing two .h files from facl/. > > getfacl.c:33: user_group.h: No such file or directory > > getfacl.c:34: walk_tree.h: No such file or directory. Hm, I'm sure this is a simple one to fix, but I'll let the userspace gurus in Australia do the build voodoo they do so well... -Eric From owner-linux-xfs@oss.sgi.com Mon Aug 13 13:57:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DKvLP20237 for linux-xfs-outgoing; Mon, 13 Aug 2001 13:57:21 -0700 Received: from chimta02 (chimta02.algx.net [216.99.233.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DKvIj20218 for ; Mon, 13 Aug 2001 13:57:19 -0700 Received: from jtsdell (66-2-81-28.customer.algx.net [66.2.81.28]) by chimmx02.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GI000CDKY7HHI@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Mon, 13 Aug 2001 15:57:18 -0500 (CDT) Date: Mon, 13 Aug 2001 16:57:37 -0400 (EDT) From: John Trostel Subject: Re: libacl.lai vs. libacl.la in cmd/acl In-reply-to: <200108132023.PAA35973@slobber.americas.sgi.com> To: Dean Roehrich Cc: linux-xfs@oss.sgi.com Reply-to: John Trostel Message-id: Organization: Connex MIME-version: 1.0 X-Mailer: XFMail 1.5.0 on Linux Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 13-Aug-2001 Dean Roehrich wrote: > >>From: John Trostel >>When I make configure, make, make install on the ../cmd/acl directory in the >>latest CVS of XFS, I get some warnings. They look like this: ... snip >>libtool: install: warning: `../libacl/libacl.la' has not been installed in >>`/lib' >>../install-sh -o root -g root -m 755 .libs/chacl /bin/chacl snip.. > > It's not a problem. The libacl.la hasn't been installed by that point, and > isn't needed by then, either. > > By the time all the pieces are installed everything will be where it needs to > be. > > Dean Soooo.... when is it supposed to get installed? By the time I have finished out of the ../cmd/acl make configure, make, make install I would think it _should_ be installed. If I am making no other utilities it would _need_ to be installed by then. -- John M. Trostel Senior Software Engineer Quantum / SnapAppliances jtrostel@mindspring.com From owner-linux-xfs@oss.sgi.com Mon Aug 13 13:59:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DKxU820374 for linux-xfs-outgoing; Mon, 13 Aug 2001 13:59:30 -0700 Received: from homer.mkintl.com (cloven-ext.nks.net [216.139.204.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DKxSj20355 for ; Mon, 13 Aug 2001 13:59:28 -0700 Received: from illusionary.com (two.nks.net [192.168.1.22]) by homer.mkintl.com (8.9.3/8.9.3) with ESMTP id QAA09413 for ; Mon, 13 Aug 2001 16:59:22 -0400 Message-ID: <3B783FAA.199018B2@illusionary.com> Date: Mon, 13 Aug 2001 16:59:22 -0400 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: problem compiling dmapi References: <000f01c12432$5f310f60$650aa8c0@vauntmure.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Adam H. Pendleton" wrote: > > I actually just sent the fix to the list. > > In include/dmapi.h, add the line: > > #include > > under the line > > #include > > and it will compile. Yep, that fixed it, although it now spits out some "redefined" warnings. I see your original message in my mailbox now. It just skipped right past me when it came across. Sorry for the duplication. Sorry for the duplication. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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.eff.org/ http://www.opendvd.org/ http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ From owner-linux-xfs@oss.sgi.com Mon Aug 13 14:36:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DLauJ21374 for linux-xfs-outgoing; Mon, 13 Aug 2001 14:36:56 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DLasj21355 for ; Mon, 13 Aug 2001 14:36:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA03658 for ; Mon, 13 Aug 2001 14:36:38 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2675385; Mon, 13 Aug 2001 16:35:36 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA03856; Mon, 13 Aug 2001 16:35:36 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id QAA36157; Mon, 13 Aug 2001 16:35:35 -0500 (CDT) Message-Id: <200108132135.QAA36157@slobber.americas.sgi.com> To: John Trostel cc: linux-xfs@oss.sgi.com Subject: Re: libacl.lai vs. libacl.la in cmd/acl Date: Mon, 13 Aug 2001 16:35:35 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: John Trostel >Soooo.... when is it supposed to get installed? By the time I have finished ou >t >of the ../cmd/acl make configure, make, make install I would think it _should_ >be installed. If I am making no other utilities it would _need_ to be installe >d >by then. It's installed during make install_dev. If you aren't installing the dev package then I'm not sure why you'd need the libacl.la. Let's not let the tail wag the dog here--that libtool warning is nothing more than an annoyance (in a long list of libtool annoyances). Or am I missing something that you're asking about? Dean From owner-linux-xfs@oss.sgi.com Mon Aug 13 14:51:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DLp0821723 for linux-xfs-outgoing; Mon, 13 Aug 2001 14:51:00 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DLoxj21703 for ; Mon, 13 Aug 2001 14:50:59 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA08873 for ; Mon, 13 Aug 2001 14:50:40 -0700 (PDT) mail_from (roehrich@clink-eth.americas.sgi.com) Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id QAA61592 for linux-xfs@oss.sgi.com; Mon, 13 Aug 2001 16:49:35 -0500 (CDT) Date: Mon, 13 Aug 2001 16:49:35 -0500 (CDT) From: Dean Roehrich Message-Id: <200108132149.QAA61592@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - add to dmapi.h for slackware Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Aug 13 14:49:23 PDT 2001 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfsA The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100641a linux/include/linux/dmapi.h - 1.6 cmd/dmapi/include/dmapi.h - 1.2 - No Message Supplied From owner-linux-xfs@oss.sgi.com Mon Aug 13 15:55:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DMtUs22689 for linux-xfs-outgoing; Mon, 13 Aug 2001 15:55:30 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DMtSj22670 for ; Mon, 13 Aug 2001 15:55:28 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA18304 for ; Mon, 13 Aug 2001 15:55:11 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA69883; Tue, 14 Aug 2001 08:54:06 +1000 (EST) Date: Tue, 14 Aug 2001 08:54:06 +1000 (EST) From: Nathan Scott Message-Id: <200108132254.IAA69883@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: apendlet@corbett-msc.com Subject: TAKE - get/setfacl headers Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Adam, this should fix the problem. Date: Mon Aug 13 15:50:45 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100645a cmd/acl/facl/Makefile - 1.3 - don't forget the local headers, bozo. From owner-linux-xfs@oss.sgi.com Mon Aug 13 17:03:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E03Mo24134 for linux-xfs-outgoing; Mon, 13 Aug 2001 17:03:22 -0700 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 f7E03Kj24114 for ; Mon, 13 Aug 2001 17:03:20 -0700 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 f7E094W21948 for ; Mon, 13 Aug 2001 17:09:04 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA12822; Tue, 14 Aug 2001 10:01:55 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA06828; Tue, 14 Aug 2001 10:01:54 +1000 (AEST) Date: Tue, 14 Aug 2001 10:01:53 +1000 From: Nathan Scott To: Dmitry Melekhov Cc: linux-xfs@oss.sgi.com Subject: Re: copy with acl Message-ID: <20010814100153.J295821@wobbly.melbourne.sgi.com> References: <3B782D8B.3269DD9A@belkam.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B782D8B.3269DD9A@belkam.com>; from dm@belkam.com on Mon, Aug 13, 2001 at 03:42:03PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Aug 13, 2001 at 03:42:03PM -0400, Dmitry Melekhov wrote: > Hello! > > Is it possible to copy files preserving acls? > Yes - you need a patched fileutils - Andreas' ACL website has a patch which has been reported to work with the XFS libacl also. See http://acl.bestbits.at/ for details. > btw, is it possible to store acls into text file > and then restore them (we use tar for backup) ? > Yes - Andreas' getfacl/setfacl tools, which we include in the XFS ACL package now (see cvs tree), were designed for just this purpose. There is a known ACE ordering bug in the libacl code that this sits above though, so YMMV at the moment. Feel free to fix the problem, its just not reached the top of anyone's ToDo list here at the moment. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 13 17:42:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E0gKB24838 for linux-xfs-outgoing; Mon, 13 Aug 2001 17:42:20 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E0gGj24819 for ; Mon, 13 Aug 2001 17:42:16 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA09670 for ; Mon, 13 Aug 2001 17:42:14 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA78429; Tue, 14 Aug 2001 10:40:56 +1000 (EST) Date: Tue, 14 Aug 2001 10:40:56 +1000 From: Timothy Shimmin To: List Account Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump problem (blocksize) Message-ID: <20010814104056.F47269@boing.melbourne.sgi.com> References: <11189.997683854@kao2.melbourne.sgi.com> <3B782E95.10205@nebelschwaden.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3B782E95.10205@nebelschwaden.de>; from listac@nebelschwaden.de on Mon, Aug 13, 2001 at 09:46:29PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, On Mon, Aug 13, 2001 at 09:46:29PM +0200, List Account wrote: > Hi, > > I have run into a slight problem with xfsdump - though it is more of > general nature, I hope it not too of topic. Not at all. > That is, how do I determine > the correct block size for my tape drive (Exabyte exb-8900 mammoth). > Using "mt setblk 0" works (and is recommended) for tar, but not for > xfsdump. Setting no blocksize at all does not work, either. "mt setblk 0" puts the scsitape driver into variable blocksize mode. I'd recommend this for xfsdump/xfsrestore also since it easily allows the program to choose the blocksize it wants - and I've generally found that there are less hassles. xfsdump uses a default blocksize of 1Mb. (xfsdump on IRIX typically uses a default blocksize of 2Mb - more notes about this can be found in cmd/xfsdump/doc/README.xfsdump) > Below is the output, first for no blocksize set and second for variable > blocksize: > > xfsdump: preparing drive > xfsdump: fixed block size tape drive at /dev/tape > xfsdump: unable to set block size to 1048576 > root@kaperfahrt:~/bin# > > syslog: > > Aug 13 21:22:55 kaperfahrt kernel: st0: Block limits 1 - 245760 bytes. ^^^^^^ > Aug 13 21:22:55 kaperfahrt kernel: st0: Illegal block size. > >From this you can see that your blocksize limit is 245760 bytes (240K) for your tape drive. Unfortunately, the scsi tape driver does not export this upper limit (only writes it into syslog). Otherwise xfsdump/xfsrestore would be using it (as it does in IRIX). So you can see from xfsdump that it tries to set the block-size to its 1Mb default but this fails since it is greater than 240K. Tar would be fine as it typically uses a small blocksize (something like 10K - I can't remember exactly). > -------------- > >mt setblk 0 > > root@kaperfahrt:~/bin# xfsdump -o -l 0 -v trace -F -L test -M test -f > /dev/tape /dev/hdg1 > xfsdump: preparing drive > xfsdump: variable block size tape drive at /dev/tape > xfsdump: WARNING: media may contain data. Overwrite option specified > xfsdump: dump size (non-dir files) : 0 bytes > xfsdump: NOTE: dump interrupted: 0 seconds elapsed: may resume later > using -R option > root@kaperfahrt:~/bin# > Not too sure why you didn't get an error msg here. Anyway, the correct thing to do here would be to explicitly set the blocksize to 240K for xfsdump and xfsrestore using the -b option. e.g. # xfsdump -o -b 245760 -l 0 -v trace -F -L test -M test \ -f /dev/tape /dev/hdg1 And on the question of what the smallest block size that xfsdump/xfsrestore likes - I'm not too sure. Certainly 240K will work; some source comments indicate it is the minimum supported blocksize (except for QIC tapes which are special cased) and it is used as the default blocksize for remote tapes. So I know 240K should work but some auditing of the code and some experiments would be needed to see if one can go lower. Anyway, in your case it looks like 240K is supported by your tape drive. Cheers, Tim. From owner-linux-xfs@oss.sgi.com Mon Aug 13 17:55:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E0tjM25162 for linux-xfs-outgoing; Mon, 13 Aug 2001 17:55:45 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E0thj25143 for ; Mon, 13 Aug 2001 17:55:43 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAB05898 for ; Mon, 13 Aug 2001 17:55:42 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id KAA10491; Tue, 14 Aug 2001 10:54:50 +1000 Date: Tue, 14 Aug 2001 10:54:50 +1000 From: Keith Owens Message-Id: <200108140054.KAA10491@sherman.melbourne.sgi.com> Subject: TAKE - Add blank line to include/linux/fs.h Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS had deleted a blank line from fs.h which increased the size of our patch footprint. Add the blank line back again. This is a candidate for the year's smallest patch :). Date: Mon Aug 13 17:52:54 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100651a linux/include/linux/fs.h - 1.108 From owner-linux-xfs@oss.sgi.com Mon Aug 13 18:14:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E1EgB25617 for linux-xfs-outgoing; Mon, 13 Aug 2001 18:14:42 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E1Eej25598 for ; Mon, 13 Aug 2001 18:14:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA12784 for ; Mon, 13 Aug 2001 18:14:25 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA2706106 for ; Mon, 13 Aug 2001 20:13:23 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA37220 for ; Mon, 13 Aug 2001 20:13:23 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f7E1C3L26184; Mon, 13 Aug 2001 20:12:03 -0500 Message-Id: <200108140112.f7E1C3L26184@jen.americas.sgi.com> Date: Mon, 13 Aug 2001 20:12:03 -0500 Subject: TAKE - fix super block locking problems Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bug from the 2.4.8 merge, internal testing caught a hang - too few unlocks and an oops, too many unlocks (and a free). You have to use dump/restore or the regression tests to hit this I think. Date: Mon Aug 13 18:11:07 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100652a linux/fs/xfs/linux/xfs_vfs.c - 1.25 - Fix drop_super calls inside xfs, sometimes we did too many, sometimes too few. From owner-linux-xfs@oss.sgi.com Mon Aug 13 18:39:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E1d3V26125 for linux-xfs-outgoing; Mon, 13 Aug 2001 18:39:03 -0700 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 f7E1d1j26106 for ; Mon, 13 Aug 2001 18:39:01 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7E1hfS19235 for ; Mon, 13 Aug 2001 18:43:42 -0700 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA71950 for linux-xfs@oss.sgi.com; Tue, 14 Aug 2001 11:37:38 +1000 (EST) Date: Tue, 14 Aug 2001 11:37:38 +1000 (EST) From: Timothy Shimmin Message-Id: <200108140137.LAA71950@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - README.xfsdump Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Aug 13 18:36:53 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100654a cmd/xfsdump/doc/README.xfsdump - 1.5 - Add info about specifying a smaller blocksize. Update todo list. From owner-linux-xfs@oss.sgi.com Mon Aug 13 21:06:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E46g828841 for linux-xfs-outgoing; Mon, 13 Aug 2001 21:06:42 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E46dj28821 for ; Mon, 13 Aug 2001 21:06:39 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA19198 for ; Mon, 13 Aug 2001 21:06:20 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA98142 for linux-xfs@oss.sgi.com; Tue, 14 Aug 2001 14:05:14 +1000 (EST) Date: Tue, 14 Aug 2001 14:05:14 +1000 (EST) From: Nathan Scott Message-Id: <200108140405.OAA98142@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mkfs + too-small-final-AG fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Aug 13 21:04:00 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100660a cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.14 - merge of Glen's IRIX fix for the too-small-final-AG bug where XFS mkfs would create an unmountable filesystem in certain situations. cmd/xfsprogs/mkfs/Makefile - 1.7 - add a missing build dependency on maxtrres.o for maxtrres. cmd/xfsprogs/doc/CHANGES - 1.32 cmd/xfsprogs/debian/changelog - 1.24 cmd/xfsprogs/VERSION - 1.26 - bump version number. From owner-linux-xfs@oss.sgi.com Tue Aug 14 03:29:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EAT3p05263 for linux-xfs-outgoing; Tue, 14 Aug 2001 03:29:03 -0700 Received: from IIZUKA.flll.uni-linz.ac.at (iizuka.flll.uni-linz.ac.at [140.78.127.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EASMj05238 for ; Tue, 14 Aug 2001 03:28:37 -0700 Received: from shiga (shiga.flll.uni-linz.ac.at [140.78.127.65]) by IIZUKA.flll.uni-linz.ac.at (8.9.3/8.9.3) with SMTP id MAA28072 for ; Tue, 14 Aug 2001 12:24:26 +0200 (MDT) Message-ID: <000801c124aa$ae2f4be0$417f4e8c@shiga> From: "walter" To: Subject: problems making a raid with sgi installer Date: Tue, 14 Aug 2001 12:20:00 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C124BB.70DF2100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C124BB.70DF2100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I tried to install rh7.1 with the sgi installer. when trying to make a raid the installer crashes. the error report is attached to this message. ps: I'm using a pci-ide card: ultra100tx from promise, the driver for this card included by sgi works fine. ---------------------------------------------------- Walter Stadler System Administrator Fuzzy Logic Laboratorium Linz Hagenberg Softwarepark Hagenberg Hauptstr. 99 A-4232 Hagenberg, Austria Phone: ++43 7236 3343 432 Fax: ++43 7236 3343 434 ----------------------------------------------------- ------=_NextPart_000_0005_01C124BB.70DF2100 Content-Type: text/plain; name="anacdump.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="anacdump.txt" Traceback (innermost last):=0A= File "/usr/bin/anaconda", line 520, in ?=0A= intf.run(todo, test =3D test)=0A= File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 392, in run=0A= self.icw.run ()=0A= File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 880, in run=0A= mainloop ()=0A= File "/usr/lib/python1.5/site-packages/gtk.py", line 2554, in mainloop=0A= _gtk.gtk_main()=0A= File "/usr/lib/python1.5/site-packages/gtk.py", line 125, in __call__=0A= ret =3D apply(self.func, a)=0A= File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 482, in = nextClicked=0A= next =3D self.currentScreen.getNext ()=0A= File = "/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/rootpartition_gui.py", line = 130, in getNext=0A= rc =3D self.lba32Check ()=0A= File = "/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/rootpartition_gui.py", line = 76, in lba32Check=0A= maxcyl =3D self.todo.fstab.getBootPartitionMaxCylFromDesired()=0A= File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 241, in = getBootPartitionMaxCylFromDesired=0A= bootpart =3D self.getBootDevice()=0A= File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 267, in = getBootDevice=0A= for (mntpoint, partition, fsystem, doFormat, size) in = self.mountList():=0A= File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 1052, in = mountList=0A= if fsType =3D=3D "swap": continue=0A= NameError: fsType=0A= =0A= Local variables in innermost frame:=0A= size: 48132=0A= fstab: [('/', 'hda5', 'xfs', 1, 4096543), ('/boot', 'hda1', 'xfs', 0, = 24066)]=0A= mntpoint: /daten=0A= device: md0=0A= partition: hda6=0A= start: 63=0A= raidType: 0=0A= self: =0A= devices: [('hda1', '/boot', 2, 63, 48132, 3, 1), ('hda5', '/', 2, 48258, = 8193087, 513, 1), ('hda6', 'Swap000', 5, 8241408, 497952, 544, 1), = ('hda7', 'Raid000', 7, 8739423, 514017, 576, 1), ('hde1', 'Raid001', 7, = 63, 512001, 508, 1), ('hdg1', 'Raid002', 7, 63, 512001, 508, 1)]=0A= makeup: ['Raid000', 'Raid001', 'Raid002']=0A= doFormat: 0=0A= fsystem: xfs=0A= raid: [('/daten', 'md0', 'xfs', 0, 63, 48132, ['Raid000', 'Raid001', = 'Raid002'])]=0A= mount: Swap000=0A= sortMounts: =0A= skipExtra: 0=0A= =0A= ToDo object:=0A= (itodo=0A= ToDo=0A= p1=0A= (dp2=0A= S'resState'=0A= p3=0A= S''=0A= sS'progressWindow'=0A= p4=0A= NsS'setupFilesystems'=0A= p5=0A= I1=0A= sS'monitorVsync'=0A= p6=0A= S''=0A= sS'videoCardStateNode'=0A= p7=0A= S''=0A= sS'serial'=0A= p8=0A= I0=0A= sS'ddruidReadOnly'=0A= p9=0A= I0=0A= sS'bootdisk'=0A= p10=0A= I0=0A= sS'videoRamState'=0A= p11=0A= S''=0A= sS'monitorOriginalName'=0A= p12=0A= S''=0A= sS'language'=0A= p13=0A= (itodo=0A= Language=0A= (dp14=0A= S'langInfoByName'=0A= p15=0A= (dp16=0A= S'Arabic (Yemen)'=0A= p17=0A= (S'ar_YE'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Spanish (Argentina)'=0A= p18=0A= (S'es_AR'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Italian (Italy)'=0A= p19=0A= (S'it_IT@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Arabic (Lebanon)'=0A= p20=0A= (S'ar_LB'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Spanish (Guatemala)'=0A= p21=0A= (S'es_GT'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Malay (Malaysia)'=0A= p22=0A= (S'ms_MY'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Arabic (Libyan Arab Jamahiriya)'=0A= p23=0A= (S'ar_LY'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Arabic (Oman)'=0A= p24=0A= (S'ar_OM'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Arabic (Iraq)'=0A= p25=0A= (S'ar_IQ'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Arabic (Kuwait)'=0A= p26=0A= (S'ar_KW'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'English (South Africa)'=0A= p27=0A= (S'en_ZA'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'French (Switzerland)'=0A= p28=0A= (S'fr_CH'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Arabic (Bahrein)'=0A= p29=0A= (S'ar_BH'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Croatian'=0A= p30=0A= (S'hr_HR'=0A= S'iso02'=0A= S'lat2-sun16'=0A= tsS'French (France)'=0A= p31=0A= (S'fr_FR@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Greenlandic (Greenland)'=0A= p32=0A= (S'kl_GL'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Korean (Republic of Korea)'=0A= p33=0A= (S'ko_KR.euckr'=0A= S'iso01'=0A= S'lat0-16'=0A= tsS'Ukrainian'=0A= p34=0A= (S'uk_UA'=0A= S'koi8-u'=0A= S'cyr-sun16'=0A= tsS'Spanish (Mexico)'=0A= p35=0A= (S'es_MX'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Greek'=0A= p36=0A= (S'el_GR'=0A= S'iso07'=0A= S'gr.f16'=0A= tsS'Spanish (El Salvador)'=0A= p37=0A= (S'es_SV'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Spanish (Peru)'=0A= p38=0A= (S'es_PE'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Spanish (Honduras)'=0A= p39=0A= (S'es_HN'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Spanish (Costa Rica)'=0A= p40=0A= (S'es_CR'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'English (Denmark)'=0A= p41=0A= (S'en_DK'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Dutch (Netherlands)'=0A= p42=0A= (S'nl_NL@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Serbian (Yugoslavia)'=0A= p43=0A= (S'sr_YU@cyrillic'=0A= S'iso05'=0A= S'cyr-sun16'=0A= tsS'Russian (Ukraine)'=0A= p44=0A= (S'ru_UA'=0A= S'koi8-u'=0A= S'cyr-sun16'=0A= tsS'Portuguese (Portugal)'=0A= p45=0A= (S'pt_PT@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Afrikaans (South Africa)'=0A= p46=0A= (S'af_ZA'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Norwegian'=0A= p47=0A= (S'no_NO'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Arabic (Morocco)'=0A= p48=0A= (S'ar_MA'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'English (Philippines)'=0A= p49=0A= (S'en_PH'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Arabic (Algeria)'=0A= p50=0A= (S'ar_DZ'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Indonesian'=0A= p51=0A= (S'id_ID'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Danish'=0A= p52=0A= (S'da_DK'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Chinese (Taiwan R.O.C.)'=0A= p53=0A= (S'zh_TW.euctw'=0A= S'iso01'=0A= S'lat0-16'=0A= tsS'Faroese (Faroe Islands)'=0A= p54=0A= (S'fo_FO'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Galician (Spain)'=0A= p55=0A= (S'gl_ES@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'English (New Zealand)'=0A= p56=0A= (S'en_NZ'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Spanish (Bolivia)'=0A= p57=0A= (S'es_BO'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Cornish (Britain)'=0A= p58=0A= (S'kw_GB'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Arabic (United Arab Emirates)'=0A= p59=0A= (S'ar_AE'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'German (Austria)'=0A= p60=0A= (S'de_AT@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Romanian'=0A= p61=0A= (S'ro_RO'=0A= S'iso02'=0A= S'lat2-sun16'=0A= tsS'Spanish (Paraguay)'=0A= p62=0A= (S'es_PY'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Hebrew (Israel)'=0A= p63=0A= (S'he_IL'=0A= S'iso08'=0A= S'LatArCyrHeb-16'=0A= tsS'English (USA)'=0A= p64=0A= (S'en_US'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Spanish (USA)'=0A= p65=0A= (S'es_US'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Portuguese (Brasil)'=0A= p66=0A= (S'pt_BR'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Spanish (Equador)'=0A= p67=0A= (S'es_EC'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Polish'=0A= p68=0A= (S'pl_PL'=0A= S'iso02'=0A= S'lat2-sun16'=0A= tsS'Slovak'=0A= p69=0A= (S'sk_SK'=0A= S'iso02'=0A= S'lat2-sun16'=0A= tsS'Macedonian'=0A= p70=0A= (S'mk_MK'=0A= S'iso05'=0A= S'cyr-sun16'=0A= tsS'Spanish (Spain)'=0A= p71=0A= (S'es_ES@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Spanish (Chile)'=0A= p72=0A= (S'es_CL'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Arabic (Syrian Arab Republic)'=0A= p73=0A= (S'ar_SY'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Czech'=0A= p74=0A= (S'cs_CZ'=0A= S'iso02'=0A= S'lat2-sun16'=0A= tsS'Irish'=0A= p75=0A= (S'ga_IE@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Arabic (Jordan)'=0A= p76=0A= (S'ar_JO'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Italian (Switzerland)'=0A= p77=0A= (S'it_CH'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'German (Belgium)'=0A= p78=0A= (S'de_BE@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Albanian'=0A= p79=0A= (S'sq_AL'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Finnish'=0A= p80=0A= (S'fi_FI@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Swedish (Sweden)'=0A= p81=0A= (S'sv_SE'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'English (Singapore)'=0A= p82=0A= (S'en_SG'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Dutch (Belgium)'=0A= p83=0A= (S'nl_BE@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Spanish (Panama)'=0A= p84=0A= (S'es_PA'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Spanish (Venezuela)'=0A= p85=0A= (S'es_VE'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'English (Great Britain)'=0A= p86=0A= (S'en_GB'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Russian'=0A= p87=0A= (S'ru_RU.koi8r'=0A= S'koi8-u'=0A= S'cyr-sun16'=0A= tsS'Norwegian, Nynorsk (Norway)'=0A= p88=0A= (S'nn_NO'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'English (Zimbabwe)'=0A= p89=0A= (S'en_ZW'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Spanish (Nicaragua)'=0A= p90=0A= (S'es_NI'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'German (Luxemburg)'=0A= p91=0A= (S'de_LU@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Spanish (Colombia)'=0A= p92=0A= (S'es_CO'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Basque (Spain)'=0A= p93=0A= (S'eu_ES@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Arabic (Qatar)'=0A= p94=0A= (S'ar_QA'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Arabic (Egypt)'=0A= p95=0A= (S'ar_EG'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'French (Belgium)'=0A= p96=0A= (S'fr_BE@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'English (Ireland)'=0A= p97=0A= (S'en_IE@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Hungarian'=0A= p98=0A= (S'hu_HU'=0A= S'iso02'=0A= S'lat2-sun16'=0A= tsS'Arabic (Tunisia)'=0A= p99=0A= (S'ar_TN'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'French (Luxemburg)'=0A= p100=0A= (S'fr_LU@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Japanese'=0A= p101=0A= (S'ja_JP.eucJP'=0A= S'iso01'=0A= S'lat0-16'=0A= tsS'Swedish (Finland)'=0A= p102=0A= (S'sv_FI@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Arabic (Saudi Arabia)'=0A= p103=0A= (S'ar_SA'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Spanish (Dominican Republic)'=0A= p104=0A= (S'es_DO'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'French (Canada)'=0A= p105=0A= (S'fr_CA'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'English (Canada)'=0A= p106=0A= (S'en_CA'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'German (Germany)'=0A= p107=0A= (S'de_DE@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Slovenian (Slovenia)'=0A= p108=0A= (S'sl_SI'=0A= S'iso02'=0A= S'lat2-sun16'=0A= tsS'Spanish (Uruguay)'=0A= p109=0A= (S'es_UY'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'German (Switzerland)'=0A= p110=0A= (S'de_CH'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'English (Hong Kong)'=0A= p111=0A= (S'en_HK'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'English (Australia)'=0A= p112=0A= (S'en_AU'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Catalan (Spain)'=0A= p113=0A= (S'ca_ES@euro'=0A= S'iso15'=0A= S'lat0-sun16'=0A= tsS'Spanish (Puerto Rico)'=0A= p114=0A= (S'es_PR'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Turkish'=0A= p115=0A= (S'tr_TR'=0A= S'iso09'=0A= S'lat5-sun16'=0A= tsS'Estonian'=0A= p116=0A= (S'et_EE'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Arabic (Sudan)'=0A= p117=0A= (S'ar_SD'=0A= S'iso06'=0A= S'LatArCyrHeb-16'=0A= tsS'Icelandic'=0A= p118=0A= (S'is_IS'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'English (Botswana)'=0A= p119=0A= (S'en_BW'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tsS'Manx Gaelic (Britain)'=0A= p120=0A= (S'gv_GB'=0A= S'iso01'=0A= S'lat0-sun16'=0A= tssS'allSupportedLangs'=0A= p121=0A= (lp122=0A= g46=0A= ag79=0A= ag50=0A= ag29=0A= ag95=0A= ag25=0A= ag76=0A= ag26=0A= ag20=0A= ag23=0A= ag48=0A= ag24=0A= ag94=0A= ag103=0A= ag117=0A= ag73=0A= ag99=0A= ag59=0A= ag17=0A= ag93=0A= ag113=0A= ag53=0A= ag58=0A= ag30=0A= ag74=0A= ag52=0A= ag83=0A= ag42=0A= ag112=0A= ag119=0A= ag106=0A= ag41=0A= ag86=0A= ag111=0A= ag97=0A= ag56=0A= ag49=0A= ag82=0A= ag27=0A= ag64=0A= ag89=0A= ag116=0A= ag54=0A= ag80=0A= ag96=0A= ag105=0A= ag31=0A= ag100=0A= ag28=0A= ag55=0A= ag60=0A= ag78=0A= ag107=0A= ag91=0A= ag110=0A= ag36=0A= ag32=0A= ag63=0A= ag98=0A= ag118=0A= ag51=0A= ag75=0A= ag19=0A= ag77=0A= ag101=0A= ag33=0A= ag70=0A= ag22=0A= ag120=0A= ag47=0A= ag88=0A= ag68=0A= ag66=0A= ag45=0A= ag61=0A= ag87=0A= ag44=0A= ag43=0A= ag69=0A= ag108=0A= ag18=0A= ag57=0A= ag72=0A= ag92=0A= ag40=0A= ag104=0A= ag37=0A= ag67=0A= ag21=0A= ag39=0A= ag35=0A= ag90=0A= ag84=0A= ag62=0A= ag38=0A= ag114=0A= ag71=0A= ag65=0A= ag109=0A= ag85=0A= ag102=0A= ag81=0A= ag115=0A= ag34=0A= asS'info'=0A= p123=0A= (dp124=0A= S'SUPPORTED'=0A= p125=0A= NssS'supported'=0A= p126=0A= (lsS'default'=0A= p127=0A= NsbsS'instClass'=0A= p128=0A= (icustom=0A= InstallClass=0A= (dp129=0A= S'rootPasswordCrypted'=0A= p130=0A= I0=0A= sS'raidList'=0A= p131=0A= (lsS'nameserver'=0A= p132=0A= S''=0A= sS'x'=0A= NsS'rootPassword'=0A= p133=0A= NsS'makeBootdisk'=0A= p134=0A= I0=0A= sS'installType'=0A= p135=0A= NsS'postScript'=0A= p136=0A= NsS'earlySwapOn'=0A= p137=0A= I0=0A= sS'networkDevice'=0A= p138=0A= NsS'fstab'=0A= p139=0A= (lsS'clearText'=0A= p140=0A= NsS'lilo'=0A= p141=0A= (S'mbr'=0A= p142=0A= I1=0A= S''=0A= tsg13=0A= NsS'name'=0A= p143=0A= S''=0A= sS'postInChroot'=0A= p144=0A= I0=0A= sS'pixmap'=0A= p145=0A= S''=0A= sS'partitions'=0A= p146=0A= (lp147=0A= (S'/boot'=0A= p148=0A= (I48=0A= I-1=0A= I0=0A= t(S''=0A= I-1=0A= I0=0A= t(I0=0A= S'xfs'=0A= p149=0A= I0=0A= tNta(S'/'=0A= (I700=0A= I-1=0A= I1=0A= t(S''=0A= I-1=0A= I0=0A= t(I0=0A= g149=0A= I0=0A= tNta(S'swap'=0A= p150=0A= (I256=0A= I512=0A= I1=0A= t(S''=0A= I-1=0A= I0=0A= t(I0=0A= NI0=0A= tNtasS'clearType'=0A= p151=0A= S'wkst'=0A= p152=0A= sS'gateway'=0A= p153=0A= S''=0A= sS'mouse'=0A= p154=0A= NsS'packages'=0A= p155=0A= NsS'timezone'=0A= p156=0A= NsS'zeroMbr'=0A= p157=0A= I0=0A= sS'keyboard'=0A= p158=0A= NsS'groups'=0A= p159=0A= NsS'bootProto'=0A= p160=0A= NsS'netmask'=0A= p161=0A= S''=0A= sS'langdefault'=0A= p162=0A= NsS'skipSteps'=0A= p163=0A= (dsS'auth'=0A= p164=0A= (I1=0A= I1=0A= I0=0A= S''=0A= I0=0A= S''=0A= I0=0A= I0=0A= S''=0A= S''=0A= I0=0A= S''=0A= S''=0A= S''=0A= I0=0A= S''=0A= S''=0A= tsS'hostname'=0A= p165=0A= NsS'langsupported'=0A= p166=0A= NsS'showgroups'=0A= p167=0A= NsS'ip'=0A= p168=0A= S''=0A= sS'firewall'=0A= p169=0A= (I-1=0A= I1=0A= (lp170=0A= S''=0A= I0=0A= I0=0A= I0=0A= I0=0A= I0=0A= I0=0A= tsS'defaultRunlevel'=0A= p171=0A= NsS'desktop'=0A= p172=0A= S''=0A= sS'clearPartText'=0A= p173=0A= S'Automatic partitioning will erase any preexisting Linux installations = on your system.'=0A= p174=0A= sS'clearParts'=0A= p175=0A= I2=0A= sbsS'bdstate'=0A= p176=0A= S''=0A= sS'extraModules'=0A= p177=0A= (lp178=0A= sS'rootpassword'=0A= p179=0A= NsS'fdDevice'=0A= p180=0A= S'fd0'=0A= p181=0A= sS'installSystem'=0A= p182=0A= I1=0A= sS'comps'=0A= p183=0A= NsS'verifiedState'=0A= p184=0A= Nsg164=0A= (itodo=0A= Authentication=0A= (dp185=0A= S'useNIS'=0A= p186=0A= I0=0A= sS'nisServer'=0A= p187=0A= S''=0A= sS'useLdap'=0A= p188=0A= I0=0A= sS'krb5Kdc'=0A= p189=0A= S''=0A= sS'ldapTLS'=0A= p190=0A= S''=0A= sS'useHesiod'=0A= p191=0A= I0=0A= sS'ldapServer'=0A= p192=0A= S''=0A= sS'nisDomain'=0A= p193=0A= S''=0A= sS'krb5Realm'=0A= p194=0A= S''=0A= sS'useLdapauth'=0A= p195=0A= I0=0A= sS'hesiodRhs'=0A= p196=0A= S''=0A= sS'useShadow'=0A= p197=0A= I1=0A= sS'nisuseBroadcast'=0A= p198=0A= I0=0A= sS'useKrb5'=0A= p199=0A= I0=0A= sS'useMD5'=0A= p200=0A= I1=0A= sS'ldapBasedn'=0A= p201=0A= S''=0A= sS'krb5Admin'=0A= p202=0A= S''=0A= sS'hesiodLhs'=0A= p203=0A= S''=0A= sS'hesiodDlhs'=0A= p204=0A= S''=0A= sbsS'users'=0A= p205=0A= NsS'hdList'=0A= p206=0A= NsS'dhcpState'=0A= p207=0A= S''=0A= sS'method'=0A= p208=0A= (iimage=0A= CdromInstallMethod=0A= p209=0A= (dp210=0A= g4=0A= =0A= =0A= ------=_NextPart_000_0005_01C124BB.70DF2100-- From owner-linux-xfs@oss.sgi.com Tue Aug 14 05:53:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ECrsE08433 for linux-xfs-outgoing; Tue, 14 Aug 2001 05:53:54 -0700 Received: from mplspop5.mpls.uswest.net (mplspop5.mpls.uswest.net [204.147.80.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ECrqj08410 for ; Tue, 14 Aug 2001 05:53:52 -0700 Received: (qmail 48667 invoked from network); 14 Aug 2001 12:53:51 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop5.mpls.uswest.net with SMTP; 14 Aug 2001 12:53:51 -0000 Date: Tue, 14 Aug 2001 07:50:49 -0500 Message-ID: <3B791EA9.F4B7AF00@sgi.com> From: "Eric Sandeen" To: "walter" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: problems making a raid with sgi installer References: <000801c124aa$ae2f4be0$417f4e8c@shiga> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk walter wrote: > > I tried to install rh7.1 with the sgi installer. when trying to make a raid > the installer crashes. the error report is attached to this message. > ps: I'm using a pci-ide card: ultra100tx from promise, the driver for this > card included by sgi works fine. Hi Walter - This is a known bug, and should be fixed on the update disk available on the ftp site in the updates/ dir - can you try that? (I'm assuming this is XFS 1.0.1) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 14 05:59:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ECx9i08643 for linux-xfs-outgoing; Tue, 14 Aug 2001 05:59:09 -0700 Received: from stratus.feevale.br ([200.248.23.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ECx7j08624 for ; Tue, 14 Aug 2001 05:59:07 -0700 Received: by stratus.feevale.br with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Aug 2001 09:59:35 -0300 Message-ID: <71F2899DFFCCD311B4100050DA697A82012983E6@stratus.feevale.br> From: Marcio Schneider To: "'linux-xfs@oss.sgi.com'" Subject: Date: Tue, 14 Aug 2001 09:59:34 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk auth 557278e0 subscribe linux-xfs schneider@feevale.br From owner-linux-xfs@oss.sgi.com Tue Aug 14 06:40:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EDeLM09644 for linux-xfs-outgoing; Tue, 14 Aug 2001 06:40:21 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EDeIj09624 for ; Tue, 14 Aug 2001 06:40:18 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA05830 for ; Tue, 14 Aug 2001 06:40:11 -0700 (PDT) mail_from (eric@sgi.com) 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 PAA16648 for ; Tue, 14 Aug 2001 15:37:34 +0200 (CEST) mail_from (eric@sgi.com) 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 IAA2709722 for ; Tue, 14 Aug 2001 08:36:16 -0500 (CDT) 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 IAA23829 for ; Tue, 14 Aug 2001 08:36:16 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7EDa9t06780; Tue, 14 Aug 2001 08:36:09 -0500 Message-Id: <200108141336.f7EDa9t06780@stout.americas.sgi.com> Date: Tue, 14 Aug 2001 08:36:09 -0500 Subject: TAKE - Merge irix6.5f:irix:99901a Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Aug 14 06:35:18 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100680a linux/fs/xfs/xfs_log.c - 1.238 - Merge of irix6.5f:irix:99901a Add xfs_ioerror_alert call on I/O errors, some with injectable errors. linux/fs/xfs/xfs_rw.h - 1.59 - Merge of irix6.5f:irix:99901a Change xfs_ioerror_alert prototype. linux/fs/xfs/xfs_rw.c - 1.341 - Merge of irix6.5f:irix:99901a Add xfs_ioerror_alert calls on I/O errors Change and xfs_force_shutdown call flag from I/O Error to In-core corruption. Change _xfs_force_shutdown to report different error messages for each shutdown flag Change xfs_ioerror_alert to take a pointer to the buffer with errors. Various info is printed about the buffer Protect xfs_ioerror_alert from a mount point that is not completely initialized. linux/fs/xfs/xfs_vnodeops.c - 1.507 linux/fs/xfs/xfs_log_recover.c - 1.208 linux/fs/xfs/xfs_mount.c - 1.258 linux/fs/xfs/xfs_trans.c - 1.121 - Merge of irix6.5f:irix:99901a Add xfs_ioerror_alert calls on I/O errors linux/fs/xfs/xfs_error.h - 1.22 - Merge of irix6.5f:irix:99901a Add new error tags for injecting I/O errors linux/fs/xfs/xfs_bmap.c - 1.270 linux/fs/xfs/xfs_trans_buf.c - 1.95 - Merge of irix6.5f:irix:99901a Add xfs_ioerror_alert calls on I/O errors From owner-linux-xfs@oss.sgi.com Tue Aug 14 06:51:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EDpIX09974 for linux-xfs-outgoing; Tue, 14 Aug 2001 06:51:18 -0700 Received: from mail.levigo.de (mail.levigo.de [193.197.156.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EDpGj09955 for ; Tue, 14 Aug 2001 06:51:16 -0700 Received: from levigo.de (zoidberg.cogito.de [193.197.156.88]) by mail.levigo.de (Postfix) with ESMTP id 0DECF7EA5 for ; Tue, 14 Aug 2001 15:49:44 +0200 (CEST) Message-ID: <3B792CD2.859A24EF@levigo.de> Date: Tue, 14 Aug 2001 15:51:14 +0200 From: Klaus Rein Organization: levigo systems gmbh X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: strange nfs... References: <200108131807.f7DI7Cr23106@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: > If you unmount the filesystem and then remount it the files should > report using the correct amount of space again. Yes, that worked. Considering the time it took to unmount and mount I think the update ist done during the unmount, right? What happens after a system crash? Klaus. From owner-linux-xfs@oss.sgi.com Tue Aug 14 06:53:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EDrl710112 for linux-xfs-outgoing; Tue, 14 Aug 2001 06:53:47 -0700 Received: from nexus.tronicplanet.de (nexus.sim.tronicplanet.de [217.74.1.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EDrij10091 for ; Tue, 14 Aug 2001 06:53:45 -0700 Received: from tronicplanet.de (igate-tp.tronicplanet.de [217.74.1.58]) by nexus.tronicplanet.de (8.11.0/8.11.0/Linux 8.11.0) with ESMTP id f7EDrgW22943 for ; Tue, 14 Aug 2001 15:53:42 +0200 X-Authentication-Warning: nexus.tronicplanet.de: Host igate-tp.tronicplanet.de [217.74.1.58] claimed to be tronicplanet.de Message-ID: <3B792D65.AEE5C0CE@tronicplanet.de> Date: Tue, 14 Aug 2001 15:53:41 +0200 From: Knollmueller Stefan Organization: Tronic Planet Online Datendienst GmbH X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-xfs i586) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs and lvm snapshot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello, we got the problem that our xfs system on a logical volume that is on a software-raid 5 partition hangs during a snapshot. we used kernel 2.4.7-xfs and 2.4.8-xfs and always the same error occured. fixing the filesystem with xfs_repair is no problem after rebooting but does anybody know why lvmsnapshot hangs the whole system? Stefan From owner-linux-xfs@oss.sgi.com Tue Aug 14 07:17:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EEHI210709 for linux-xfs-outgoing; Tue, 14 Aug 2001 07:17:18 -0700 Received: from mplspop5.mpls.uswest.net (mplspop5.mpls.uswest.net [204.147.80.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EEHGj10690 for ; Tue, 14 Aug 2001 07:17:16 -0700 Received: (qmail 56387 invoked from network); 14 Aug 2001 14:17:14 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop5.mpls.uswest.net with SMTP; 14 Aug 2001 14:17:14 -0000 Date: Tue, 14 Aug 2001 09:14:13 -0500 Message-ID: <3B793235.41FC4FF5@sgi.com> From: "Eric Sandeen" To: "Nathan Scott" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: New tarball error References: <000001c1242c$b968d220$650aa8c0@vauntmure.com> <3B7839A3.69A052D2@sgi.com> <20010814095037.I295821@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott wrote: > sorry - my bad - should be workin' now. Thanks for the fix, Nathan - updated packages are available on oss now. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 14 07:22:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EEMml10899 for linux-xfs-outgoing; Tue, 14 Aug 2001 07:22:48 -0700 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 f7EEMkj10879 for ; Tue, 14 Aug 2001 07:22:46 -0700 Received: from umbi.umd.edu (mystery.carb.nist.gov [129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GI2ANO00.CSP; Tue, 14 Aug 2001 10:23:48 -0400 Message-ID: <3B793420.33D5AA42@umbi.umd.edu> Date: Tue, 14 Aug 2001 10:22:24 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: walter , linux-xfs@oss.sgi.com Subject: Re: problems making a raid with sgi installer References: <000801c124aa$ae2f4be0$417f4e8c@shiga> <3B791EA9.F4B7AF00@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, Walter, I had the same problem. Setting up RAID with the graphical installer works if you boot with "linux updates" and use the updates disk. However, I first tried "text updates" (I didn't have a mouse) but setting up RAID was not an option in the text installer. I had to borrow a mouse and use the graphical installer, then it worked. Eric Sandeen wrote: > > walter wrote: > > > > I tried to install rh7.1 with the sgi installer. when trying to make a raid > > the installer crashes. the error report is attached to this message. > > ps: I'm using a pci-ide card: ultra100tx from promise, the driver for this > > card included by sgi works fine. > > Hi Walter - > > This is a known bug, and should be fixed on the update disk available on > the ftp site in the updates/ dir - can you try that? > > (I'm assuming this is XFS 1.0.1) > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- "Jonathan F. Dill" (dill@umbi.umd.edu) From owner-linux-xfs@oss.sgi.com Tue Aug 14 07:33:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EEXBU11222 for linux-xfs-outgoing; Tue, 14 Aug 2001 07:33:11 -0700 Received: from mplspop3.mpls.uswest.net (mplspop3.mpls.uswest.net [204.147.80.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EEX9j11203 for ; Tue, 14 Aug 2001 07:33:09 -0700 Received: (qmail 6210 invoked from network); 14 Aug 2001 14:33:08 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop3.mpls.uswest.net with SMTP; 14 Aug 2001 14:33:08 -0000 Date: Tue, 14 Aug 2001 09:30:06 -0500 Message-ID: <3B7935EE.8346003C@sgi.com> From: "Eric Sandeen" To: "Klaus Rein" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: strange nfs... References: <200108131807.f7DI7Cr23106@jen.americas.sgi.com> <3B792CD2.859A24EF@levigo.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Klaus Rein wrote: > > Steve Lord wrote: > > > If you unmount the filesystem and then remount it the files should > > report using the correct amount of space again. > > Yes, that worked. Considering the time it took to unmount and mount > I think the update ist done during the unmount, right? Yes: /* * This is called from the XFS unmount code to purge all entries for the * given mount from the cache. It uses the refcache busy counter to * make sure that new entries are not added to the cache as we purge them. */ void xfs_refcache_purge_mp( > What happens after a system crash? Good question... Steve? :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 14 08:42:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EFguf12531 for linux-xfs-outgoing; Tue, 14 Aug 2001 08:42:56 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EFgsj12512 for ; Tue, 14 Aug 2001 08:42:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA08204 for ; Tue, 14 Aug 2001 08:40:55 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2683842 for ; Tue, 14 Aug 2001 10:41:38 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA12962 for ; Tue, 14 Aug 2001 10:41:34 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f7EFe8L00971; Tue, 14 Aug 2001 10:40:08 -0500 Message-Id: <200108141540.f7EFe8L00971@jen.americas.sgi.com> Date: Tue, 14 Aug 2001 10:40:08 -0500 Subject: TAKE - a vm memory reclaim optimization Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Based on a comment from Marcello we can call into writepage from page_launder in a few more cases than we used to. Should help some with memory pressure. Date: Tue Aug 14 08:40:37 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100689a linux/mm/vmscan.c - 1.69 - Call writepage on delalloc pages in more cases from page_launder From owner-linux-xfs@oss.sgi.com Tue Aug 14 09:07:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EG7ur13293 for linux-xfs-outgoing; Tue, 14 Aug 2001 09:07:56 -0700 Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EG7sj13274 for ; Tue, 14 Aug 2001 09:07:54 -0700 Received: from lucas.loria (strasbourg-2-a7-50-58.dial.proxad.net [212.27.50.58]) by postfix1-2.free.fr (Postfix) with ESMTP id 745CDAB1CB for ; Tue, 14 Aug 2001 18:07:51 +0200 (CEST) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id 1B174A5D2 for ; Tue, 14 Aug 2001 18:07:38 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id 046E55F8B6; Tue, 14 Aug 2001 18:07:36 +0200 (CEST) To: Subject: Re: New tarball error References: <000001c1242c$b968d220$650aa8c0@vauntmure.com> X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E In-Reply-To: <000001c1242c$b968d220$650aa8c0@vauntmure.com> From: Vincent Bernat Date: 14 Aug 2001 18:07:36 +0200 Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) 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 OoO En ce début de soirée du lundi 13 août 2001, vers 21:18, Adam Pendleton disait: > One of the new tarballs generated today: [...] I have just compiled latest tarballs and found some glitches (I have never compiled earlier tarballs, so it may be "normal") : - in my system, libtool is /usr/local/libexec/rep/i686-pc-linux-gnu/libtool and not /usr/bin/libtool. I have never seen any program who have complained about this. - compiling xfsprogs (and I suppose others) with --enable-shared=no produces dynamic executables (just like without this option) and make install-dev fails because it tries to install libxfs.lai instead of libxfs.la. After correcting the Makefile, (replacing lai by la for the static target), it goes fine however, configure of xfsdump (I haven't tried with others) complains that it doesn't find libxfs. BTW, I don't understand what dmapi is. In what it is useful ? Do I need it for xfsdump ? From owner-linux-xfs@oss.sgi.com Tue Aug 14 09:42:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EGgHm14290 for linux-xfs-outgoing; Tue, 14 Aug 2001 09:42:17 -0700 Received: from twain.franken.de (mail@dsl-213-023-054-056.arcor-ip.net [213.23.54.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EGgCj14208 for ; Tue, 14 Aug 2001 09:42:12 -0700 Received: from smoki by twain.franken.de with local (Exim 3.22 #1 (Debian)) id 15WhFL-0000WF-00; Tue, 14 Aug 2001 18:40:51 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Smoki To: Linux XFS Mailing List Subject: Fwd: Re: SYSCALLS for Posix-ACL's in 2.4.5 and later Date: Tue, 14 Aug 2001 18:40:50 +0200 X-Mailer: KMail [version 1.2] Cc: "Martin Schwidefsky" MIME-Version: 1.0 Message-Id: <01081418405000.01632@twain> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello again, i have asked the IBM S/390 maintainer to reserve three SYSCALLS for s390 in the kernel, and have got 222, 223 and 224 as Syscall for 31-bit (arch/s390/kernel/entry.S) and 64-bit (arch/s390x/kernel/entry.S). The diff now look like this (for arch/s390/kernel/entry.S): diff -u entry.S.org entry.S --- entry.S.org Tue Aug 14 18:10:16 2001 +++ entry.S Tue Aug 14 18:19:47 2001 @@ -574,9 +574,9 @@ .long sys_madvise .long sys_getdents64 /* 220 */ .long sys_fcntl64 - .long sys_ni_syscall /* 222 - reserved for posix_acl */ - .long sys_ni_syscall /* 223 - reserved for posix_acl */ - .long sys_ni_syscall /* 224 - reserved for posix_acl */ + .long sys_attrctl /* 222 - reserved for posix_acl */ + .long sys_acl_get /* 223 - reserved for posix_acl */ + .long sys_acl_set /* 224 - reserved for posix_acl */ .rept 255-224 .long sys_ni_syscall .endr The ACL on my System work with this changes, what diff have to used for 64-bit tree i am not sure (but propably similar...), i dont have access to a 64bit machine :-/ In the File "acl/acl.h" have following #defines to be added: +#define HAVE_ACL_SYSCALL 1 +# ifndef SYS__acl_get +# define SYS__acl_get 223 +# endif +# ifndef SYS__acl_set +# define SYS__acl_set 224 +# endif I hope with this changes will help XFS get a step further to run on s/390 enviroment. I will work on, to get xfs run more stable on my system, becouse i have some strange problems already, hope i will find and solve them. Sincerly, Christian Mueller ---------- Weitergeleitete Nachricht ---------- Subject: Re: SYSCALLS for Posix-ACL's in 2.4.5 and later Date: Tue, 14 Aug 2001 09:57:28 +0200 From: "Martin Schwidefsky" To: "Christian Mueller" Hallo Herr Mueller, die Leute von der XFS Mailing Liste haben Sie in die richtige Richtung verwiesen. Ich habe gerade die drei Systemaufrufe 222, 223 und 224 für ACL reserviert. Die zwei relevanten Stellen sehen jetzt so aus: Index: entry.S =================================================================== RCS file: /home/cvs/linux-2.3/arch/s390/kernel/entry.S,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- entry.S 2001/07/27 11:36:47 1.41 +++ entry.S 2001/08/14 07:56:57 1.42 @@ -559,7 +559,10 @@ .long sys_madvise .long sys_getdents64 /* 220 */ .long sys_fcntl64 - .rept 255-221 + .long sys_ni_syscall /* 222 - reserved for posix_acl */ + .long sys_ni_syscall /* 223 - reserved for posix_acl */ + .long sys_ni_syscall /* 224 - reserved for posix_acl */ + .rept 255-224 .long sys_ni_syscall .endr Index: entry.S =================================================================== RCS file: /home/cvs/linux-2.3/arch/s390x/kernel/entry.S,v retrieving revision 1.53 retrieving revision 1.54 diff -u -r1.53 -r1.54 --- entry.S 2001/07/26 15:15:20 1.53 +++ entry.S 2001/08/14 07:57:01 1.54 @@ -594,7 +594,10 @@ .long SYSCALL(sys_madvise,sys32_madvise_wrapper) .long SYSCALL(sys_getdents64,sys32_getdents64_wrapper)/* 220 */ .long SYSCALL(sys_ni_syscall,sys32_fcntl64_wrapper) - .rept 255-221 + .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 222 - reserved for posix_acl */ + .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 223 - reserved for posix_acl */ + .long SYSCALL/sys_ni_syscall,sys_ni_syscall) /* 224 - reserved for posix_acl */ + .rept 255-224 .long SYSCALL(sys_ni_syscall,sys_ni_syscall) .endr Brauchen Sie einen ähnlichen Patch für 2.2 ? blue skies, Martin Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247 E-Mail: schwidefsky@de.ibm.com "Christian Mueller" @twain.franken.de> on 13.08.2001 21:51:55 Please respond to "Christian Mueller" Sent by: Smoki To: Martin Schwidefsky/Germany/IBM@IBMDE cc: Subject: SYSCALLS for Posix-ACL's in 2.4.5 and later Hello Mr. Schwidefsky, the people from the Mailing-List for the XFS development have told me, i should ask the maintainer of s/390 to ask for 3 syscalls, to get support posix_acl support for s/390 enviroment. I hope you are the right person. : -) To make it short, the support of posix acl needs 3 syscalls, i have used the following in my enviroment ("arch/s390/kernel/entry.S"): .long sys_getdents64 /* 220 */ .long sys_fcntl64 + .long sys_attrctl /* 222 - Attrctrl */ + .long sys_acl_get /* 223 - ACL Syscall for get */ + .long sys_acl_set /* 224 - ACL Syscall for set */ - .rept 255-221 .rept 255-224 .long sys_ni_syscall .endr Could i reserve this 3 numbers for s/390 or can you give me some other numbers for syscall, to get posix_acl offical supported by linux/390. Posix ACL works fine on my s/390, if you have any question, tell me (may be in german, too) :-) By the way, do you know, if there is a someone working on JFS to use posix ACL's too? Good bye, and i hope i will hear from u soon, what syscall-numbers used for the posix-acl :) Christian Mueller ------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Aug 14 12:07:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EJ7FK17656 for linux-xfs-outgoing; Tue, 14 Aug 2001 12:07:15 -0700 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 f7EJ7Dj17637 for ; Tue, 14 Aug 2001 12:07:13 -0700 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 f7EJBvS18639 for ; Tue, 14 Aug 2001 12:11:57 -0700 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 OAA2706144; Tue, 14 Aug 2001 14:05:51 -0500 (CDT) Received: from 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 OAA40173; Tue, 14 Aug 2001 14:05:50 -0500 (CDT) Message-ID: <3B797686.D613E7B6@sgi.com> Date: Tue, 14 Aug 2001 14:05:42 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Knollmueller Stefan CC: linux-xfs@oss.sgi.com Subject: Re: xfs and lvm snapshot References: <3B792D65.AEE5C0CE@tronicplanet.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Knollmueller Stefan wrote: > > hello, > > we got the problem that our xfs system on a logical volume that is on a > software-raid 5 partition hangs during a snapshot. > we used kernel 2.4.7-xfs and 2.4.8-xfs and always the same error > occured. fixing the filesystem with xfs_repair is no problem after > rebooting but does anybody know why lvmsnapshot hangs the whole system? Can you use kdb to get a backtrace and see what's going on when the system hangs? -Eric From owner-linux-xfs@oss.sgi.com Tue Aug 14 12:14:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EJEOb17925 for linux-xfs-outgoing; Tue, 14 Aug 2001 12:14:24 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EJEHj17903 for ; Tue, 14 Aug 2001 12:14:17 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A8B7C1E4E7 for ; Tue, 14 Aug 2001 21:14:08 +0200 (MEST) Date: Tue, 14 Aug 2001 21:14:07 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: [PATCH] XFS OOM hardening Message-ID: <20010814211407.A5410@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I ran into a few problems with XFS running out of memory and crashing and did a few changes to fix the most obvious problems. The only tricky bit is the ENOMEM return in xfs_trans_read_buf(); there may be some callers that handle NULL correctly but most seem not to when the error return is zero. The others are straight forward. I replace the panics in kmem.c with random retries with printks to give it some chance to recover. Sometimes it deadlocks unfortunately (probably because too many locks are held), but in other cases it recovers and that's better than a panic. I also fixed oom checking in some other easy cases. This patch also fixes an unrelated bug -- pagebuf sometimes sets pb_error to negative errno when the rest of XFS expects positive here. -Andi --- linux-xfs/fs/pagebuf/page_buf.c-XFSMEM Tue Aug 14 01:12:43 2001 +++ linux-xfs/fs/pagebuf/page_buf.c Tue Aug 14 20:43:57 2001 @@ -1055,6 +1055,8 @@ int pagebuf_geterror( /* return buffer error */ page_buf_t * pb) /* buffer */ { + if (!pb) + return ENOMEM; return (pb->pb_error); } @@ -1200,7 +1202,7 @@ page = bh->b_page; if (!test_bit(BH_Uptodate, &bh->b_state)) { set_bit(PG_error, &page->flags); - pb->pb_error = -EIO; + pb->pb_error = EIO; } unlock_buffer(bh); @@ -1221,7 +1223,7 @@ page = bh->b_page; if (!test_bit(BH_Uptodate, &bh->b_state)) { set_bit(PG_error, &page->flags); - pb->pb_error = -EIO; + pb->pb_error = EIO; } unlock_buffer(bh); @@ -1244,7 +1246,7 @@ page = bh->b_page; if (!test_bit(BH_Uptodate, &bh->b_state)) { set_bit(PG_error, &page->flags); - pb->pb_error = -EIO; + pb->pb_error = EIO; } unlock_buffer(bh); --- linux-xfs/fs/xfs/linux/xfs_vfs.c-XFSMEM Tue Aug 14 01:12:44 2001 +++ linux-xfs/fs/xfs/linux/xfs_vfs.c Tue Aug 14 04:51:07 2001 @@ -52,6 +52,8 @@ vfs_t *vfsp; vfsp = kmalloc(sizeof(vfs_t), GFP_KERNEL); + if (!vfsp) + return NULL; memset(vfsp, 0, sizeof(vfs_t)); ASSERT(vfsp); VFS_INIT(vfsp); --- linux-xfs/fs/xfs/linux/xfs_super.c-XFSMEM Tue Aug 14 01:12:44 2001 +++ linux-xfs/fs/xfs/linux/xfs_super.c Tue Aug 14 02:06:09 2001 @@ -357,6 +357,8 @@ /* Set up the vfs_t structure */ vfsp = vfs_allocate(); + if (!vfsp) + return NULL; if (sb->s_flags & MS_RDONLY) vfsp->vfs_flag |= VFS_RDONLY; @@ -364,6 +366,11 @@ /* Setup up the cvp structure */ cip = (struct inode *)kmem_alloc(sizeof(struct inode),0); + if (!cip) { + vfs_deallocate(vfsp); + return NULL; + } + bzero(cip, sizeof(*cip)); atomic_set(&cip->i_count, 1); --- linux-xfs/fs/xfs/xfs_buf.h-XFSMEM Tue Aug 14 01:44:21 2001 +++ linux-xfs/fs/xfs/xfs_buf.h Tue Aug 14 01:50:01 2001 @@ -238,6 +238,9 @@ static inline void xfs_buf_relse(page_buf_t *bp) { + if (!bp) + return; + if (bp->pb_relse == NULL) pagebuf_unlock(bp); --- linux-xfs/fs/xfs/xfs_trans_buf.c-XFSMEM Tue Aug 14 01:12:46 2001 +++ linux-xfs/fs/xfs/xfs_trans_buf.c Tue Aug 14 20:28:33 2001 @@ -295,6 +295,9 @@ */ if (tp == NULL) { bp = xfs_buf_read_flags(target, blkno, len, flags); + if (!bp) + return XFS_ERROR(ENOMEM); + if ((bp != NULL) && (XFS_BUF_GETERROR(bp) != 0)) { xfs_ioerror_alert("xfs_trans_read_buf", mp, target->dev, blkno); --- linux-xfs/fs/xfs_support/kmem.c-XFSMEM Tue Aug 14 01:12:46 2001 +++ linux-xfs/fs/xfs_support/kmem.c Tue Aug 14 01:51:14 2001 @@ -47,6 +47,15 @@ #define GFP_NOFS GFP_BUFFER #endif +/* random generator stolen from net/core/utils.c. */ +static unsigned long xfs_rand_seed = 152L; + +unsigned long xfs_random(void) +{ + xfs_rand_seed=xfs_rand_seed*69069L+1; + return xfs_rand_seed^jiffies; +} + static __inline__ unsigned int flag_convert(int flags) { if (flags & KM_NOSLEEP) return GFP_ATOMIC; @@ -79,8 +88,13 @@ rval = kmalloc(size, flag_convert(flags)); } - if (rval || (flags & KM_NOSLEEP)) - return rval; + if (!rval) { + if ((flags & KM_NOSLEEP) == 0) { + printk(KERN_ERR "xfs [%d]: failed to allocate %d bytes.\n", current->pid, size); + return NULL; + } + } else + return rval; /* * KM_SLEEP callers don't expect a failure @@ -93,8 +107,16 @@ } rval = __vmalloc(size, flag_convert(flags), PAGE_KERNEL); - if (!rval && (flags & KM_SLEEP)) - panic("kmem_alloc: NULL memory on KM_SLEEP request!"); + if (!rval) { + if (flags & KM_SLEEP) { + printk(KERN_ERR "xfs [%d]: failed to allocate %d bytes. waiting and retry.\n", + current->pid, size); + delay(5 + xfs_random()%10); + shrink = DEF_PRIORITY; + goto repeat; + } + printk(KERN_ERR "xfs [%d]: failed to allocate %d bytes.\n", current->pid, size); + } return rval; } @@ -157,8 +179,11 @@ repeat: ptr = kmem_cache_alloc(zone, flag_convert(flags)); - if (ptr || (flags & KM_NOSLEEP)) + if (ptr || (flags & KM_NOSLEEP)) { + if (!ptr) + printk(KERN_ERR "xfs [%d]: failed to allocate from zone.\n", current->pid); return ptr; + } /* * KM_SLEEP callers don't expect a failure @@ -170,8 +195,13 @@ goto repeat; } - if (flags & KM_SLEEP) - panic("kmem_zone_alloc: NULL memory on KM_SLEEP request!"); + if (flags & KM_SLEEP) { + printk(KERN_ERR "xfs [%d]: failed to allocate from zone. waiting and retry.\n", + current->pid); + delay(5 + xfs_random()%10); + shrink = DEF_PRIORITY; + goto repeat; + } return NULL; } @@ -185,21 +215,29 @@ repeat: ptr = kmem_cache_zalloc(zone, flag_convert(flags)); - if (ptr || (flags & KM_NOSLEEP)) + if (ptr || (flags & KM_NOSLEEP)) { + if (!ptr) + printk(KERN_ERR "xfs [%d]: failed to allocate from zone.\n", current->pid); return ptr; + } /* * KM_SLEEP callers don't expect a failure */ if (shrink) { kmem_shake(); - + shrink--; goto repeat; } - if (flags & KM_SLEEP) - panic("kmem_zone_zalloc: NULL memory on KM_SLEEP request!"); + if (flags & KM_SLEEP) { + printk(KERN_ERR "xfs [%d]: failed to allocate from zone. waiting and retry.\n", + current->pid); + delay(5 + xfs_random()%10); + shrink = DEF_PRIORITY; + goto repeat; + } return NULL; } From owner-linux-xfs@oss.sgi.com Tue Aug 14 12:15:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EJFjI18081 for linux-xfs-outgoing; Tue, 14 Aug 2001 12:15:45 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EJFgj18061 for ; Tue, 14 Aug 2001 12:15:43 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 5679B1E4E0 for ; Tue, 14 Aug 2001 21:15:37 +0200 (MEST) Date: Tue, 14 Aug 2001 21:15:36 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: Some XFS problems Message-ID: <20010814211536.A5490@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Here are some things I stumbled over during XFS stress testing. I don't have time to fix them, they're not that critical (except for the last one perhaps which is a admittedly bit vague); but I thought I would just note them. - When the log replay fails not all objects in the XFS zones are freed. This causes one of the zones not to be freed on module unload afterwards, and when XFS module loads again stumbles over an BUG() in slab.c that checks for duplicate zones. - pagebuf layer will surely not run on sparc32; it passes the _irqsave interrupt mask between functions which causes quick crashes there because on that architecture the interrupt mask includes the register window pointer and it can only be restored in the same function. (e.g. _pagebuf_free_lockable_buffer violates that) [I personally do not care about sparc32, I just thought I would note it. It is probably fairly easy to fix if anyone on the list is motivated] - When a filesystem shutdown occurs there seem to be some problems in the error cleanup paths. For example page locks seem to get leaked. In one case I had a whole bunch of processes stuck in lock_page and wait_on_page after a shutdown. - I had a buffer leak for some time in my version of XFS that eventually caused it to run out of memory because pagecache pages were not freed (no other corruption though) When that happened under heavy fsstress load I usually pressed reset because user space was dead. I think the page leak itself didn't cause any corruption. In several cases I got a corrupted file system afterwards that needed an xfs_repair; otherwise even after a remount with log replay it would shutdown the file system (from various places) while accessing fsstress test directory. In one case I got an corrupted log with garbage in it that caused log replay to fail. -Andi From owner-linux-xfs@oss.sgi.com Tue Aug 14 13:10:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EKAn319476 for linux-xfs-outgoing; Tue, 14 Aug 2001 13:10:49 -0700 Received: from cueva.cse.ucsc.edu (cueva.cse.ucsc.edu [128.114.49.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EKAmj19456 for ; Tue, 14 Aug 2001 13:10:48 -0700 Received: from localhost (jgarcia@localhost) by cueva.cse.ucsc.edu (8.11.2/8.9.1) with ESMTP id f7EKAkt16051 for ; Tue, 14 Aug 2001 13:10:46 -0700 X-Authentication-Warning: cueva.cse.ucsc.edu: jgarcia owned process doing -bs Date: Tue, 14 Aug 2001 13:10:46 -0700 (PDT) From: Jorge Garcia To: Subject: DMA problems with XFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm testing out an XFS install on one of our systems here. The system: ASUS CUR-DLS motherboard Dual 866 MHz Pentium III 4 Gb Memory 61.5 Gb IBM Deskstar ATA/IDE Disk When I install vanilla RedHat 7.1, I get no problems. But, when I install from the RH7.1-SGI-XFS-1.0.1.iso CDs, I get some strange DMA messages regarding hda: Start mounting filesystem: ide0(3,5) hda: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } hda: drive not ready for command Ending clean XFS mount for filesystem: ide0(3,5) The system comes up correctly and runs fine, but every once in a while (when there's lots of disk activity) it will complain once again about timeouts waiting for DMA, and sometimes other messages that say "DMA disabled". Once again, no other problems that I can see, but the error messages just get me nervous. Is there a reason for these messages? I don't get them when running vanilla RedHat 7.1, so they seem to be a product of the XFS installation... Any help would be very appreciated. Thanks, Jorge From owner-linux-xfs@oss.sgi.com Tue Aug 14 14:03:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EL3jL20800 for linux-xfs-outgoing; Tue, 14 Aug 2001 14:03:45 -0700 Received: from acmez.gatech.edu (IDENT:root@acmez.gatech.edu [130.207.165.24]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EL3gj20781 for ; Tue, 14 Aug 2001 14:03:42 -0700 Received: from [130.207.197.237] ([130.207.197.237]) by acmez.gatech.edu (8.9.2/8.9.2) with ESMTP id RAA18791; Tue, 14 Aug 2001 17:03:40 -0400 (EDT) Subject: Re: DMA problems with XFS From: Rob Myers To: Jorge Garcia Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12.99 (Preview Release) Date: 14 Aug 2001 17:06:42 -0400 Message-Id: <997823202.32695.44.camel@ransom> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk jorge- this is a known issue with the serverworks chipset. check this thread on l-k for details. http://marc.theaimsgroup.com/?t=99602499100003&w=2&r=1 this thread also brings up some questions about how this system performs with 4gb of memory. how does it perform for you? rob. On 14 Aug 2001 13:10:46 -0700, Jorge Garcia wrote: > I'm testing out an XFS install on one of our systems here. The system: > > ASUS CUR-DLS motherboard > Dual 866 MHz Pentium III > 4 Gb Memory > 61.5 Gb IBM Deskstar ATA/IDE Disk > > When I install vanilla RedHat 7.1, I get no problems. But, when I install > from the RH7.1-SGI-XFS-1.0.1.iso CDs, I get some strange DMA messages > regarding hda: > > Start mounting filesystem: ide0(3,5) > hda: timeout waiting for DMA > ide_dmaproc: chipset supported ide_dma_timeout func only: 14 > hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } > hda: drive not ready for command > Ending clean XFS mount for filesystem: ide0(3,5) > > The system comes up correctly and runs fine, but every once in a while > (when there's lots of disk activity) it will complain once again about > timeouts waiting for DMA, and sometimes other messages that say "DMA > disabled". Once again, no other problems that I can see, but the error > messages just get me nervous. Is there a reason for these messages? > I don't get them when running vanilla RedHat 7.1, so they seem to be a > product of the XFS installation... > > Any help would be very appreciated. > > Thanks, > > Jorge > From owner-linux-xfs@oss.sgi.com Tue Aug 14 15:11:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EMBha22778 for linux-xfs-outgoing; Tue, 14 Aug 2001 15:11:43 -0700 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 f7EMBfj22758 for ; Tue, 14 Aug 2001 15:11:41 -0700 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 f7EMHSW02918 for ; Tue, 14 Aug 2001 15:17:28 -0700 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 RAA2712653 for ; Tue, 14 Aug 2001 17:10:20 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA49659 for ; Tue, 14 Aug 2001 17:10:20 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f7EM8pC15524; Tue, 14 Aug 2001 17:08:51 -0500 Message-Id: <200108142208.f7EM8pC15524@jen.americas.sgi.com> Date: Tue, 14 Aug 2001 17:08:51 -0500 Subject: TAKE - fix ABBA deadlock under heavy load Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This may be what Andrew Tridgell hit, I hit it running dbench 140 and deadlocked between kswapd reclaiming inodes and kupdated flushing inodes. 160 stack traces later...... Date: Tue Aug 14 14:58:24 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100765a linux/fs/xfs/xfs_vnodeops.c - 1.508 - Remove ABBA deadlock between ilock and ihash lock, the ihash lock in xfs_finish_reclaim is a hang over from an earlier implementation on Linux, we do not need it anymore, and at some point this deadlock got introduced. From owner-linux-xfs@oss.sgi.com Tue Aug 14 15:24:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EMOVn23268 for linux-xfs-outgoing; Tue, 14 Aug 2001 15:24:31 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EMOOj23249 for ; Tue, 14 Aug 2001 15:24:24 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA05352 for ; Tue, 14 Aug 2001 15:24:24 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2715457; Tue, 14 Aug 2001 17:23:07 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA97343; Tue, 14 Aug 2001 17:23:07 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7EMLcQ15900; Tue, 14 Aug 2001 17:21:38 -0500 Message-Id: <200108142221.f7EMLcQ15900@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] XFS OOM hardening In-Reply-To: Message from Andi Kleen of "Tue, 14 Aug 2001 21:14:07 +0200." <20010814211407.A5410@gruyere.muc.suse.de> Date: Tue, 14 Aug 2001 17:21:38 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Andi, I know you have sent most of this before, things are a just a 'leetle bit' hectic around here right now, so things are taking longer than they otherwise would. The problem with the code which does some xfs memory allocation failure detection is that you can never get to all of them, this is why I have never checked in the stuff about seeing a NULL and doing an error return. There are also places in xfs where failure is not an option - once a transaction has dirtied metadata there is no turning back. So really the only option which will fly long term is making sure memory allocations do not return failure when they get back up to xfs proper. I do have some other ideas it is just a matter of finding the time. Steve > > I ran into a few problems with XFS running out of memory and crashing > and did a few changes to fix the most obvious problems. The only tricky > bit is the ENOMEM return in xfs_trans_read_buf(); there may be some > callers that handle NULL correctly but most seem not to when the error > return is zero. The others are straight forward. I replace the panics > in kmem.c with random retries with printks to give it some chance to > recover. Sometimes it deadlocks unfortunately (probably because too > many locks are held), but in other cases it recovers and that's better > than a panic. I also fixed oom checking in some other easy cases. > > This patch also fixes an unrelated bug -- pagebuf sometimes sets > pb_error to negative errno when the rest of XFS expects positive here. > > -Andi > > > --- linux-xfs/fs/pagebuf/page_buf.c-XFSMEM Tue Aug 14 01:12:43 2001 > +++ linux-xfs/fs/pagebuf/page_buf.c Tue Aug 14 20:43:57 2001 > @@ -1055,6 +1055,8 @@ > int pagebuf_geterror( /* return buffer error */ > page_buf_t * pb) /* buffer */ > { > + if (!pb) > + return ENOMEM; > return (pb->pb_error); > } > > @@ -1200,7 +1202,7 @@ > page = bh->b_page; > if (!test_bit(BH_Uptodate, &bh->b_state)) { > set_bit(PG_error, &page->flags); > - pb->pb_error = -EIO; > + pb->pb_error = EIO; > } > > unlock_buffer(bh); > @@ -1221,7 +1223,7 @@ > page = bh->b_page; > if (!test_bit(BH_Uptodate, &bh->b_state)) { > set_bit(PG_error, &page->flags); > - pb->pb_error = -EIO; > + pb->pb_error = EIO; > } > > unlock_buffer(bh); > @@ -1244,7 +1246,7 @@ > page = bh->b_page; > if (!test_bit(BH_Uptodate, &bh->b_state)) { > set_bit(PG_error, &page->flags); > - pb->pb_error = -EIO; > + pb->pb_error = EIO; > } > > unlock_buffer(bh); > --- linux-xfs/fs/xfs/linux/xfs_vfs.c-XFSMEM Tue Aug 14 01:12:44 2001 > +++ linux-xfs/fs/xfs/linux/xfs_vfs.c Tue Aug 14 04:51:07 2001 > @@ -52,6 +52,8 @@ > vfs_t *vfsp; > > vfsp = kmalloc(sizeof(vfs_t), GFP_KERNEL); > + if (!vfsp) > + return NULL; > memset(vfsp, 0, sizeof(vfs_t)); > ASSERT(vfsp); > VFS_INIT(vfsp); > --- linux-xfs/fs/xfs/linux/xfs_super.c-XFSMEM Tue Aug 14 01:12:44 2001 > +++ linux-xfs/fs/xfs/linux/xfs_super.c Tue Aug 14 02:06:09 2001 > @@ -357,6 +357,8 @@ > /* Set up the vfs_t structure */ > > vfsp = vfs_allocate(); > + if (!vfsp) > + return NULL; > > if (sb->s_flags & MS_RDONLY) > vfsp->vfs_flag |= VFS_RDONLY; > @@ -364,6 +366,11 @@ > /* Setup up the cvp structure */ > > cip = (struct inode *)kmem_alloc(sizeof(struct inode),0); > + if (!cip) { > + vfs_deallocate(vfsp); > + return NULL; > + } > + > bzero(cip, sizeof(*cip)); > > atomic_set(&cip->i_count, 1); > --- linux-xfs/fs/xfs/xfs_buf.h-XFSMEM Tue Aug 14 01:44:21 2001 > +++ linux-xfs/fs/xfs/xfs_buf.h Tue Aug 14 01:50:01 2001 > @@ -238,6 +238,9 @@ > > static inline void xfs_buf_relse(page_buf_t *bp) > { > + if (!bp) > + return; > + > if (bp->pb_relse == NULL) > pagebuf_unlock(bp); > > --- linux-xfs/fs/xfs/xfs_trans_buf.c-XFSMEM Tue Aug 14 01:12:46 2001 > +++ linux-xfs/fs/xfs/xfs_trans_buf.c Tue Aug 14 20:28:33 2001 > @@ -295,6 +295,9 @@ > */ > if (tp == NULL) { > bp = xfs_buf_read_flags(target, blkno, len, flags); > + if (!bp) > + return XFS_ERROR(ENOMEM); > + > if ((bp != NULL) && (XFS_BUF_GETERROR(bp) != 0)) { > xfs_ioerror_alert("xfs_trans_read_buf", mp, > target->dev, blkno); > --- linux-xfs/fs/xfs_support/kmem.c-XFSMEM Tue Aug 14 01:12:46 2001 > +++ linux-xfs/fs/xfs_support/kmem.c Tue Aug 14 01:51:14 2001 > @@ -47,6 +47,15 @@ > #define GFP_NOFS GFP_BUFFER > #endif > > +/* random generator stolen from net/core/utils.c. */ > +static unsigned long xfs_rand_seed = 152L; > + > +unsigned long xfs_random(void) > +{ > + xfs_rand_seed=xfs_rand_seed*69069L+1; > + return xfs_rand_seed^jiffies; > +} > + > static __inline__ unsigned int flag_convert(int flags) > { > if (flags & KM_NOSLEEP) return GFP_ATOMIC; > @@ -79,8 +88,13 @@ > rval = kmalloc(size, flag_convert(flags)); > } > > - if (rval || (flags & KM_NOSLEEP)) > - return rval; > + if (!rval) { > + if ((flags & KM_NOSLEEP) == 0) { > + printk(KERN_ERR "xfs [%d]: failed to allocate %d bytes. > \n", current->pid, size); > + return NULL; > + } > + } else > + return rval; > > /* > * KM_SLEEP callers don't expect a failure > @@ -93,8 +107,16 @@ > } > > rval = __vmalloc(size, flag_convert(flags), PAGE_KERNEL); > - if (!rval && (flags & KM_SLEEP)) > - panic("kmem_alloc: NULL memory on KM_SLEEP request!"); > + if (!rval) { > + if (flags & KM_SLEEP) { > + printk(KERN_ERR "xfs [%d]: failed to allocate %d bytes. > waiting and retry.\n", > + current->pid, size); > + delay(5 + xfs_random()%10); > + shrink = DEF_PRIORITY; > + goto repeat; > + } > + printk(KERN_ERR "xfs [%d]: failed to allocate %d bytes.\n", cur > rent->pid, size); > + } > > return rval; > } > @@ -157,8 +179,11 @@ > repeat: > ptr = kmem_cache_alloc(zone, flag_convert(flags)); > > - if (ptr || (flags & KM_NOSLEEP)) > + if (ptr || (flags & KM_NOSLEEP)) { > + if (!ptr) > + printk(KERN_ERR "xfs [%d]: failed to allocate from zone > .\n", current->pid); > return ptr; > + } > > /* > * KM_SLEEP callers don't expect a failure > @@ -170,8 +195,13 @@ > goto repeat; > } > > - if (flags & KM_SLEEP) > - panic("kmem_zone_alloc: NULL memory on KM_SLEEP request!"); > + if (flags & KM_SLEEP) { > + printk(KERN_ERR "xfs [%d]: failed to allocate from zone. waitin > g and retry.\n", > + current->pid); > + delay(5 + xfs_random()%10); > + shrink = DEF_PRIORITY; > + goto repeat; > + } > > return NULL; > } > @@ -185,21 +215,29 @@ > repeat: > ptr = kmem_cache_zalloc(zone, flag_convert(flags)); > > - if (ptr || (flags & KM_NOSLEEP)) > + if (ptr || (flags & KM_NOSLEEP)) { > + if (!ptr) > + printk(KERN_ERR "xfs [%d]: failed to allocate from zone > .\n", current->pid); > return ptr; > + } > > /* > * KM_SLEEP callers don't expect a failure > */ > if (shrink) { > kmem_shake(); > - > + > shrink--; > goto repeat; > } > > - if (flags & KM_SLEEP) > - panic("kmem_zone_zalloc: NULL memory on KM_SLEEP request!"); > + if (flags & KM_SLEEP) { > + printk(KERN_ERR "xfs [%d]: failed to allocate from zone. waitin > g and retry.\n", > + current->pid); > + delay(5 + xfs_random()%10); > + shrink = DEF_PRIORITY; > + goto repeat; > + } > > return NULL; > } From owner-linux-xfs@oss.sgi.com Tue Aug 14 15:30:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EMU4223563 for linux-xfs-outgoing; Tue, 14 Aug 2001 15:30:04 -0700 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 f7EMTxj23532 for ; Tue, 14 Aug 2001 15:29:59 -0700 Received: from fwd00.sul.t-online.de by mailout05.sul.t-online.de with smtp id 15WmhB-0005Po-03; Wed, 15 Aug 2001 00:29:57 +0200 Received: from merlin.dettmering.org (320081421941-0001@[217.226.206.101]) by fmrl00.sul.t-online.com with esmtp id 15Wmh4-19lUMyC; Wed, 15 Aug 2001 00:29:50 +0200 Received: from pc16154.pharmazie.uni-marburg.de (dastiban.dettmering.org [192.168.66.2]) by merlin.dettmering.org (Postfix) with ESMTP id C6C7B5DF03 for ; Wed, 15 Aug 2001 00:29:51 +0200 (CEST) Message-ID: <3B79A65E.EB59079D@pc16154.pharmazie.uni-marburg.de> Date: Wed, 15 Aug 2001 00:29:50 +0200 From: Dirk Dettmering Organization: EDV-Abteilung und AK Imming - FB Pharmazie, Uni Marburg X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: de, en MIME-Version: 1.0 To: SGI XFS ML Subject: Strange errors after upgrading the command rpms Content-Type: multipart/mixed; boundary="------------0124460E6FF948BA77B283FA" X-Sender: 320081421941-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------0124460E6FF948BA77B283FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, two weeks ago I tried to upgrade the command rpms on a small server in my institute but during rpm -Fvh the machine crashed. Afterwards I couldn't boot anymore because of severe errors on the root partition. I couldn't repair the partition in single user mode because the fileutils especially xfs_repair were completly broken. So I booted from the 1.0.1 install cd and repaired the partition and used xfs_repair several times. Afterwards I replaced all files from the command rpms with the manually extracted files from the new rpms which I tried to upgrade. These are the now by rpm -qa reported versions of the command rpms: xfsprogs-devel-1.2.7-0 xfsprogs-1.3.1-pre1 xfsdump-1.0.11-0 acl-1.0.8-0 acl-devel-1.0.8-0 layout of the partitions: pc16154:[] #mount /dev/hda2 on / type xfs (rw) none on /proc type proc (rw) /dev/hda1 on /boot type ext2 (rw) /dev/hda8 on /home type ext2 (rw) /dev/hda9 on /home/data type xfs (rw) /dev/hda7 on /usr/local type xfs (rw) /dev/hda6 on /var type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) hardware is: AMD K6-2 500 MHz on a Gigabyte GA-5AA Board 196 MB Ram Ati Mach64 PCI IBM DTLA 305040 HD 3C590 Teles 16.3 ISDN card But the problem with the partition didn't vanish completly but instead I got some really strange errors. Every two or three days some files on that partition were missing and every time I had to boot to single user mode run xfs_repair and then I could copy over the missing files. But today I got several kernel oops during normal operation and I couldn't copy the files over as fast as they disapeared. After copying the missing files sometimes the affected files show up two or three times in the directory when using ls! I've attached a file with the output of ls -il in two of the affected directories. When the first crash during the update of the command rpms happend, the kernel was 2.4.6 with the non-cvs xfs-patch for this version. Last week I updated the kernel to 2.4.8-pre4 cause I had the hope to get away with the filesystem trouble: Linux pc16154.pharmazie.uni-marburg.de 2.4.8-pre4-xfs #1 Die Aug 7 17:06:15 CEST 2001 i586 unknown If you wonder why I havn't reinstalled the machine already that's because I didn't have time to do it 'till now. But since today the problem have become so serious that I have to reinstall the machine tomorrow morning (CEST). If someone wants more information I will be happy to collect as many informations as possible before I start. I will not use xfs on that machine again because I need ADSM backup and don't want to get by the backup trouble by remounting the xfs partitions via nfs or any other shoot-in-your-feet solution. Greetings from Germany Dirk P.S.: I'm still happy with xfs! ;-) I have it running on two other machines without any hassle (but I used only the official kernel rpms from 1.0 and 1.0.1, 2.4.2 and 2.4.5 on both) and had never any problem with my SGI O2 in nearly five years! P.P.S.: Should I update the command rpms in single user mode or is it okay to do it during normal operation? -- ===============D=i=r=k===D=e=t=t=m=e=r=i=n=g==================== http://pc16154.pharmazie.uni-marburg.de/dettmering/index.html Tel.: +49 6421 28 21332 Fax: +49 6421 28 25828 Faculty of Pharmacy - Philipps University Marburg - Germany Enjoy drugs in 3D and read some basic facts gathered by students Visit our drug database WisDa: http://www.wisda.de --------------0124460E6FF948BA77B283FA Content-Type: application/x-unknown-content-type-PABZIP2; name="xfs_defekt.txt.bz2" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="xfs_defekt.txt.bz2" QlpoOTFBWSZTWcjJ/LgABhdfgX/SQBP/8T/3/qC/7//gBABgBz1G+KN8wdsAdAredgKAxSj1 NqanoIaGINGBGgGJmpo9NJ4p6AGkYCkmgABoAAGNRoAAABxkyZMRiYATJgmQA0YRgCGAQqSJ oyj0mg9QAA0MgAAaANACKKE0aCemjRqYpoNAGgAABpkNNBJAgmhCaiAGgAAAAAABqQUDUoj6 OLh17opmgpOrgxTRVVJIpJJIoJe6sR0B5xta9pmi00n6qzQP+kE250FODWPlbFEEdCPYYihC lmFloRncwy74TxojIdwAwuIuExijBjAQkSqb/B4LMOuAH8Gas+ODLFpxGMZWIzNOl8JyLyxc pIumzHDK0wrnBVFaysmyq5uDY0WAopF82M5zckpWMgGFljuUAJgQmLgZrBsrpBk7BgJtwMdP 2g4B0gi4vVYQZrbpzvXEtw/NU6OS6yWkbM3AzceoRaKGw8jjkYGegSgSZVXesq5KlERCNBCB gbQyCrQ5zULWWbFrpod4vsklcEXhwHq98SpI+JQpiCFEQQDu6HdyIghREEIyOOTMEERBBEQQ Gk6dTMEGGvWb3p8PWnKwXYm2z5UoQobG9G3DkSZEBoCcNTmkyzffl9nYAPNAB3XCPTvqAHqA GlRDEIjry6pI4oIiYogSYJgmKKEtCGEZIQS1LGtt6OonfXuozDf738XqNuMQeQecMHBjWqjT ba34kYfFFOnQ6qwMZa+XHYHaGHGcGiHzlMzDayWLu3leidQDwN28N5ju/mwV5/z0YI9CoGYw 9DfQJBgAvtQUDoC4e5nyVE2lIYEzBhi5DlJ4HfbKsEUyjCK2DdPdtn+EEW3OB7xo4sCVbmAy BArLgInDNbdvAAYbStd4GVtIYRBRbH6KB5sBTBl0ntCyt4oxADXAI034hhnTnz7DJnlVsvyZ kAsMCMYcEtAsX0mJCK8ViLLN+bnj66ys5SzeUgmTNcFGreMbtD7uXIHi8kqSnrsd0hFNNzCT mxltgsyI0wdWDhlNxjhYk6N1Zhk6l6VlaEuGCOm7eKe9RBSXewh9zDbYDnva1DKKfwfbR1YE VcLhTpA3OgRy1WFleAn6xw7nTkojFQlZwp0iKuhDa68RHG0O6vEvINGBphzm1qhg6U8u/L8P jkEwAuQ5VotV1AAuBgq+lG4SWqUjjYXx2ZDcC0HXOOCkhEQ3nJP2i9JHJBwxYa3d4NUOhEMJ G6oY1Gk3caOUG5q0Zi51jeTexFLQzVyOYoAYI24gVtrCRtrCyd/C2bsdiX6NAFYYBHvi/tJk FabpXgiQIlX7m86wDt2y7EzNXsjrT/StnZdsFBkahmd9lY3VGiHemreRt1irkySxlHa9mGYj hgk3p2qmWA0+dW3iUbJiqe1ZyPSssnbKEPMqLBCQQ0clQGWDBwyEarmd9FJBhsa4Q4I3JJyP O0AamXEh0uDBqjTJgzmNdkJS0pGcyk2giQY2ZYYHGxsml3S31tBQJMsTo8GuWoaMTKVwxBWY woGlFLFKaZA3CPeX9fTSAgfZMOsmUmRqmY6dkiifySE0QCBKWOlc0VXMJZPE9WrR13UJn7E+ EkRg4yQHZsZJwAi2AQ8EKNL+eh/W/A7Z/fav8qGqKrXCQDSoH0Xiy5ONvjOYdKnLaGiEpXUP OYlpFWtX8yFA3Z/tEfechcaL7xVp1WdSmfGuzGSKt9Kmsp0kkAXlYo1bBixHHQQ80eDDICaB 1gA7QKCC7pxhr5ymrOC1m+RvghIV8JmtMK5K96qlozooEaaowV2KR/qTjFWuuisMOgd27KpV iMB2goZVz0HmtFNKit1giu2hd+UbjlF0rtGi4ALBetCVWAxgA8BEbFLjkRdrGw5+UiP1PnDF VRBBNMEAGWdYBhDIAORhRvEZdjetWbCeQGePDKtQ6iIBQtOFC8qFWzuDZC0a7JskRW87FkJG qsnQKuCzkFWRmzcKPXJaakOBAqNuCI/xyyiMqLmHAcS99H/i7kinChIZGT+XAA== --------------0124460E6FF948BA77B283FA-- From owner-linux-xfs@oss.sgi.com Tue Aug 14 15:50:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EMoga24230 for linux-xfs-outgoing; Tue, 14 Aug 2001 15:50:42 -0700 Received: from ente.berdmann.de (frnk-d5141a4b.dsl.mediaWays.net [213.20.26.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EModj24207 for ; Tue, 14 Aug 2001 15:50:39 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15Wn16-0001LL-00 for linux-xfs@oss.sgi.com; Wed, 15 Aug 2001 00:50:32 +0200 Message-ID: <3B79AB38.B7A8DC0C@berdmann.de> Date: Wed, 15 Aug 2001 00:50:32 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: oops with 2.4.8-xfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, this evening I got a complete system lockup with kernel 2.4.8-xfs CVS checkout of this morning. It locked up as soon as I started xfsdump on a filesystem. Afterwards, I found in /var/log/warn: Aug 14 19:48:29 hostname kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Aug 14 19:48:29 hostname kernel: printing eip: Aug 14 19:48:29 hostname kernel: c0137569 Aug 14 19:48:29 hostname kernel: *pde = 00000000 Aug 14 19:48:29 hostname kernel: Oops: 0000 Aug 14 19:48:29 hostname kernel: CPU: 1 Aug 14 19:48:29 hostname kernel: EIP: 0010:[mangle+17/148] Aug 14 19:48:29 hostname kernel: EFLAGS: 00010292 Aug 14 19:48:29 hostname kernel: eax: 00000000 ebx: 0000007e ecx: 00000000 edx: dec3b07e Aug 14 19:48:29 hostname kernel: esi: c1889ea0 edi: c188df60 ebp: dec3b07e esp: ded39edc Aug 14 19:48:29 hostname kernel: ds: 0018 es: 0018 ss: 0018 Aug 14 19:48:29 hostname kernel: Process df (pid: 8471, stackpage=ded39000) Aug 14 19:48:29 hostname kernel: Stack: 0000007e c1889ea0 c188df60 c188df60 ffffffff c01377b1 c01377b9 00000000 Aug 14 19:48:29 hostname kernel: dec3b07e 00000eba ded2effb dec3b079 00000ebf df83ff20 dec3b06c 00000ecc Aug 14 19:48:29 hostname kernel: ded39f94 00000c00 dec3b000 00000000 ded2effb ded38000 dffce440 dffdaea0 Aug 14 19:48:29 hostname kernel: Call Trace: [get_filesystem_info+453/1088] [get_filesystem_info+461/1088] [mounts_read_proc+26/52] [proc_file_read+242/404] [sys_read+143/196] [system_call+51/56] Aug 14 19:48:29 hostname kernel: Aug 14 19:48:29 hostname kernel: Code: 80 39 00 74 71 8b 44 24 24 83 c0 fd 89 44 24 10 85 c0 7e 62 It happened three times after a subsequential reboot. After downgrading to 2.4.7-xfs, the problem disappeared. The system is a dual PIII-1000. Any clue? # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:0e.0 PCI bridge: Distributed Processing Technology PCI Bridge (rev 02) 00:0e.1 I2O: Distributed Processing Technology SmartRAID V Controller (rev 02) 00:10.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 86C326 (rev 0b) From owner-linux-xfs@oss.sgi.com Tue Aug 14 16:01:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EN1av24636 for linux-xfs-outgoing; Tue, 14 Aug 2001 16:01:36 -0700 Received: from lists.samba.org (samba.sourceforge.net [198.186.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EN1Yj24617 for ; Tue, 14 Aug 2001 16:01:34 -0700 Received: by lists.samba.org (Postfix, from userid 1002) id EBCC34539; Tue, 14 Aug 2001 15:57:36 -0700 (PDT) From: Andrew Tridgell To: linux-xfs@oss.sgi.com Subject: minor logdev bugs Reply-To: tridge@valinux.com Message-Id: <20010814225736.EBCC34539@lists.samba.org> Date: Tue, 14 Aug 2001 15:57:36 -0700 (PDT) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS doesn't open the logdev during use, which has two unfortunate consequences. The first is if you mount a XFS filesystem while the logdev device is not loaded (say for example if the logdev is on a device implemented in a kernel module). You get an oops from within linvfs_read_super() when it calls into the pagebug to ask for pages on a device that doesn't exist. The second is that the usage count of the logdev module remains at zero while the logdev is being used, which means it can be removed. Then you get an almost certain lockup when XFS next tries to use the log. It also means that someone else can come along and use the devive without any usage count tests kicking in. You can reproduce the effect by using a logdev on a ramdisk. Cheers, Tridge From owner-linux-xfs@oss.sgi.com Tue Aug 14 16:07:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EN7Qe24832 for linux-xfs-outgoing; Tue, 14 Aug 2001 16:07:26 -0700 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 f7EN7Pj24813 for ; Tue, 14 Aug 2001 16:07:25 -0700 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 19:06:38 -0400 Message-ID: <23D04BDBA646D411BDDD00D0B774B5390460255A@SA-BWMAIL1> From: "Christian, Chip" To: "Linux XFS (E-mail)" Subject: mounts sometimes take forever Date: Tue, 14 Aug 2001 19:06:34 -0400 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 Has anyone seen "mount -f xfs /dev/blah /blah" take an extremely long time , possibly an eternity, to complete? We're running 2.4.3-SGI_XFS_1.0.1 #1 SMP, i686, RedHat Linux 7.1 on a pair of servers, in an HA fashion. When node #1 notes that node #2 isn't responding, he mounts all of node #2's filesystems. What we have seen happen exactly twice now (out of many, many more successful mounts) is that a mount of one of the filesystems takes a long time, long enough that the user gave up and rebooted. In one instance, the mount command ate 25 minutes of cpu in 30 minutes before we aborted. mount was in state RN. Is there anything anyone can think of I might try to diagnose this if it happens again? strace and ltrace are useless; we're sitting inside mount(). Anything else I can use to see what's going on? Could it be a timing thing, where node #2 is coming down and is in the process of umounting the filesystem while node #1 starts to mount the same filesystem? Thanks for any and all assistance. -Chip From owner-linux-xfs@oss.sgi.com Tue Aug 14 16:40:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ENe7M25795 for linux-xfs-outgoing; Tue, 14 Aug 2001 16:40:07 -0700 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 f7ENe5j25774 for ; Tue, 14 Aug 2001 16:40:06 -0700 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 f7ENioS06416 for ; Tue, 14 Aug 2001 16:44:50 -0700 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 SAA2709466 for ; Tue, 14 Aug 2001 18:38:44 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA24766 for ; Tue, 14 Aug 2001 18:38:44 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7ENbFJ16359; Tue, 14 Aug 2001 18:37:15 -0500 Message-Id: <200108142337.f7ENbFJ16359@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Re: TAKE - fix ABBA deadlock under heavy load In-Reply-To: Message from Steve Lord of "Tue, 14 Aug 2001 17:08:51 CDT." <200108142208.f7EM8pC15524@jen.americas.sgi.com> Date: Tue, 14 Aug 2001 18:37:15 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > This may be what Andrew Tridgell hit, I hit it running dbench 140 > and deadlocked between kswapd reclaiming inodes and kupdated > flushing inodes. 160 stack traces later...... > OK, this may not be the end of this one yet, I I would hold off on updating to include this file, I drove home and my test box crashed on the next run..... time to think harder about this one.... Steve From owner-linux-xfs@oss.sgi.com Tue Aug 14 17:13:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F0Di926582 for linux-xfs-outgoing; Tue, 14 Aug 2001 17:13:44 -0700 Received: from www.fortuitous.com (cs666824-51.austin.rr.com [66.68.24.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F0Dgj26563 for ; Tue, 14 Aug 2001 17:13:42 -0700 Received: by www.fortuitous.com (Postfix, from userid 500) id F1A36829; Tue, 14 Aug 2001 19:11:07 -0500 (CDT) Date: Tue, 14 Aug 2001 19:11:07 -0500 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Re: 2.4.8 devel snapshot patch available Message-ID: <20010814191107.A18246@bistro.marx> Reply-To: pac@fortuitous.com References: <3B7818B0.FEF6356@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <3B7818B0.FEF6356@sgi.com>; from sandeen@sgi.com on Mon, Aug 13, 2001 at 01:13:04PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Aug 13, 2001 at 01:13:04PM -0500, Eric Sandeen wrote: > A development snapshot patch against 2.4.8 is now available in > > ftp://oss.sgi.com/projects/xfs/download/patches/ > > Steve said this merge was a bit trickier, so all the usual dire warnings > about development snapshots certainly apply here. The docs are confusing. Do i need to apply only 1 patch? See the comment about "Do not use..." patch-2.4.x-xfs-cvs-.bz2 CVS seed patch: patch a vanilla linux 2.4.x tree to a "cvs update -d" capable tree. The resulting tree includes all kernel and userspace code for XFS. Do not use this patch unless you are willing stay up-to-date with "current". patch-2.4.x-xfs-.bz2 Patches to take a vanilla linux 2.4.x tree to an xfs capable kernel. Note that these are kernel only patches, command source can be obtained from the cmd_tars directory. -phil -- .--------------------------------------------------------. | 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 Tue Aug 14 17:42:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F0gbM27395 for linux-xfs-outgoing; Tue, 14 Aug 2001 17:42:37 -0700 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 f7F0gZj27372 for ; Tue, 14 Aug 2001 17:42:35 -0700 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 f7F0lJS08500 for ; Tue, 14 Aug 2001 17:47:19 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id KAA15181; Wed, 15 Aug 2001 10:42:26 +1000 Date: Wed, 15 Aug 2001 10:42:26 +1000 From: Keith Owens Message-Id: <200108150042.KAA15181@sherman.melbourne.sgi.com> Subject: TAKE - Remove BLKBSZ[GS]ET Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove the blocksize ioctls. Date: Tue Aug 14 17:41:23 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100780a linux/include/linux/fs.h - 1.109 linux/drivers/block/ps2esdi.c - 1.17 linux/arch/sparc64/kernel/ioctl32.c - 1.39 linux/drivers/block/blkpg.c - 1.8 linux/drivers/block/cpqarray.c - 1.24 linux/drivers/block/DAC960.c - 1.32 linux/drivers/ide/ide.c - 1.24 linux/arch/mips64/kernel/ioctl32.c - 1.7 linux/drivers/md/lvm.c - 1.14 linux/drivers/block/cciss.c - 1.11 linux/drivers/md/md.c - 1.17 From owner-linux-xfs@oss.sgi.com Tue Aug 14 18:00:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F10Za27891 for linux-xfs-outgoing; Tue, 14 Aug 2001 18:00:35 -0700 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 f7F10Xj27872 for ; Tue, 14 Aug 2001 18:00:33 -0700 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 f7F15GS09025 for ; Tue, 14 Aug 2001 18:05:16 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA20167; Wed, 15 Aug 2001 10:59:09 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA01540; Wed, 15 Aug 2001 10:59:06 +1000 (AEST) Date: Wed, 15 Aug 2001 10:59:06 +1000 From: Nathan Scott To: Andrew Tridgell Cc: linux-xfs@oss.sgi.com Subject: Re: minor logdev bugs Message-ID: <20010815105906.D302907@wobbly.melbourne.sgi.com> References: <20010814225736.EBCC34539@lists.samba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010814225736.EBCC34539@lists.samba.org>; from tridge@valinux.com on Tue, Aug 14, 2001 at 03:57:36PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Andrew, On Tue, Aug 14, 2001 at 03:57:36PM -0700, Andrew Tridgell wrote: > XFS doesn't open the logdev during use, which has two unfortunate > consequences. > > The first is if you mount a XFS filesystem while the logdev device is > not loaded (say for example if the logdev is on a device implemented > in a kernel module). You get an oops from within linvfs_read_super() > when it calls into the pagebug to ask for pages on a device that ^^^^^^^ Freudian slip? ;-) > doesn't exist. > > The second is that the usage count of the logdev module remains at > zero while the logdev is being used, which means it can be > removed. Then you get an almost certain lockup when XFS next tries to > use the log. It also means that someone else can come along and use > the devive without any usage count tests kicking in. > > You can reproduce the effect by using a logdev on a ramdisk. Steve's just sent me some notes on how to fix this - I'll get onto it later today. Thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 14 18:08:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F18Lv28165 for linux-xfs-outgoing; Tue, 14 Aug 2001 18:08:21 -0700 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 f7F18Jj28146 for ; Tue, 14 Aug 2001 18:08:19 -0700 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 f7F1E5W10068 for ; Tue, 14 Aug 2001 18:14:05 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20238; Wed, 15 Aug 2001 11:06:54 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA91772; Wed, 15 Aug 2001 11:06:53 +1000 (AEST) Date: Wed, 15 Aug 2001 11:06:52 +1000 From: Nathan Scott To: "Christian, Chip" Cc: "Linux XFS (E-mail)" Subject: Re: mounts sometimes take forever Message-ID: <20010815110651.E302907@wobbly.melbourne.sgi.com> References: <23D04BDBA646D411BDDD00D0B774B5390460255A@SA-BWMAIL1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <23D04BDBA646D411BDDD00D0B774B5390460255A@SA-BWMAIL1>; from chip.christian@storageapps.com on Tue, Aug 14, 2001 at 07:06:34PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Tue, Aug 14, 2001 at 07:06:34PM -0400, Christian, Chip wrote: > Has anyone seen "mount -f xfs /dev/blah /blah" take an extremely long time , possibly an eternity, to complete? > > We're running 2.4.3-SGI_XFS_1.0.1 #1 SMP, i686, RedHat Linux 7.1 on a pair of servers, in an HA fashion. > > When node #1 notes that node #2 isn't responding, he mounts all of node #2's filesystems. What we have seen happen exactly twice now (out of many, many more successful mounts) is that a mount of one of the filesystems takes a long time, long enough that the user gave up and rebooted. In one instance, the mount command ate 25 minutes of cpu in 30 minutes before we aborted. mount was in state RN. > > Is there anything anyone can think of I might try to diagnose this if it happens again? strace and ltrace are useless; we're sitting inside mount(). Anything else I can use to see what's going on? > build a kernel with kdb enabled, drop into kdb during the hang, and start with a backtrace. Sounds like its got itself into an infinite loop, most likely during recovery. also could try enabling profiling (append profile=2 in lilo.conf) and use readprofile to see where all the time is being spent... that will only give you the function though, kdb will be more useful. > Could it be a timing thing, where node #2 is coming down and is in the process of umounting the filesystem while node #1 starts to mount the same filesystem? Is node one still writing to the filesystem while node 2 is trying to recover? that would be bad and you'll need to ensure that doesn't happen (does node one shoot node two via a reset line if it is not responding? and only then attempt the mount?). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 14 18:25:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F1P4g28590 for linux-xfs-outgoing; Tue, 14 Aug 2001 18:25:04 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F1P0j28571 for ; Tue, 14 Aug 2001 18:25:00 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA08245 for ; Tue, 14 Aug 2001 18:24:54 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20334; Wed, 15 Aug 2001 11:23:36 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA96962; Wed, 15 Aug 2001 11:23:35 +1000 (AEST) Date: Wed, 15 Aug 2001 11:23:31 +1000 From: Nathan Scott To: Dirk Dettmering Cc: SGI XFS ML Subject: Re: Strange errors after upgrading the command rpms Message-ID: <20010815112331.F302907@wobbly.melbourne.sgi.com> References: <3B79A65E.EB59079D@pc16154.pharmazie.uni-marburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B79A65E.EB59079D@pc16154.pharmazie.uni-marburg.de>; from dettmer@pc16154.pharmazie.uni-marburg.de on Wed, Aug 15, 2001 at 12:29:50AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Aug 15, 2001 at 12:29:50AM +0200, Dirk Dettmering wrote: > Hello, > > two weeks ago I tried to upgrade the command rpms on a small server in > my institute but during rpm -Fvh the machine crashed. Afterwards I > couldn't boot anymore because of severe errors on the root partition. > I couldn't repair the partition in single user mode because the > fileutils especially xfs_repair were completly broken. So I booted Were you part way through installing new XFS rpms when you crashed? That might explain why the commands were trashed (right?). > from the 1.0.1 install cd and repaired the partition and used > xfs_repair several times. Afterwards I replaced all files from the > command rpms with the manually extracted files from the new rpms which > I tried to upgrade. > > These are the now by rpm -qa reported versions of the command rpms: > xfsprogs-devel-1.2.7-0 > xfsprogs-1.3.1-pre1 This is very old & moldy, probably from cvs right? (these "pre" rpms were never "released") - I would upgrade at least this, and probably everything XFS related in your userspace. > xfsdump-1.0.11-0 > acl-1.0.8-0 > acl-devel-1.0.8-0 > > ...[snip]... > > But the problem with the partition didn't vanish completly but instead > I got some really strange errors. Every two or three days some files > on that partition were missing and every time I had to boot to single > user mode run xfs_repair and then I could copy over the missing files. > But today I got several kernel oops during normal operation and I > couldn't copy the files over as fast as they disapeared. After copying > the missing files sometimes the affected files show up two or three > times in the directory when using ls! > I've attached a file with the output of ls -il in two of the affected > directories. > > When the first crash during the update of the command rpms happend, > the kernel was 2.4.6 with the non-cvs xfs-patch for this version. Last Which version of gcc did you use to compile this kernel? You will probably get best results with egcs-2.91.66. > week I updated the kernel to 2.4.8-pre4 cause I had the hope to get > away with the filesystem trouble: > Linux pc16154.pharmazie.uni-marburg.de 2.4.8-pre4-xfs #1 Die Aug 7 > 17:06:15 CEST 2001 i586 unknown > > If you wonder why I havn't reinstalled the machine already that's > because I didn't have time to do it 'till now. But since today the > problem have become so serious that I have to reinstall the machine > tomorrow morning (CEST). If someone wants more information I will be If you are looking for stability, I wouldn't recommend following the 2.4.X releases as you seem to have been - try the stable XFS releases (ie. 1.0.1). > > Dirk > > P.S.: I'm still happy with xfs! ;-) I have it running on two other > machines without any hassle (but I used only the official kernel rpms > from 1.0 and 1.0.1, 2.4.2 and 2.4.5 on both) and had never any problem > with my SGI O2 in nearly five years! > that's good to hear. > P.P.S.: Should I update the command rpms in single user mode or is it > okay to do it during normal operation? I'm not sure that'll make much difference - there will always be a chance that a crash will happen during an upgrade and that is likely to be disastrous no matter which runlevel you're at. Hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 14 18:27:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F1RZm28755 for linux-xfs-outgoing; Tue, 14 Aug 2001 18:27:35 -0700 Received: from mplspop5.mpls.uswest.net (mplspop5.mpls.uswest.net [204.147.80.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F1RXj28734 for ; Tue, 14 Aug 2001 18:27:33 -0700 Received: (qmail 7068 invoked from network); 15 Aug 2001 01:27:29 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop5.mpls.uswest.net with SMTP; 15 Aug 2001 01:27:29 -0000 Date: Tue, 14 Aug 2001 20:24:25 -0500 Message-ID: <3B79CF49.FECF1552@sgi.com> From: "Eric Sandeen" To: "Nathan Scott" Cc: "Christian, Chip" , " Linux XFS (E-mail)" 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 Subject: Re: mounts sometimes take forever References: <23D04BDBA646D411BDDD00D0B774B5390460255A@SA-BWMAIL1> <20010815110651.E302907@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just to provide a little more guidance... :) Nathan Scott wrote: > > We're running 2.4.3-SGI_XFS_1.0.1 #1 SMP > build a kernel with kdb enabled, This kernel should have kdb in it, just echo 1 > /proc/sys/kernel/kdb > drop into kdb during the hang, (hit the "pause" key if you're at the console) > and start with a backtrace. type "bt" at the kdb prompt. All this is actually easier if you set up a serial console (well, easier to capture the output). -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 14 18:47:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F1lKb29431 for linux-xfs-outgoing; Tue, 14 Aug 2001 18:47:20 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F1lHj29412 for ; Tue, 14 Aug 2001 18:47:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA14647 for ; Tue, 14 Aug 2001 18:46:55 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20483; Wed, 15 Aug 2001 11:45:52 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA95056; Wed, 15 Aug 2001 11:45:50 +1000 (AEST) Date: Wed, 15 Aug 2001 11:45:48 +1000 From: Nathan Scott To: Vincent Bernat Cc: linux-xfs@oss.sgi.com Subject: Re: New tarball error Message-ID: <20010815114548.G302907@wobbly.melbourne.sgi.com> References: <000001c1242c$b968d220$650aa8c0@vauntmure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bernat@free.fr on Tue, Aug 14, 2001 at 06:07:36PM +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7F1lHj29413 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Tue, Aug 14, 2001 at 06:07:36PM +0200, Vincent Bernat wrote: > OoO En ce début de soirée du lundi 13 août 2001, vers 21:18, Adam > Pendleton disait: > > > One of the new tarballs generated today: > [...] > > I have just compiled latest tarballs and found some glitches (I have > never compiled earlier tarballs, so it may be "normal") : > - in my system, libtool is > /usr/local/libexec/rep/i686-pc-linux-gnu/libtool and not > /usr/bin/libtool. I have never seen any program who have complained > about this. That's a strange place for libtool. I have checked only Debian and Redhat, but they both install it in /usr/bin. I think /usr/bin is also only a backup if it can't be found on your path, this is from configure.in: dnl ensure libtool is installed AC_PATH_PROG(LIBTOOL, libtool,,/usr/bin) if test "$LIBTOOL" = ""; then echo echo 'FATAL ERROR: libtool does not seem to be installed.' echo $pkg_name cannot be built without a working libtool installation. exit 1 fi libtool=$LIBTOOL AC_SUBST(libtool) Is this the error you're running into? The fourth parameter should be just a fallback path in case its not found anywhere else, IIRC. > - compiling xfsprogs (and I suppose others) with --enable-shared=no > produces dynamic executables (just like without this option) and > make install-dev fails because it tries to install libxfs.lai > instead of libxfs.la. After correcting the Makefile, (replacing lai > by la for the static target), it goes fine however, configure of > xfsdump (I haven't tried with others) complains that it doesn't > find libxfs. Yup, that sounds like its wrong, will need to be looked at - thanks for reporting. > > BTW, I don't understand what dmapi is. In what it is useful ? Do I > need it for xfsdump ? > A brief description follows... (yes, xfsdump does need it as it links with libdm). This is a brief description from the rpm/deb packages - ie. "rpm -q -i dmapi" / "dpkg -s dmapi": Description : Files required by system software using the Data Management API (DMAPI). This is used to implement the interface defined in the X/Open document: Systems Management: Data Storage Managment (XDSM) API dated February 1997. This interface is implemented by the libdm library. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 14 19:10:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F2APO30055 for linux-xfs-outgoing; Tue, 14 Aug 2001 19:10:25 -0700 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 f7F2ANj30035 for ; Tue, 14 Aug 2001 19:10:23 -0700 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 f7F0SbW08658 for ; Tue, 14 Aug 2001 17:28:37 -0700 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 TAA2711062; Tue, 14 Aug 2001 19:21:27 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id TAA35776; Tue, 14 Aug 2001 19:21:27 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7F0JvF16575; Tue, 14 Aug 2001 19:19:57 -0500 Message-Id: <200108150019.f7F0JvF16575@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: pac@fortuitous.com cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.8 devel snapshot patch available In-Reply-To: Message from pac@fortuitous.com of "Tue, 14 Aug 2001 19:11:07 CDT." <20010814191107.A18246@bistro.marx> Date: Tue, 14 Aug 2001 19:19:57 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Mon, Aug 13, 2001 at 01:13:04PM -0500, Eric Sandeen wrote: > > A development snapshot patch against 2.4.8 is now available in > > > > ftp://oss.sgi.com/projects/xfs/download/patches/ > > > > Steve said this merge was a bit trickier, so all the usual dire warnings > > about development snapshots certainly apply here. > > The docs are confusing. Do i need to apply only 1 patch? > See the comment about "Do not use..." > > patch-2.4.x-xfs-cvs-.bz2 > CVS seed patch: patch a vanilla linux 2.4.x tree to a "cvs update -d" > capable tree. The resulting tree includes all kernel and userspace > code for XFS. Do not use this patch unless you are willing stay > up-to-date with "current". > > patch-2.4.x-xfs-.bz2 > Patches to take a vanilla linux 2.4.x tree to an xfs capable > kernel. Note that these are kernel only patches, command > source can be obtained from the cmd_tars directory. If you want to take a kernel tree from kernel.org and add just xfs to it then take the patch without cvs in it's name. If you want to start following the cvs tree instead of just using patches, then take the cvs patch. It is a super set of the other one, the additional content is all the cvs files you would get in a tree to allow you to download the cvs development version of xfs as it progresses. Steve > > -phil > -- > .--------------------------------------------------------. > | 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 Tue Aug 14 19:16:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F2G4D30322 for linux-xfs-outgoing; Tue, 14 Aug 2001 19:16:04 -0700 Received: from mplspop4.mpls.uswest.net (mplspop4.mpls.uswest.net [204.147.80.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F2G2j30302 for ; Tue, 14 Aug 2001 19:16:02 -0700 Received: (qmail 59187 invoked from network); 15 Aug 2001 02:15:58 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop4.mpls.uswest.net with SMTP; 15 Aug 2001 02:15:58 -0000 Date: Tue, 14 Aug 2001 21:12:54 -0500 Message-ID: <3B79DAA6.E85BC57E@sgi.com> From: "Eric Sandeen" To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com 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 Subject: Re: 2.4.8 devel snapshot patch available References: <3B7818B0.FEF6356@sgi.com> <20010814191107.A18246@bistro.marx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk pac@fortuitous.com wrote: > > On Mon, Aug 13, 2001 at 01:13:04PM -0500, Eric Sandeen wrote: > > A development snapshot patch against 2.4.8 is now available in > > > > ftp://oss.sgi.com/projects/xfs/download/patches/ > > > > Steve said this merge was a bit trickier, so all the usual dire warnings > > about development snapshots certainly apply here. > > The docs are confusing. Do i need to apply only 1 patch? Yep, only one patch. The "cvs" patch will build a cvs tree as of the date & time the patch was created, you can continue to use cvs to update this tree. The "non-cvs" patch will just patch up a kernel to the state cvs was in at the time, but does not construct a whole cvs tree. > See the comment about "Do not use..." The "do not use" is a bit dire, perhaps, it's just that there's no reason to grab all the cvs info if you're not going to use it as a cvs tree. -Eric > patch-2.4.x-xfs-cvs-.bz2 > CVS seed patch: patch a vanilla linux 2.4.x tree to a "cvs update -d" > capable tree. The resulting tree includes all kernel and userspace > code for XFS. Do not use this patch unless you are willing stay > up-to-date with "current". > > patch-2.4.x-xfs-.bz2 > Patches to take a vanilla linux 2.4.x tree to an xfs capable > kernel. Note that these are kernel only patches, command > source can be obtained from the cmd_tars directory. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 14 20:10:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F3AlB31455 for linux-xfs-outgoing; Tue, 14 Aug 2001 20:10:47 -0700 Received: from zero.aec.at (qmailr@zero.aec.at [195.3.98.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F3Ajj31436 for ; Tue, 14 Aug 2001 20:10:45 -0700 Received: (qmail 7564 invoked by uid 99); 15 Aug 2001 03:10:41 -0000 Received: from unknown (HELO fred.muc.de) (unknown) by unknown with SMTP; 15 Aug 2001 03:10:41 -0000 Received: by fred.muc.de (Postfix, from userid 500) id 58FC7E2D53; Wed, 15 Aug 2001 05:11:28 +0200 (CEST) Date: Wed, 15 Aug 2001 05:11:28 +0200 From: Andi Kleen To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: re: XFS memory hardening Message-ID: <20010815051128.A9849@fred.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, In reply to your reply to my XFS memory hardening patch. Work email is unfortunately down, so this way. > The problem with the code which does some > xfs memory allocation failure detection is that you can never get to > all of them, this is why I have never checked in the stuff about > seeing a NULL and doing an error return. There are also places in xfs > where failure is not an option - once a transaction has dirtied > metadata there is no turning back. So really the only option which will > fly long term is making sure memory allocations do not return failure > when they get back up to xfs proper. I do have some other ideas it is > just a matter of finding the time. Most of my patch satisfies that. The kmem changes especially do not return until success, even though that could mean deadlock on OOM. The only place in the patch where a transaction could be potentially dirtied and a new ENOMEM is added is in xfs_trans_read_buf(). There I still think it's better to return the error than to oops in the caller on a NULL pointer. Also this function definitely can return other errors instead (EIO) so the callers should handle it (or they have a different bug) The other places either involve no transactions or just extend existing error paths. -Andi From owner-linux-xfs@oss.sgi.com Tue Aug 14 20:27:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F3RiT31879 for linux-xfs-outgoing; Tue, 14 Aug 2001 20:27:44 -0700 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 f7F3Rfj31860 for ; Tue, 14 Aug 2001 20:27:41 -0700 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 f7F3WRS12902 for ; Tue, 14 Aug 2001 20:32:27 -0700 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 WAA2653516; Tue, 14 Aug 2001 22:26:19 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA54381; Tue, 14 Aug 2001 22:26:19 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7F3OmN23615; Tue, 14 Aug 2001 22:24:48 -0500 Message-Id: <200108150324.f7F3OmN23615@jen.americas.sgi.com> To: Andi Kleen cc: lord@sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS memory hardening References: <20010815051128.A9849@fred.local> Comments: In-reply-to Andi Kleen message dated "Wed, 15 Aug 2001 05:11:28 +0200." Date: Tue, 14 Aug 2001 22:24:48 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Hi Steve, > > In reply to your reply to my XFS memory hardening patch. Work email is > unfortunately down, so this way. hey, we had no phones today at work, just a hydrogen sulphide smell which they assured us was at an extremely low and safe concentration! > > > The problem with the code which does some > > xfs memory allocation failure detection is that you can never get to > > all of them, this is why I have never checked in the stuff about > > seeing a NULL and doing an error return. There are also places in xfs > > where failure is not an option - once a transaction has dirtied > > metadata there is no turning back. So really the only option which will > > fly long term is making sure memory allocations do not return failure > > when they get back up to xfs proper. I do have some other ideas it is > > just a matter of finding the time. > > Most of my patch satisfies that. The kmem changes especially do not return > until success, even though that could mean deadlock on OOM. > > The only place in the patch where a transaction could be potentially > dirtied and a new ENOMEM is added is in xfs_trans_read_buf(). There I still > think it's better to return the error than to oops in the caller on a NULL > pointer. Also this function definitely can return other errors instead > (EIO) so the callers should handle it (or they have a different bug) Yes the readbuf case is a little different, I think the issue here is that pagebuf cannot get any memory - either pages for the data, or buffer heads to read them with. An emergency pool of buffer heads in the pagebuf code may help with one part of this - a similar approach to md and friends. The odd thing is I can run without your code under some fairly high stress loads without hitting these end cases, how much memory do you test with in general? Steve From owner-linux-xfs@oss.sgi.com Tue Aug 14 20:40:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F3eVq32244 for linux-xfs-outgoing; Tue, 14 Aug 2001 20:40:31 -0700 Received: from colin.muc.de (root@colin.muc.de [193.149.48.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F3eSj32225 for ; Tue, 14 Aug 2001 20:40:28 -0700 Received: by colin.muc.de id <140566-2>; Wed, 15 Aug 2001 05:40:21 +0200 Message-ID: <20010815054020.39520@colin.muc.de> Date: Wed, 15 Aug 2001 05:40:20 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: XFS memory hardening References: <20010815051128.A9849@fred.local> <200108150324.f7F3OmN23615@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <200108150324.f7F3OmN23615@jen.americas.sgi.com>; from Steve Lord on Wed, Aug 15, 2001 at 05:24:48AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 15, 2001 at 05:24:48AM +0200, Steve Lord wrote: > > > > Hi Steve, > > > > In reply to your reply to my XFS memory hardening patch. Work email is > > unfortunately down, so this way. > > hey, we had no phones today at work, just a hydrogen sulphide smell > which they assured us was at an extremely low and safe concentration! Ugh. Doesn't sound good. > > > > > > The problem with the code which does some > > > xfs memory allocation failure detection is that you can never get to > > > all of them, this is why I have never checked in the stuff about > > > seeing a NULL and doing an error return. There are also places in xfs > > > where failure is not an option - once a transaction has dirtied > > > metadata there is no turning back. So really the only option which will > > > fly long term is making sure memory allocations do not return failure > > > when they get back up to xfs proper. I do have some other ideas it is > > > just a matter of finding the time. > > > > Most of my patch satisfies that. The kmem changes especially do not return > > until success, even though that could mean deadlock on OOM. > > > > The only place in the patch where a transaction could be potentially > > dirtied and a new ENOMEM is added is in xfs_trans_read_buf(). There I still > > think it's better to return the error than to oops in the caller on a NULL > > pointer. Also this function definitely can return other errors instead > > (EIO) so the callers should handle it (or they have a different bug) > > Yes the readbuf case is a little different, I think the issue here is > that pagebuf cannot get any memory - either pages for the data, or > buffer heads to read them with. An emergency pool of buffer heads in > the pagebuf code may help with one part of this - a similar approach > to md and friends. Just needs to be very careful that all other users block, and do not hold any locks that would prevent any of the blockers to succeed while doing that. Frankly I don't know enough about XFS lock hierarchies to attempt that. > > > The odd thing is I can run without your code under some fairly high > stress loads without hitting these end cases, how much memory do you > test with in general? I mostly hit these because I had a page cache leak, and until that one was found I had plenty of possibility to exercise OOM and do these patches. On a 512MB machine now I also don't get any OOM with "normal" load. -Andi From owner-linux-xfs@oss.sgi.com Tue Aug 14 23:27:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F6Rbd02619 for linux-xfs-outgoing; Tue, 14 Aug 2001 23:27:37 -0700 Received: from pipe.aspec.ru (nobody@relay1.aspec.ru [217.14.198.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F6RXj02594 for ; Tue, 14 Aug 2001 23:27:34 -0700 Received: from p100.p100.belkam.com (p100.p100.belkam.com [192.168.21.122]) by pipe.aspec.ru (8.11.1/8.11.1) with ESMTP id f7F6RUv28664 for ; Wed, 15 Aug 2001 11:27:30 +0500 (SAMST) Received: from belkam.com ([192.168.22.111]) by p100.p100.belkam.com (8.9.3/8.9.3) with ESMTP id LAA21249 for ; Wed, 15 Aug 2001 11:27:30 +0500 Message-ID: <3B7A94DF.63F47A6B@belkam.com> Date: Wed, 15 Aug 2001 11:27:27 -0400 From: Dmitry Melekhov X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.7-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: setfacl problem Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello! I just downloaded new acl package - 1.1.2 But I can't change acl with setfacl. [root@dm 121212]# getfacl 1111 # file: 1111 # owner: dm # group: dm user::rwx group::r-x other::r-x user:dm:rwx mask::rwx default:user::rwx default:group::rwx default:other::rwx default:user:dm:rwx default:mask::rwx Now I'm trying to remove default acl for user dm: [root@dm 121212]# setfacl -d -x u:dm 1111 setfacl: 1111: Resulting default ACL `user::rwx,group::rwx,other::rwx,mask::rwx': Missing or wrong entry at entry 4 What mean this error? I can't understand :( Certanly, there is no changes in acl. From owner-linux-xfs@oss.sgi.com Tue Aug 14 23:38:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F6csJ02884 for linux-xfs-outgoing; Tue, 14 Aug 2001 23:38:54 -0700 Received: from ente.berdmann.de (frnk-d5141ada.dsl.mediaWays.net [213.20.26.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F6cqj02865 for ; Tue, 14 Aug 2001 23:38:52 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15WuKE-0003mj-00 for linux-xfs@oss.sgi.com; Wed, 15 Aug 2001 08:38:46 +0200 Message-ID: <3B7A18F6.D655FE3F@berdmann.de> Date: Wed, 15 Aug 2001 08:38:46 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: " Linux XFS (E-mail)" Subject: Re: mounts sometimes take forever References: <23D04BDBA646D411BDDD00D0B774B5390460255A@SA-BWMAIL1> <20010815110651.E302907@wobbly.melbourne.sgi.com> <3B79CF49.FECF1552@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > All this is actually easier if you set up a serial console (well, easier > to capture the output). How do you fire up a serial console? From owner-linux-xfs@oss.sgi.com Tue Aug 14 23:43:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F6hBx03062 for linux-xfs-outgoing; Tue, 14 Aug 2001 23:43:11 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F6h9j03043 for ; Tue, 14 Aug 2001 23:43:09 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA22284 for ; Tue, 14 Aug 2001 23:42:52 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21586; Wed, 15 Aug 2001 16:41:50 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA96743; Wed, 15 Aug 2001 16:41:49 +1000 (AEST) Date: Wed, 15 Aug 2001 16:41:48 +1000 From: Nathan Scott To: Dmitry Melekhov Cc: linux-xfs@oss.sgi.com Subject: Re: setfacl problem Message-ID: <20010815164148.J302907@wobbly.melbourne.sgi.com> References: <3B7A94DF.63F47A6B@belkam.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7A94DF.63F47A6B@belkam.com>; from dm@belkam.com on Wed, Aug 15, 2001 at 11:27:27AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Aug 15, 2001 at 11:27:27AM -0400, Dmitry Melekhov wrote: > Hello! > > [root@dm 121212]# setfacl -d -x u:dm 1111 > setfacl: 1111: Resulting default ACL > `user::rwx,group::rwx,other::rwx,mask::rwx': Missing or wrong entry at > entry 4 > > What mean this error? > > I can't understand :( > In reply to your initial question, I wrote (and I quote): "[...] getfacl/setfacl [...] were designed for just this purpose. There is a known ACE ordering bug in the libacl code that this sits above though, so YMMV at the moment. Feel free to fix the problem, its just not reached the top of anyone's ToDo list here at the moment." So if you are not prepared to fix or work around this bug yourself, don't use getfacl/setfacl with XFS yet. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 14 23:45:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F6j1N03200 for linux-xfs-outgoing; Tue, 14 Aug 2001 23:45:01 -0700 Received: from pipe.aspec.ru (nobody@relay1.aspec.ru [217.14.198.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F6iwj03168 for ; Tue, 14 Aug 2001 23:44:59 -0700 Received: from p100.p100.belkam.com (p100.p100.belkam.com [192.168.21.122]) by pipe.aspec.ru (8.11.1/8.11.1) with ESMTP id f7F6iuv29175; Wed, 15 Aug 2001 11:44:56 +0500 (SAMST) Received: from belkam.com ([192.168.22.111]) by p100.p100.belkam.com (8.9.3/8.9.3) with ESMTP id LAA22951; Wed, 15 Aug 2001 11:44:55 +0500 Message-ID: <3B7A98F5.8F34C8C0@belkam.com> Date: Wed, 15 Aug 2001 11:44:53 -0400 From: Dmitry Melekhov X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.7-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: setfacl problem References: <3B7A94DF.63F47A6B@belkam.com> <20010815164148.J302907@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott wrote: > hi, > > On Wed, Aug 15, 2001 at 11:27:27AM -0400, Dmitry Melekhov wrote: > > Hello! > > > > [root@dm 121212]# setfacl -d -x u:dm 1111 > > setfacl: 1111: Resulting default ACL > > `user::rwx,group::rwx,other::rwx,mask::rwx': Missing or wrong entry at > > entry 4 > > > > What mean this error? > > > > I can't understand :( > > > > In reply to your initial question, I wrote (and I quote): > > "[...] getfacl/setfacl [...] were designed for just this > purpose. There is a known ACE ordering bug in the libacl code > that this sits above though, so YMMV at the moment. Feel free > to fix the problem, its just not reached the top of anyone's > ToDo list here at the moment." > > So if you are not prepared to fix or work around this bug yourself, > don't use getfacl/setfacl with XFS yet. > Oops! , sorry, I forgot about this :( Thank you! From owner-linux-xfs@oss.sgi.com Wed Aug 15 00:22:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F7MtI03837 for linux-xfs-outgoing; Wed, 15 Aug 2001 00:22:55 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F7Mrj03818 for ; Wed, 15 Aug 2001 00:22:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id AAA06452 for ; Wed, 15 Aug 2001 00:20:54 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA21749; Wed, 15 Aug 2001 17:21:32 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Bernhard R. Erdmann" cc: " Linux XFS (E-mail)" Subject: Re: mounts sometimes take forever In-reply-to: Your message of "Wed, 15 Aug 2001 08:38:46 +0200." <3B7A18F6.D655FE3F@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2001 17:21:32 +1000 Message-ID: <3213.997860092@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 15 Aug 2001 08:38:46 +0200, "Bernhard R. Erdmann" wrote: >> All this is actually easier if you set up a serial console (well, easier >> to capture the output). > >How do you fire up a serial console? linux/Documentation/serial-console.txt From owner-linux-xfs@oss.sgi.com Wed Aug 15 00:44:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F7iHE04286 for linux-xfs-outgoing; Wed, 15 Aug 2001 00:44:17 -0700 Received: from musique.teaser.fr (musique.teaser.net [213.91.2.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F7iDj04267 for ; Wed, 15 Aug 2001 00:44:13 -0700 Received: from lucas.loria (d32-210.ppp.teaser.fr [213.91.32.210]) by musique.teaser.fr (Postfix) with ESMTP id F2B477250C; Wed, 15 Aug 2001 09:44:10 +0200 (CEST) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id 3EAFFA5E3; Wed, 15 Aug 2001 09:48:27 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id C08535F8B5; Wed, 15 Aug 2001 09:48:25 +0200 (CEST) To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: New tarball error References: <000001c1242c$b968d220$650aa8c0@vauntmure.com> <20010815114548.G302907@wobbly.melbourne.sgi.com> X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E In-Reply-To: <20010815114548.G302907@wobbly.melbourne.sgi.com> From: Vincent Bernat Date: 15 Aug 2001 09:48:25 +0200 Message-ID: Lines: 77 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) 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 OoO En ce milieu de nuit étoilée du mercredi 15 août 2001, vers 03:45, Nathan Scott disait: >> I have just compiled latest tarballs and found some glitches (I have >> never compiled earlier tarballs, so it may be "normal") : >> - in my system, libtool is >> /usr/local/libexec/rep/i686-pc-linux-gnu/libtool and not >> /usr/bin/libtool. I have never seen any program who have complained >> about this. > That's a strange place for libtool. I have checked only > Debian and Redhat, but they both install it in /usr/bin. I have a SuSE (6.2, 6.3 or 6.4, I can't remember) and I think it is the default place since I didn't recompiled libtool. > I think /usr/bin is also only a backup if it can't be found > on your path, this is from configure.in: > dnl ensure libtool is installed > AC_PATH_PROG(LIBTOOL, libtool,,/usr/bin) > if test "$LIBTOOL" = ""; then > echo > echo 'FATAL ERROR: libtool does not seem to be installed.' > echo $pkg_name cannot be built without a working libtool installation. > exit 1 > fi > libtool=$LIBTOOL > AC_SUBST(libtool) > Is this the error you're running into? The fourth parameter > should be just a fallback path in case its not found anywhere > else, IIRC. Since I thought that I didn't have libtool, I have downloaded it, compiled and installed. It has ended in /usr/local/bin. I have types "rehash" and relaunched configure and got the same error. Then, I have checked the script and make a symlink to help him find it. If I remove the symlink, I get : neo bernat/xfsprogs-1.3.4> which libtool /usr/local/bin/libtool neo bernat/xfsprogs-1.3.4> ./configure creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for make... /usr/bin/make checking for ld... /usr/bin/ld checking for tar... /bin/tar checking for gzip... /usr/bin/gzip checking for rpm... /bin/rpm checking for makedepend... /usr/X11R6/bin/makedepend checking whether ln -s works... yes checking for awk... /usr/bin/awk checking for sed... /usr/bin/sed checking for echo... /bin/echo checking for libtool... no FATAL ERROR: libtool does not seem to be installed. xfsprogs cannot be built without a working libtool installation. neo bernat/xfsprogs-1.3.4> libtool --version ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18) > Files required by system software using the Data Management API > (DMAPI). This is used to implement the interface defined in the > X/Open document: Systems Management: Data Storage Managment > (XDSM) API dated February 1997. This interface is implemented > by the libdm library. OK, but for a end user, it is useful ? Or in other words, is it useful just for certain programs (databases ?) which will then explicitely use it (and so, there is no advantage to use dmapi without one of these programs) ? From owner-linux-xfs@oss.sgi.com Wed Aug 15 04:02:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FB2G714255 for linux-xfs-outgoing; Wed, 15 Aug 2001 04:02:16 -0700 Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FB2Dj14216 for ; Wed, 15 Aug 2001 04:02:13 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 15WyR7-0004Ap-0V for linux-xfs@oss.sgi.com; Wed, 15 Aug 2001 12:02:10 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 6D8CA27F0 for ; Wed, 15 Aug 2001 08:56:18 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id 1FD32125E6; Wed, 15 Aug 2001 08:56:18 +0100 (BST) Date: Wed, 15 Aug 2001 08:56:18 +0100 (BST) From: Keith Matthews Subject: Re[2]: XFS memory hardening To: linux-xfs@oss.sgi.com In-Reply-To: <200108150324.f7F3OmN23615@jen.americas.sgi.com> References: <20010815051128.A9849@fred.local>, <200108150324.f7F3OmN23615@jen.americas.sgi.com> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010815075618.1FD32125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f7FB2Ej14222 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 14 Aug 2001 22:24:48 -0500 Steve Lord > wrote: > hey, we had no phones today at work, just a hydrogen sulphide smell > which they assured us was at an extremely low and safe concentration! OT but, I'm told by experts in the field that its just objectionable until it starts to smell sweet. Then you need to get the hell out of there. -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Wed Aug 15 04:58:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FBwMl30075 for linux-xfs-outgoing; Wed, 15 Aug 2001 04:58:22 -0700 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 f7FBwKj30047 for ; Wed, 15 Aug 2001 04:58:20 -0700 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 f7FC36S24410 for ; Wed, 15 Aug 2001 05:03:06 -0700 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 GAA2716186 for ; Wed, 15 Aug 2001 06:56:58 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA74913 for ; Wed, 15 Aug 2001 06:56:58 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f7FBtOJ24478; Wed, 15 Aug 2001 06:55:24 -0500 Message-Id: <200108151155.f7FBtOJ24478@jen.americas.sgi.com> Date: Wed, 15 Aug 2001 06:55:24 -0500 Subject: TAKE - Fix ABBA deadlock, the better version Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, lets try that again, I fixed the deadlock first time around, but I did introduce a race. This code has hit the spot where the race was (6 times in over 1 million attempts) and survived. Now lets see if we can catch up with Linus..... Date: Wed Aug 15 04:55:01 PDT 2001 Workarea: 128.162.187.49:/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:100792a linux/fs/xfs/xfs_vnodeops.c - 1.509 - Second attempt at ABBA deadlock fix between inode and inode hash lock, this time without introducing a race between inode lookup and teardown. From owner-linux-xfs@oss.sgi.com Wed Aug 15 05:32:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FCWgf06183 for linux-xfs-outgoing; Wed, 15 Aug 2001 05:32:42 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FCWbj06142 for ; Wed, 15 Aug 2001 05:32:38 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 2C06BC00FB9 for ; Wed, 15 Aug 2001 20:32:29 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 79511C00AC1 for ; Wed, 15 Aug 2001 20:32:27 +0800 (PHT) Date: Wed, 15 Aug 2001 20:32:27 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: TAKE - Fix ABBA deadlock, the better version In-Reply-To: <200108151155.f7FBtOJ24478@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 On Wed, 15 Aug 2001 at 06:55, Steve Lord wrote: > OK, lets try that again, I fixed the deadlock first time around, but I > did introduce a race. This code has hit the spot where the race was (6 > times in over 1 million attempts) and survived. Now lets see if we can > catch up with Linus..... Go go go Steve!!! Great work keeping the CVS tree working, and up-to-date with Linus's. I'm sure that's one hell of a job. Hopefully XFS will get merged with the main tree sometime in the near future. That should lessen these oh-so-great VM changes that give you guys such a hard time syncing. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Wed Aug 15 06:05:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FD5hh15124 for linux-xfs-outgoing; Wed, 15 Aug 2001 06:05:43 -0700 Received: from mplspop6.mpls.uswest.net (mplspop6.mpls.uswest.net [204.147.80.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FD5fj15095 for ; Wed, 15 Aug 2001 06:05:41 -0700 Received: (qmail 47969 invoked from network); 15 Aug 2001 13:05:40 -0000 Received: from mplsdslgw14poola24.mpls.uswest.net (HELO beaver.iucha.org) (63.229.192.24) by mplspop6.mpls.uswest.net with SMTP; 15 Aug 2001 13:05:40 -0000 Received: (from florin@localhost) by beaver.iucha.org (8.11.3/8.11.3) id f7FD5cW24855 for linux-xfs@oss.sgi.com; Wed, 15 Aug 2001 08:05:38 -0500 (CDT) Date: Wed, 15 Aug 2001 08:05:37 -0500 Message-ID: <20010815080537.A21347@beaver.iucha.org> From: "Florin Iucha" To: linux-xfs@oss.sgi.com Subject: Re: oops with 2.4.8-xfs 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 got the oops too. I have a cron backup script that runs at 4 am and used to make a tar archive of a reiserfs directory. Last Sunday I converted the partition to xfs and the script to use tar. What is interesting is the fact that if I run the script from the interactive session it works fine; it crashes only when run from the cron. I am using 2.4.8-xfs with xfsdump-1.0.9 xfsprogs-1.3.4-0 from Debian unstable/testing on a _dual_ P90. florin -- "If it's not broken, is because you are not fixing it enough." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4 From owner-linux-xfs@oss.sgi.com Wed Aug 15 06:41:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FDfCd24984 for linux-xfs-outgoing; Wed, 15 Aug 2001 06:41:12 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FDfAj24956 for ; Wed, 15 Aug 2001 06:41:10 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA01538 for ; Wed, 15 Aug 2001 06:39:09 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2714400; Wed, 15 Aug 2001 08:39:51 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA20773; Wed, 15 Aug 2001 08:39:51 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7FDcFA32694; Wed, 15 Aug 2001 08:38:15 -0500 Message-Id: <200108151338.f7FDcFA32694@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Florin Iucha" cc: linux-xfs@oss.sgi.com Subject: Re: oops with 2.4.8-xfs In-Reply-To: Message from "Florin Iucha" of "Wed, 15 Aug 2001 08:05:37 CDT." <20010815080537.A21347@beaver.iucha.org> Date: Wed, 15 Aug 2001 08:38:15 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I have got the oops too. > > I have a cron backup script that runs at 4 am and used to make a tar archive > of > a reiserfs directory. Last Sunday I converted the partition to xfs and the > script to use tar. > > What is interesting is the fact that if I run the script from the interactive > session it works fine; it crashes only when run from the cron. > > I am using 2.4.8-xfs with > xfsdump-1.0.9 > xfsprogs-1.3.4-0 > from Debian unstable/testing on a _dual_ P90. I just placed new patches on oss for 2.4.8, can you possibly try these, there were at least a couple of bugs which needed working out of the original 2.4.8 checkin. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 15 07:51:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FEpMR10435 for linux-xfs-outgoing; Wed, 15 Aug 2001 07:51:22 -0700 Received: from ntown.esper.com (root@ntown.esper.com [216.111.16.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FEpJj10399 for ; Wed, 15 Aug 2001 07:51:19 -0700 Received: from kjcwin2k (kcross.ntown.esper.com [216.111.19.212]) by ntown.esper.com (8.11.4/8.11.4) with SMTP id f7FEvcE16952 for ; Wed, 15 Aug 2001 10:57:38 -0400 Message-ID: <002101c12599$bd9afe40$0200a8c0@kjc2.com> From: "Ken Cross" To: "Linux XFS" Subject: SPEC failures Date: Wed, 15 Aug 2001 10:51:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been trying to run SPEC sfs tests, but during validation it fails with: validating create file file_en.00000 ... file_en.00000: create attribute mismatch mode: returned = 100644, specified = 100666 validating create file file_en.00001 ... file_en.00001: create attribute mismatch mode: returned = 100644, specified = 100666 Later on in the validation pass, I get: validating setattr file_en.00000 ... file_en.00000: setattr attribute mismatch mode: returned = 100666, specified = 100644 validating setattr file_en.00001 ... file_en.00001: setattr attribute mismatch mode: returned = 100666, specified = 100644 This is on a system with the latest (8/15/01) CVS code, using egcs 1.1.2. It works fine using chmod manually, but SPEC sfs fails very consistently with different clients and different hosts. It does *not* fail with the Linux-XFS 1.0.1 ISO image. Any ideas? Thanks, Ken From owner-linux-xfs@oss.sgi.com Wed Aug 15 07:59:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FExj512598 for linux-xfs-outgoing; Wed, 15 Aug 2001 07:59:45 -0700 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 f7FExhj12577 for ; Wed, 15 Aug 2001 07:59:43 -0700 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 f7FF4TS32140 for ; Wed, 15 Aug 2001 08:04:29 -0700 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 JAA2719283; Wed, 15 Aug 2001 09:58:20 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA17311; Wed, 15 Aug 2001 09:58:20 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7FEuid00491; Wed, 15 Aug 2001 09:56:44 -0500 Message-Id: <200108151456.f7FEuid00491@jen.americas.sgi.com> To: "Ken Cross" cc: "Linux XFS" Subject: Re: SPEC failures References: <002101c12599$bd9afe40$0200a8c0@kjc2.com> Comments: In-reply-to "Ken Cross" message dated "Wed, 15 Aug 2001 10:51:17 -0400." Date: Wed, 15 Aug 2001 09:56:44 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I've been trying to run SPEC sfs tests, but during validation it fails with: > > validating create file file_en.00000 ... > file_en.00000: create attribute mismatch > mode: returned = 100644, specified = 100666 > > validating create file file_en.00001 ... > file_en.00001: create attribute mismatch > mode: returned = 100644, specified = 100666 > > Later on in the validation pass, I get: > > validating setattr file_en.00000 ... > file_en.00000: setattr attribute mismatch > mode: returned = 100666, specified = 100644 > > validating setattr file_en.00001 ... > file_en.00001: setattr attribute mismatch > mode: returned = 100666, specified = 100644 > > > This is on a system with the latest (8/15/01) CVS code, using egcs 1.1.2. > It works fine using chmod manually, but SPEC sfs fails very consistently > with different clients and different hosts. > > It does *not* fail with the Linux-XFS 1.0.1 ISO image. > > Any ideas? > > Thanks, > Ken > Yes, Andrew Tridgell hit the same thing, this has to do with the code added to xfs for posix acl support and when we do and do not apply the process umask to file create permissions. When and how these masks are applied in the main kernel has changed since the 1.0.1 release. Our problem right now is we need a way in the create code in xfs to tell we are being called from NFS, and apart from looking at the name of the running process I don't have a way of doing this. So basically the status is : broken until someone has a brainwave on how to detect a create/mkdir/mknod from nfs neatly. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 15 08:09:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FF9Sw15177 for linux-xfs-outgoing; Wed, 15 Aug 2001 08:09:28 -0700 Received: from sina.com ([202.108.35.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FF9Pj15133 for ; Wed, 15 Aug 2001 08:09:25 -0700 Received: (qmail 25402 invoked by uid 99); 15 Aug 2001 15:06:53 -0000 Message-ID: <20010815150653.25401.qmail@sina.com> From: Tang Lingbo To: linux-xfs@oss.sgi.com Subject: error in xfs_logprint? Date: Wed, 15 Aug 2001 23:06:52 +0800 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, There was a core dump in xfs_logprint when I did as follows: 1)$ dd if=/dev/zero of=/tmp/xfs bs=1024 count=50000 2)$ mkfs.xfs /tmp/xfs 3)$ mount -t xfs -o loop /tmp/xfs /xfs 4)$ touch /xfs/test 5)$ for((i=0;i<1024;i++));do echo -n 1 >> /tmp/dummy;done 6)$ value=`cat /tmp/dummy`;attr -s test -V $value /xfs/test 7)$ xfs_logprint /tmp/xfs output: ... xlog_print_trans_inode: illegal inode type And I think the patch will be as follows: --- logprint/log_misc.c Wed Aug 15 22:57:18 2001 +++ logprint/log_misc.c.new Wed Aug 15 23:00:14 2001 @@ -714,6 +714,41 @@ printf("UUID inode: no extra region\n"); break; } + case XFS_ILOG_AEXT: { + ASSERT(f->ilf_size == 3); + (*i)++; + xlog_print_op_header(op_head, *i, ptr); + printf("EXTENTS inode attr\n"); + *ptr += INT_GET(op_head->oh_len, ARCH_CONVERT); + if (XLOG_SET(op_head->oh_flags, XLOG_CONTINUE_TRANS)) { + return 1; + } + break; + } + case XFS_ILOG_ABROOT: { + ASSERT(f->ilf_size == 3); + (*i)++; + xlog_print_op_header(op_head, *i, ptr); + printf("BTREE inode attr\n"); + *ptr += INT_GET(op_head->oh_len, ARCH_CONVERT); + if (XLOG_SET(op_head->oh_flags, XLOG_CONTINUE_TRANS)) { + return 1; + } + break; + } + case XFS_ILOG_ADATA: { + ASSERT(f->ilf_size == 3); + (*i)++; + xlog_print_op_header(op_head, *i, ptr); + printf("LOCAL inode attr\n"); + if (mode == IFDIR) { + xlog_print_dir_sf((xfs_dir_shortform_t*)*ptr, size); + } + *ptr += INT_GET(op_head->oh_len, ARCH_CONVERT); + if (XLOG_SET(op_head->oh_flags, XLOG_CONTINUE_TRANS)) + return 1; + break; + } case 0: { ASSERT(f->ilf_size == 2); break; Any comments? Best regards, Tang Lingbo ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) ¶©ÔÄÊÖ»ú¶ÌÐÅÍ·ÌõÐÂÎÅ£¬ÌìÌ윱¶à¿îʱÉÐÊÖ»ú£¡ (http://dailynews.sina.com.cn/c/272235.html) ÏëÈÃ100ÍòÄ°ÉúÈËͬʱ°®ÉÏÄãÃŽ?ÀŽÕÒÎÒ°É! (http://cheese.sina.com.cn) From owner-linux-xfs@oss.sgi.com Wed Aug 15 08:09:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FF9Ln15085 for linux-xfs-outgoing; Wed, 15 Aug 2001 08:09:21 -0700 Received: from ntown.esper.com (root@ntown.esper.com [216.111.16.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FF9Hj15045 for ; Wed, 15 Aug 2001 08:09:18 -0700 Received: from kjcwin2k (kcross.ntown.esper.com [216.111.19.212]) by ntown.esper.com (8.11.4/8.11.4) with SMTP id f7FFFUE18321; Wed, 15 Aug 2001 11:15:30 -0400 Message-ID: <002f01c1259c$3cb3b260$0200a8c0@kjc2.com> From: "Ken Cross" To: "Steve Lord" Cc: "Linux XFS" References: <002101c12599$bd9afe40$0200a8c0@kjc2.com> <200108151456.f7FEuid00491@jen.americas.sgi.com> Subject: Re: SPEC failures Date: Wed, 15 Aug 2001 11:09:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for the quick response, Steve. I'd be happy to tackle the problem if you have an idea which module(s) changed. Maybe nfsd would have more luck detecting XFS than the other way around. Ken ----- Original Message ----- From: "Steve Lord" To: "Ken Cross" Cc: "Linux XFS" Sent: Wednesday, August 15, 2001 10:56 AM Subject: Re: SPEC failures > > I've been trying to run SPEC sfs tests, but during validation it fails with: > > > > validating create file file_en.00000 ... > > file_en.00000: create attribute mismatch > > mode: returned = 100644, specified = 100666 > > > > validating create file file_en.00001 ... > > file_en.00001: create attribute mismatch > > mode: returned = 100644, specified = 100666 > > > > Later on in the validation pass, I get: > > > > validating setattr file_en.00000 ... > > file_en.00000: setattr attribute mismatch > > mode: returned = 100666, specified = 100644 > > > > validating setattr file_en.00001 ... > > file_en.00001: setattr attribute mismatch > > mode: returned = 100666, specified = 100644 > > > > > > This is on a system with the latest (8/15/01) CVS code, using egcs 1.1.2. > > It works fine using chmod manually, but SPEC sfs fails very consistently > > with different clients and different hosts. > > > > It does *not* fail with the Linux-XFS 1.0.1 ISO image. > > > > Any ideas? > > > > Thanks, > > Ken > > > > Yes, Andrew Tridgell hit the same thing, this has to do with the code > added to xfs for posix acl support and when we do and do not apply > the process umask to file create permissions. When and how these > masks are applied in the main kernel has changed since the 1.0.1 > release. > > Our problem right now is we need a way in the create code in xfs to > tell we are being called from NFS, and apart from looking at the > name of the running process I don't have a way of doing this. > > So basically the status is : broken until someone has a brainwave > on how to detect a create/mkdir/mknod from nfs neatly. > > Steve From owner-linux-xfs@oss.sgi.com Wed Aug 15 08:28:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FFSqY20434 for linux-xfs-outgoing; Wed, 15 Aug 2001 08:28:52 -0700 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 f7FFSWj20332 for ; Wed, 15 Aug 2001 08:28:32 -0700 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 f7FFYMW02537 for ; Wed, 15 Aug 2001 08:34:22 -0700 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 KAA2711320 for ; Wed, 15 Aug 2001 10:27:11 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA89410 for ; Wed, 15 Aug 2001 10:27:11 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f7FFPZM00654; Wed, 15 Aug 2001 10:25:35 -0500 Message-Id: <200108151525.f7FFPZM00654@jen.americas.sgi.com> Date: Wed, 15 Aug 2001 10:25:35 -0500 Subject: TAKE - merge up to 2.4.9-pre4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You turn your back for a couple of days, and what happens? 707 files get changed, thats what! This has had some reasonable stress applied and seems to be behaving. 2.4.8 will continue to be available via patch on the ftp site. Date: Wed Aug 15 08:20:11 PDT 2001 Workarea: 128.162.187.49:/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:100796a linux/include/asm-arm/arch-sa1100/jornada720.h - 1.1 linux/drivers/net/irda/vlsi_ir.c - 1.1 linux/include/asm-arm/arch-sa1100/lart.h - 1.1 linux/drivers/net/wan/farsync.c - 1.1 linux/drivers/net/wan/farsync.h - 1.1 linux/drivers/scsi/cpqfcTStrigger.h - 1.1 linux/drivers/sound/btaudio.c - 1.1 linux/include/asm-arm/arch-sa1100/omnimeter.h - 1.1 linux/include/asm-arm/arch-sa1100/pfs168.h - 1.1 linux/include/asm-arm/arch-sa1100/pleb.h - 1.1 linux/drivers/sound/rme96xx.c - 1.1 linux/drivers/sound/rme96xx.h - 1.1 linux/drivers/usb/CDCEther.c - 1.1 linux/drivers/usb/CDCEther.h - 1.1 linux/drivers/usb/kaweth.c - 1.1 linux/drivers/ieee1394/ieee1394_hotplug.h - 1.1 linux/drivers/usb/kawethfw.h - 1.1 linux/drivers/video/sa1100fb.h - 1.1 linux/include/asm-arm/arch-sa1100/simpad.h - 1.1 linux/drivers/ide/serverworks.c - 1.1 linux/drivers/ide/it8172.c - 1.1 linux/arch/alpha/kernel/srm_env.c - 1.1 linux/drivers/ide/ide-adma.c - 1.1 linux/drivers/ide/amd74xx.c - 1.1 linux/include/asm-arm/arch-anakin/dma.h - 1.1 linux/include/asm-arm/arch-sa1100/yopy.h - 1.1 linux/include/asm-arm/arch-anakin/hardware.h - 1.1 linux/drivers/acorn/char/defkeymap-l7200.c - 1.1 linux/drivers/acorn/char/defkeymap-acorn.map - 1.1 linux/include/asm-arm/arch-sa1100/itsy.h - 1.1 linux/include/asm-arm/arch-anakin/ide.h - 1.1 linux/arch/arm/def-configs/anakin - 1.1 linux/include/asm-arm/arch-sa1100/huw_webpanel.h - 1.1 linux/arch/arm/def-configs/bitsy - 1.1 linux/include/asm-arm/arch-sa1100/freebird.h - 1.1 linux/include/asm-arm/arch-sa1100/flexanet.h - 1.1 linux/arch/arm/def-configs/flexanet - 1.1 linux/arch/arm/def-configs/freebird - 1.1 linux/arch/arm/def-configs/freebird_new - 1.1 linux/include/net/irda/vlsi_ir.h - 1.1 linux/arch/arm/def-configs/h3600 - 1.1 linux/arch/arm/def-configs/huw_webpanel - 1.1 linux/arch/arm/mm/discontig.c - 1.1 linux/arch/arm/def-configs/jornada720 - 1.1 linux/arch/arm/mach-sa1100/yopy.c - 1.1 linux/arch/arm/mach-sa1100/xp860.c - 1.1 linux/arch/arm/def-configs/omnimeter - 1.1 linux/arch/arm/mach-sa1100/victor.c - 1.1 linux/arch/arm/def-configs/pfs168_mqtft - 1.1 linux/arch/arm/def-configs/pfs168_mqvga - 1.1 linux/arch/arm/def-configs/pfs168_sastn - 1.1 linux/arch/arm/def-configs/pfs168_satft - 1.1 linux/arch/arm/def-configs/pleb - 1.1 linux/arch/arm/mach-sa1100/simpad.c - 1.1 linux/arch/arm/mach-sa1100/sherman.c - 1.1 linux/arch/arm/mach-sa1100/sa1111.h - 1.1 linux/arch/s390x/vmlinux-shared.lds - 1.1 linux/arch/arm/mach-sa1100/sa1111.c - 1.1 linux/include/asm-arm/arch-anakin/io.h - 1.1 linux/arch/arm/mach-sa1100/sa1111-pcibuf.c - 1.1 linux/arch/arm/kernel/compat.c - 1.1 linux/arch/arm/mach-sa1100/pleb.c - 1.1 linux/include/asm-arm/arch-anakin/irq.h - 1.1 linux/include/asm-arm/arch-anakin/irqs.h - 1.1 linux/include/asm-arm/arch-anakin/keyboard.h - 1.1 linux/arch/s390/vmlinux-shared.lds - 1.1 linux/arch/arm/kernel/entry-header.S - 1.1 linux/include/asm-arm/arch-anakin/memory.h - 1.1 linux/arch/arm/mach-sa1100/pfs168.c - 1.1 linux/include/asm-arm/arch-anakin/param.h - 1.1 linux/include/asm-arm/arch-anakin/serial.h - 1.1 linux/include/asm-arm/arch-anakin/serial_reg.h - 1.1 linux/include/asm-arm/arch-anakin/system.h - 1.1 linux/include/asm-arm/arch-anakin/time.h - 1.1 linux/include/asm-arm/arch-anakin/timex.h - 1.1 linux/arch/arm/mach-sa1100/pcipool.h - 1.1 linux/include/asm-arm/arch-anakin/uncompress.h - 1.1 linux/include/asm-arm/arch-anakin/vmalloc.h - 1.1 linux/arch/arm/mach-sa1100/pcipool.c - 1.1 linux/arch/arm/mach-sa1100/pangolin.c - 1.1 linux/arch/arm/mach-sa1100/omnimeter.c - 1.1 linux/arch/arm/mach-sa1100/neponset.c - 1.1 linux/arch/arm/mach-sa1100/nanoengine.c - 1.1 linux/arch/arm/mach-sa1100/leds.h - 1.1 linux/arch/arm/mach-sa1100/leds-simpad.c - 1.1 linux/arch/arm/mach-sa1100/leds-pfs168.c - 1.1 linux/arch/arm/mach-sa1100/leds-lart.c - 1.1 linux/arch/arm/mach-sa1100/leds-graphicsclient.c - 1.1 linux/arch/arm/mach-sa1100/leds-flexanet.c - 1.1 linux/arch/arm/mach-anakin/Makefile - 1.1 linux/arch/arm/mach-anakin/arch.c - 1.1 linux/arch/arm/mach-anakin/irq.c - 1.1 linux/arch/arm/mach-anakin/mm.c - 1.1 linux/arch/arm/mach-sa1100/leds-cerf.c - 1.1 linux/arch/arm/mach-sa1100/leds-brutus.c - 1.1 linux/arch/arm/mach-sa1100/leds-assabet.c - 1.1 linux/arch/arm/mach-sa1100/lart.c - 1.1 linux/arch/arm/mach-sa1100/jornada720.c - 1.1 linux/arch/arm/mach-integrator/cpu.c - 1.1 linux/arch/arm/mach-sa1100/itsy.c - 1.1 linux/arch/arm/mach-sa1100/irq.c - 1.1 linux/include/asm-arm/mach/serial_sa1100.h - 1.1 linux/arch/arm/mach-sa1100/huw_webpanel.c - 1.1 linux/arch/arm/mach-sa1100/graphicsclient.c - 1.1 linux/arch/arm/mach-sa1100/assabet.c - 1.1 linux/arch/arm/mach-sa1100/bitsy.c - 1.1 linux/arch/arm/mach-sa1100/brutus.c - 1.1 linux/arch/arm/mach-sa1100/cerf.c - 1.1 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.1 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.1 linux/arch/arm/mach-sa1100/generic.h - 1.1 linux/arch/arm/mach-sa1100/generic.c - 1.1 linux/arch/arm/mach-sa1100/freebird.c - 1.1 linux/arch/arm/mach-sa1100/empeg.c - 1.1 linux/arch/arm/mach-sa1100/flexanet.c - 1.1 linux/net/wanrouter/wanproc.c - 1.16 linux/net/wanrouter/wanmain.c - 1.12 linux/net/ipv4/ip_output.c - 1.25 linux/mm/vmscan.c - 1.70 linux/mm/page_alloc.c - 1.51 linux/mm/memory.c - 1.55 linux/mm/filemap.c - 1.81 linux/kernel/module.c - 1.23 linux/kernel/ksyms.c - 1.100 linux/kernel/exit.c - 1.29 linux/ipc/util.c - 1.19 linux/include/linux/swap.h - 1.35 linux/include/linux/ntfs_fs_sb.h - 1.8 linux/include/linux/nfsd/xdr3.h - 1.6 linux/include/linux/nfsd/xdr.h - 1.5 linux/include/linux/nfsd/nfsd.h - 1.13 linux/include/linux/netdevice.h - 1.28 linux/include/linux/major.h - 1.27 linux/include/linux/kernel.h - 1.19 linux/include/linux/iso_fs_sb.h - 1.3 linux/include/linux/fs.h - 1.110 linux/include/linux/apm_bios.h - 1.11 linux/include/asm-sparc64/mmu_context.h - 1.11 linux/include/asm-ppc/types.h - 1.10 linux/include/asm-ppc/prom.h - 1.12 linux/include/asm-ppc/init.h - 1.10 linux/include/asm-m68k/keyboard.h - 1.4 linux/include/asm-i386/page.h - 1.17 linux/include/asm-i386/keyboard.h - 1.8 linux/include/asm-i386/io.h - 1.16 linux/include/asm-arm/unistd.h - 1.17 linux/include/asm-arm/uaccess.h - 1.7 linux/include/asm-arm/softirq.h - 1.7 linux/include/asm-arm/smplock.h - 1.5 linux/include/asm-arm/siginfo.h - 1.6 linux/include/asm-arm/setup.h - 1.10 linux/include/asm-arm/semaphore.h - 1.8 linux/include/asm-arm/processor.h - 1.17 linux/include/asm-arm/proc-armv/uaccess.h - 1.9 linux/include/asm-arm/proc-armv/system.h - 1.12 linux/include/asm-arm/proc-armv/pgtable.h - 1.13 linux/include/asm-arm/proc-armo/uaccess.h - 1.5 linux/include/asm-arm/proc-armo/system.h - 1.10 linux/include/asm-arm/proc-armo/pgtable.h - 1.9 linux/include/asm-arm/pgtable.h - 1.19 linux/include/asm-arm/page.h - 1.12 linux/include/asm-arm/keyboard.h - 1.4 linux/include/asm-arm/io.h - 1.16 linux/include/asm-arm/hardirq.h - 1.9 linux/include/asm-arm/floppy.h - 1.5 linux/include/asm-arm/dma.h - 1.8 linux/include/asm-arm/delay.h - 1.3 linux/include/asm-arm/checksum.h - 1.9 linux/include/asm-arm/bitops.h - 1.7 linux/include/asm-arm/atomic.h - 1.8 linux/include/asm-arm/arch-rpc/time.h - 1.6 linux/include/asm-arm/arch-rpc/system.h - 1.12 linux/include/asm-arm/arch-rpc/memory.h - 1.7 linux/include/asm-arm/arch-rpc/io.h - 1.7 linux/include/asm-arm/arch-nexuspci/time.h - 1.7 linux/include/asm-arm/arch-nexuspci/memory.h - 1.7 linux/include/asm-arm/arch-nexuspci/io.h - 1.7 linux/include/asm-arm/arch-ebsa285/time.h - 1.11 linux/include/asm-arm/arch-ebsa285/system.h - 1.12 linux/include/asm-arm/arch-ebsa285/memory.h - 1.10 linux/include/asm-arm/arch-ebsa285/io.h - 1.12 linux/include/asm-arm/arch-ebsa110/time.h - 1.8 linux/include/asm-arm/arch-ebsa110/memory.h - 1.8 linux/include/asm-arm/arch-arc/time.h - 1.6 linux/include/asm-arm/arch-arc/system.h - 1.11 linux/include/asm-arm/arch-arc/memory.h - 1.7 linux/include/asm-arm/arch-arc/io.h - 1.7 linux/include/asm-arm/arch-arc/hardware.h - 1.9 linux/include/asm-alpha/system.h - 1.16 linux/include/asm-alpha/pgtable.h - 1.27 linux/include/asm-alpha/keyboard.h - 1.4 linux/include/asm-alpha/irq.h - 1.5 linux/include/asm-alpha/console.h - 1.4 linux/include/asm-alpha/cache.h - 1.7 linux/fs/umsdos/namei.c - 1.10 linux/fs/ufs/file.c - 1.8 linux/fs/sysv/file.c - 1.10 linux/fs/smbfs/file.c - 1.21 linux/fs/select.c - 1.17 linux/fs/readdir.c - 1.10 linux/fs/qnx4/file.c - 1.9 linux/fs/qnx4/README - 1.5 linux/fs/open.c - 1.29 linux/fs/ntfs/util.h - 1.5 linux/fs/ntfs/util.c - 1.6 linux/fs/ntfs/support.c - 1.7 linux/fs/ntfs/fs.c - 1.27 linux/fs/ntfs/dir.c - 1.6 linux/fs/ntfs/Makefile - 1.9 linux/fs/nfsd/nfsxdr.c - 1.9 linux/fs/nfsd/nfsfh.c - 1.29 linux/fs/nfsd/nfs3xdr.c - 1.19 linux/fs/nfs/file.c - 1.21 linux/fs/ncpfs/file.c - 1.15 linux/fs/msdos/namei.c - 1.18 linux/fs/isofs/rock.c - 1.13 linux/fs/isofs/joliet.c - 1.6 linux/fs/isofs/inode.c - 1.24 linux/fs/hfs/file_hdr.c - 1.10 linux/fs/hfs/file_cap.c - 1.9 linux/fs/hfs/file.c - 1.12 linux/fs/fat/inode.c - 1.25 linux/fs/fat/file.c - 1.14 linux/fs/fat/cache.c - 1.11 linux/fs/coda/file.c - 1.14 linux/fs/buffer.c - 1.78 linux/fs/affs/file.c - 1.18 linux/fs/adfs/file.c - 1.11 linux/fs/Makefile - 1.33 linux/drivers/video/controlfb.h - 1.3 linux/drivers/video/controlfb.c - 1.14 linux/drivers/video/acornfb.c - 1.17 linux/drivers/usb/hub.c - 1.36 linux/drivers/sound/wavfront.c - 1.18 linux/drivers/sound/soundcard.c - 1.19 linux/drivers/sound/sonicvibes.c - 1.32 linux/drivers/sound/es1371.c - 1.33 linux/drivers/sound/es1370.c - 1.32 linux/drivers/sound/Makefile - 1.31 linux/drivers/sound/Config.in - 1.26 linux/drivers/scsi/st.h - 1.11 linux/drivers/scsi/st.c - 1.31 linux/drivers/scsi/qlogicfc_asm.c - 1.6 linux/drivers/scsi/qlogicfc.c - 1.20 linux/drivers/scsi/ppa.c - 1.11 linux/drivers/scsi/megaraid.c - 1.25 linux/drivers/scsi/in2000.c - 1.8 linux/drivers/scsi/imm.c - 1.11 linux/drivers/scsi/i91uscsi.c - 1.5 linux/drivers/scsi/atp870u.c - 1.17 linux/drivers/scsi/aic7xxx/aic7xxx.seq - 1.9 linux/drivers/scsi/aic7xxx/aic7xxx.reg - 1.7 linux/drivers/scsi/advansys.c - 1.18 linux/drivers/sbus/char/vfc_dev.c - 1.13 linux/drivers/sbus/char/rtc.c - 1.11 linux/drivers/sbus/char/openprom.c - 1.10 linux/drivers/sbus/char/envctrl.c - 1.13 linux/drivers/sbus/audio/audio.c - 1.14 linux/drivers/pci/pci.c - 1.41 linux/drivers/net/smc-mca.c - 1.13 linux/drivers/net/irda/irport.c - 1.21 linux/drivers/net/irda/Makefile - 1.14 linux/drivers/net/irda/Config.in - 1.11 linux/drivers/net/eepro.c - 1.20 linux/drivers/net/depca.c - 1.16 linux/drivers/net/ariadne.c - 1.13 linux/drivers/net/Config.in - 1.45 linux/drivers/net/3c59x.c - 1.28 linux/drivers/net/3c505.c - 1.21 linux/drivers/macintosh/adb.c - 1.11 linux/drivers/isdn/isdnloop/isdnloop.c - 1.7 linux/drivers/isdn/isdn_common.c - 1.26 linux/drivers/isdn/icn/icn.c - 1.13 linux/drivers/isdn/avmb1/capi.c - 1.23 linux/drivers/isdn/act2000/module.c - 1.7 linux/drivers/isdn/act2000/act2000_isa.c - 1.5 linux/drivers/isdn/Config.in - 1.18 linux/drivers/char/wdt.c - 1.11 linux/drivers/char/vt.c - 1.19 linux/drivers/char/tty_ioctl.c - 1.4 linux/drivers/char/tty_io.c - 1.33 linux/drivers/char/tpqic02.c - 1.13 linux/drivers/char/serial.c - 1.46 linux/drivers/char/rtc.c - 1.21 linux/drivers/char/pc_keyb.c - 1.23 linux/drivers/char/lp.c - 1.22 linux/drivers/char/console.c - 1.23 linux/drivers/char/Config.in - 1.46 linux/drivers/char/ChangeLog - 1.3 linux/drivers/acorn/net/etherh.c - 1.11 linux/drivers/acorn/char/Makefile - 1.10 linux/drivers/acorn/block/mfmhd.c - 1.10 linux/drivers/acorn/block/fd1772.c - 1.13 linux/arch/sparc64/mm/init.c - 1.28 linux/arch/sparc64/mm/fault.c - 1.16 linux/arch/sparc64/kernel/sys_sunos32.c - 1.31 linux/arch/sparc64/kernel/sys_sparc32.c - 1.37 linux/arch/sparc64/kernel/smp.c - 1.26 linux/arch/sparc64/kernel/dtlb_backend.S - 1.5 linux/arch/sparc64/defconfig - 1.44 linux/arch/sparc64/config.in - 1.43 linux/arch/sparc/mm/extable.c - 1.5 linux/arch/sparc/kernel/sys_sunos.c - 1.30 linux/arch/ppc/vmlinux.lds - 1.9 linux/arch/ppc/mm/init.c - 1.35 linux/arch/ppc/kernel/traps.c - 1.20 linux/arch/ppc/kernel/setup.c - 1.33 linux/arch/ppc/kernel/prom.c - 1.24 linux/arch/ppc/kernel/prep_setup.c - 1.21 linux/arch/ppc/kernel/prep_pci.c - 1.11 linux/arch/ppc/kernel/ppc_ksyms.c - 1.33 linux/arch/ppc/kernel/pmac_time.c - 1.12 linux/arch/ppc/kernel/pmac_setup.c - 1.22 linux/arch/ppc/kernel/pmac_pci.c - 1.16 linux/arch/ppc/kernel/pci.h - 1.6 linux/arch/ppc/kernel/pci.c - 1.21 linux/arch/ppc/kernel/feature.c - 1.13 linux/arch/ppc/kernel/chrp_pci.c - 1.18 linux/arch/ppc/kernel/apus_setup.c - 1.16 linux/arch/ppc/defconfig - 1.32 linux/arch/mips/kernel/sysirix.c - 1.16 linux/arch/i386/lib/delay.c - 1.6 linux/arch/i386/kernel/traps.c - 1.38 linux/arch/i386/kernel/smp.c - 1.33 linux/arch/i386/kernel/apm.c - 1.32 linux/arch/i386/defconfig - 1.63 linux/arch/arm/mm/proc-sa110.S - 1.21 linux/arch/arm/mm/proc-arm6,7.S - 1.18 linux/arch/arm/mm/init.c - 1.23 linux/arch/arm/mm/fault-common.c - 1.16 linux/arch/arm/mm/fault-armv.c - 1.16 linux/arch/arm/mm/Makefile - 1.12 linux/arch/arm/lib/uaccess-armo.S - 1.6 linux/arch/arm/lib/io-acorn.S - 1.6 linux/arch/arm/lib/Makefile - 1.18 linux/arch/arm/kernel/traps.c - 1.20 linux/arch/arm/kernel/signal.c - 1.15 linux/arch/arm/kernel/setup.c - 1.21 linux/arch/arm/kernel/ptrace.c - 1.13 linux/arch/arm/kernel/process.c - 1.18 linux/arch/arm/kernel/oldlatches.c - 1.9 linux/arch/arm/kernel/head-armv.S - 1.16 linux/arch/arm/kernel/entry-common.S - 1.15 linux/arch/arm/kernel/entry-armv.S - 1.20 linux/arch/arm/kernel/entry-armo.S - 1.11 linux/arch/arm/kernel/ecard.c - 1.14 linux/arch/arm/kernel/armksyms.c - 1.19 linux/arch/arm/kernel/Makefile - 1.17 linux/arch/arm/config.in - 1.26 linux/arch/arm/boot/compressed/misc.c - 1.4 linux/arch/arm/boot/compressed/head.S - 1.14 linux/arch/arm/Makefile - 1.22 linux/arch/alpha/kernel/traps.c - 1.13 linux/arch/alpha/kernel/time.c - 1.17 linux/arch/alpha/kernel/sys_dp264.c - 1.16 linux/arch/alpha/kernel/smp.c - 1.24 linux/arch/alpha/kernel/setup.c - 1.21 linux/arch/alpha/kernel/osf_sys.c - 1.25 linux/arch/alpha/kernel/irq.c - 1.19 linux/arch/alpha/kernel/alpha_ksyms.c - 1.24 linux/arch/alpha/kernel/Makefile - 1.18 linux/arch/alpha/defconfig - 1.18 linux/arch/alpha/config.in - 1.33 linux/Makefile - 1.113 linux/MAINTAINERS - 1.68 linux/Documentation/networking/vortex.txt - 1.10 linux/Documentation/isdn/README.HiSax - 1.10 linux/Documentation/filesystems/ntfs.txt - 1.7 linux/Documentation/devices.txt - 1.10 linux/Documentation/Configure.help - 1.93 linux/CREDITS - 1.59 linux/include/net/irda/smc-ircc.h - 1.7 linux/include/linux/ide.h - 1.30 linux/include/linux/i2o.h - 1.14 linux/fs/hpfs/inode.c - 1.13 linux/fs/hpfs/file.c - 1.14 linux/drivers/video/cyber2000fb.c - 1.23 linux/drivers/sound/cmpci.c - 1.24 linux/drivers/sbus/char/aurora.c - 1.10 linux/drivers/net/irda/smc-ircc.c - 1.20 linux/drivers/isdn/eicon/eicon_mod.c - 1.13 linux/drivers/i2o/i2o_scsi.c - 1.12 linux/drivers/i2o/i2o_proc.c - 1.15 linux/drivers/i2o/i2o_pci.c - 1.17 linux/drivers/i2o/i2o_lan.c - 1.20 linux/drivers/i2o/i2o_core.c - 1.26 linux/drivers/i2o/i2o_config.c - 1.16 linux/drivers/i2o/i2o_block.c - 1.24 linux/drivers/acorn/char/keyb_arc.c - 1.10 linux/arch/arm/nwfpe/single_cpdo.c - 1.5 linux/arch/arm/nwfpe/fpmodule.inl - 1.4 linux/arch/arm/nwfpe/fpmodule.c - 1.9 linux/arch/arm/nwfpe/fpa11_cprt.c - 1.6 linux/arch/arm/nwfpe/fpa11_cpdt.c - 1.5 linux/arch/arm/nwfpe/fpa11_cpdo.c - 1.6 linux/arch/arm/nwfpe/fpa11.inl - 1.4 linux/arch/arm/nwfpe/fpa11.h - 1.4 linux/arch/arm/nwfpe/fpa11.c - 1.5 linux/arch/arm/nwfpe/extended_cpdo.c - 1.6 linux/arch/arm/nwfpe/entry.S - 1.4 linux/arch/arm/nwfpe/double_cpdo.c - 1.6 linux/drivers/sgi/char/ds1286.c - 1.8 linux/drivers/char/ppdev.c - 1.22 linux/arch/arm/def-configs/rpc - 1.7 linux/arch/arm/def-configs/ebsa110 - 1.8 linux/drivers/parport/share.c - 1.16 linux/drivers/parport/parport_pc.c - 1.36 linux/drivers/sound/esssolo1.c - 1.30 linux/fs/partitions/Config.in - 1.14 linux/drivers/isdn/divert/divert_procfs.c - 1.13 linux/drivers/sound/vwsnd.c - 1.12 linux/net/atm/common.c - 1.14 linux/arch/arm/vmlinux-armv.lds.in - 1.16 linux/arch/arm/vmlinux-armo.lds.in - 1.14 linux/arch/arm/kernel/bios32.c - 1.23 linux/drivers/sound/maestro.c - 1.23 linux/drivers/pcmcia/bulkmem.c - 1.14 linux/drivers/sbus/char/uctrl.c - 1.10 linux/drivers/net/wan/cosa.c - 1.20 linux/drivers/net/wan/Makefile - 1.12 linux/drivers/net/wan/Config.in - 1.12 linux/arch/i386/kernel/pci-pc.c - 1.24 linux/include/linux/pci_ids.h - 1.42 linux/drivers/net/wan/syncppp.c - 1.12 linux/drivers/net/wan/sdlamain.c - 1.9 linux/drivers/net/wan/sdla_x25.c - 1.8 linux/drivers/net/wan/sdla_ppp.c - 1.11 linux/drivers/net/wan/sdla_fr.c - 1.12 linux/drivers/net/wan/sbni.c - 1.12 linux/drivers/video/tdfxfb.c - 1.11 linux/arch/arm/mm/mm-sa1100.c - 1.11 linux/arch/arm/kernel/debug-armv.S - 1.9 linux/arch/arm/def-configs/brutus - 1.9 linux/include/asm-arm/proc-armv/cache.h - 1.8 linux/include/asm-arm/proc-armo/cache.h - 1.7 linux/include/asm-arm/pci.h - 1.12 linux/include/asm-arm/arch-sa1100/system.h - 1.12 linux/include/asm-arm/arch-sa1100/serial_reg.h - 1.2 linux/include/asm-arm/arch-sa1100/memory.h - 1.6 linux/include/asm-arm/arch-sa1100/keyboard.h - 1.5 linux/include/asm-arm/arch-sa1100/irq.h - 1.7 linux/include/asm-arm/arch-sa1100/hardware.h - 1.8 linux/include/asm-arm/arch-sa1100/dma.h - 1.4 linux/fs/bfs/file.c - 1.15 linux/drivers/video/acornfb.h - 1.4 linux/drivers/char/pcmcia/serial_cs.c - 1.6 linux/drivers/pci/pci.ids - 1.31 linux/include/asm-arm/pgalloc.h - 1.7 linux/include/asm-arm/arch-cl7500/time.h - 1.6 linux/include/asm-arm/arch-cl7500/memory.h - 1.4 linux/include/asm-arm/arch-cl7500/io.h - 1.5 linux/arch/ppc/kernel/pmac_nvram.c - 1.8 linux/arch/ppc/configs/walnut_defconfig - 1.12 linux/arch/ppc/configs/oak_defconfig - 1.12 linux/arch/ppc/configs/mbx_defconfig - 1.7 linux/arch/ppc/configs/gemini_defconfig - 1.14 linux/arch/ppc/configs/common_defconfig - 1.20 linux/arch/ppc/configs/apus_defconfig - 1.8 linux/drivers/sound/trident.h - 1.11 linux/drivers/sound/trident.c - 1.24 linux/drivers/char/agp/agpgart_fe.c - 1.12 linux/drivers/scsi/scsi_lib.c - 1.34 linux/drivers/char/agp/agpgart_be.c - 1.19 linux/drivers/i2c/i2c-dev.c - 1.11 linux/drivers/usb/dabusb.c - 1.12 linux/drivers/ieee1394/raw1394.c - 1.11 linux/drivers/ieee1394/ieee1394_core.h - 1.8 linux/drivers/ieee1394/pcilynx.h - 1.7 linux/drivers/ieee1394/pcilynx.c - 1.12 linux/drivers/ieee1394/ieee1394_core.c - 1.13 linux/drivers/ieee1394/ohci1394.h - 1.11 linux/drivers/ieee1394/ohci1394.c - 1.15 linux/drivers/ieee1394/ieee1394_types.h - 1.8 linux/drivers/ieee1394/ieee1394_transactions.c - 1.7 linux/drivers/ieee1394/ieee1394_syms.c - 1.9 linux/drivers/ieee1394/hosts.h - 1.6 linux/drivers/ieee1394/hosts.c - 1.8 linux/include/asm-i386/apicdef.h - 1.7 linux/include/asm-arm/arch-sa1100/uncompress.h - 1.6 linux/include/asm-arm/arch-sa1100/ide.h - 1.6 linux/drivers/scsi/scsi_scan.c - 1.17 linux/drivers/net/wan/sdla_chdlc.c - 1.10 linux/drivers/sound/ac97_codec.c - 1.17 linux/arch/ia64/ia32/sys_ia32.c - 1.17 linux/arch/alpha/kernel/pci_iommu.c - 1.13 linux/drivers/sound/via82cxxx_audio.c - 1.18 linux/include/linux/raid/md_k.h - 1.12 linux/include/linux/raid/md.h - 1.7 linux/drivers/net/8139too.c - 1.24 linux/drivers/isdn/hysdn/hysdn_procconf.c - 1.11 linux/drivers/isdn/hysdn/hysdn_procfs.c - 1.6 linux/drivers/isdn/hysdn/hysdn_proclog.c - 1.10 linux/include/linux/ac97_codec.h - 1.9 linux/drivers/parport/ChangeLog - 1.17 linux/drivers/ide/via82cxxx.c - 1.14 linux/drivers/ide/piix.c - 1.12 linux/drivers/ide/pdc202xx.c - 1.9 linux/drivers/ide/ide.c - 1.25 linux/drivers/ide/ide-tape.c - 1.14 linux/drivers/ide/ide-proc.c - 1.6 linux/drivers/ide/ide-probe.c - 1.15 linux/drivers/ide/ide-pci.c - 1.15 linux/drivers/ide/ide-floppy.c - 1.7 linux/drivers/ide/ide-dma.c - 1.11 linux/drivers/ide/ide-disk.c - 1.14 linux/drivers/ide/ide-cd.h - 1.7 linux/drivers/ide/ide-cd.c - 1.16 linux/drivers/ide/Makefile - 1.9 linux/drivers/ide/Config.in - 1.12 linux/arch/arm/kernel/arch.c - 1.9 linux/drivers/sound/dmasound/dmasound_core.c - 1.7 linux/drivers/char/wdt_pci.c - 1.6 linux/include/asm-arm/arch-shark/time.h - 1.5 linux/include/asm-arm/arch-shark/memory.h - 1.4 linux/include/asm-arm/arch-shark/io.h - 1.5 linux/drivers/video/sa1100fb.c - 1.7 linux/include/asm-arm/arch-shark/dma.h - 1.3 linux/drivers/sound/i810_audio.c - 1.13 linux/drivers/sound/emu10k1/midi.c - 1.8 linux/drivers/sound/emu10k1/main.c - 1.11 linux/drivers/sound/emu10k1/audio.c - 1.10 linux/drivers/sound/emu10k1/Makefile - 1.5 linux/arch/s390/kernel/process.c - 1.7 linux/include/linux/raid/raid1.h - 1.5 linux/arch/arm/def-configs/lart - 1.4 linux/include/asm-s390/softirq.h - 1.4 linux/arch/s390/kernel/entry.S - 1.11 linux/arch/arm/def-configs/assabet - 1.5 linux/arch/arm/def-configs/graphicsclient - 1.4 linux/include/asm-arm/arch-sa1100/time.h - 1.3 linux/include/asm-arm/arch-l7200/time.h - 1.4 linux/include/asm-arm/arch-l7200/system.h - 1.5 linux/include/asm-arm/arch-l7200/memory.h - 1.4 linux/include/asm-arm/arch-l7200/io.h - 1.4 linux/drivers/char/drm/ffb_drv.c - 1.9 linux/drivers/char/drm/ffb_context.c - 1.4 linux/drivers/usb/storage/scsiglue.c - 1.12 linux/drivers/char/sbc60xxwdt.c - 1.9 linux/include/asm-arm/mmzone.h - 1.4 linux/include/asm-arm/memory.h - 1.3 linux/fs/jffs/inode-v23.c - 1.9 linux/fs/jffs/intrep.c - 1.5 linux/arch/arm/mm/proc-arm720.S - 1.7 linux/drivers/acorn/char/defkeymap-acorn.c - 1.4 linux/include/asm-arm/arch-sa1100/mmzone.h - 1.6 linux/include/asm-arm/arch-sa1100/bitsy.h - 1.4 linux/include/asm-arm/arch-sa1100/assabet.h - 1.4 linux/include/asm-arm/arch-sa1100/SA-1111.h - 1.3 linux/include/asm-arm/arch-sa1100/SA-1100.h - 1.4 linux/drivers/ieee1394/video1394.c - 1.8 linux/drivers/ieee1394/video1394.h - 1.5 linux/include/linux/serio.h - 1.3 linux/include/linux/jffs.h - 1.3 linux/arch/ppc/configs/rpxlite_defconfig - 1.7 linux/arch/ppc/configs/rpxcllf_defconfig - 1.8 linux/arch/ppc/configs/est8260_defconfig - 1.8 linux/arch/ppc/configs/bseip_defconfig - 1.7 linux/drivers/net/tun.c - 1.10 linux/include/asm-arm/mach/pci.h - 1.4 linux/include/asm-arm/mach/arch.h - 1.4 linux/drivers/sound/cs46xx.c - 1.13 linux/drivers/net/natsemi.c - 1.11 linux/drivers/media/video/videodev.c - 1.6 linux/drivers/media/video/tvmixer.c - 1.4 linux/drivers/media/radio/radio-sf16fmi.c - 1.7 linux/drivers/media/radio/Config.in - 1.8 linux/drivers/isdn/eicon/xlog.c - 1.3 linux/drivers/isdn/eicon/uxio.h - 1.3 linux/drivers/isdn/eicon/log.c - 1.3 linux/drivers/isdn/eicon/linsys.c - 1.3 linux/drivers/isdn/eicon/linchr.c - 1.5 linux/drivers/isdn/eicon/lincfg.c - 1.3 linux/drivers/isdn/eicon/kprintf.c - 1.4 linux/drivers/isdn/eicon/common.c - 1.6 linux/arch/arm/tools/mach-types - 1.7 linux/arch/arm/mach-footbridge/arch.c - 1.4 linux/arch/arm/mach-footbridge/Makefile - 1.4 linux/drivers/md/raid1.c - 1.11 linux/Documentation/SubmittingDrivers - 1.5 linux/arch/arm/def-configs/shark - 1.2 linux/arch/arm/kernel/via82c505.c - 1.4 linux/arch/arm/mach-sa1100/Makefile - 1.4 linux/arch/arm/mach-sa1100/arch.c - 1.4 linux/arch/arm/mach-sa1100/hw.c - 1.3 linux/arch/arm/mach-sa1100/leds.c - 1.2 linux/arch/arm/mach-shark/arch.c - 1.3 linux/arch/arm/mm/proc-arm920.S - 1.4 linux/drivers/macintosh/rtc.c - 1.3 linux/drivers/md/md.c - 1.18 linux/drivers/net/hamachi.c - 1.10 linux/drivers/scsi/cpqfc.Readme - 1.4 linux/drivers/scsi/cpqfcTSinit.c - 1.10 linux/drivers/scsi/cpqfcTSstructs.h - 1.4 linux/drivers/scsi/cpqfcTStrigger.c - 1.2 linux/drivers/scsi/cpqfcTSworker.c - 1.6 linux/include/asm-arm/arch-tbox/io.h - 1.3 linux/include/asm-arm/arch-tbox/memory.h - 1.3 linux/include/asm-arm/arch-tbox/time.h - 1.3 linux/include/asm-arm/hardware/pci_v3.h - 1.3 linux/drivers/ide/osb4.c - 1.5 linux/mm/oom_kill.c - 1.5 linux/drivers/video/sis/sis_main.c - 1.4 linux/include/linux/ethtool.h - 1.5 linux/drivers/video/fbcon-sti.c - 1.2 linux/Documentation/parisc/mm - 1.2 linux/drivers/video/sticon-bmode.c - 1.3 linux/drivers/video/sticore.c - 1.3 linux/drivers/net/lasi_82596.c - 1.6 linux/arch/arm/def-configs/integrator - 1.3 linux/arch/arm/def-configs/neponset - 1.2 linux/arch/arm/def-configs/pangolin - 1.2 linux/arch/arm/def-configs/sherman - 1.2 linux/arch/arm/lib/io-pcio.S - 1.3 linux/arch/arm/lib/io-readsb.S - 1.3 linux/arch/arm/lib/io-readsw-armv3.S - 1.3 linux/arch/arm/lib/io-readsw-armv4.S - 1.3 linux/arch/arm/lib/io-writesb.S - 1.3 linux/arch/arm/lib/io-writesl.S - 1.3 linux/arch/arm/lib/io-writesw-armv3.S - 1.3 linux/arch/arm/lib/io-writesw-armv4.S - 1.3 linux/arch/i386/kernel/dmi_scan.c - 1.6 linux/drivers/sound/ymfpci.h - 1.5 linux/drivers/sound/ymfpci.c - 1.9 linux/arch/parisc/hpux/fs.c - 1.2 linux/drivers/char/drm/r128_cce.c - 1.3 linux/drivers/char/drm/radeon_cp.c - 1.3 linux/arch/ppc/configs/power3_defconfig - 1.5 linux/arch/ppc/configs/ibmchrp_defconfig - 1.5 linux/arch/arm/boot/compressed/ofw-shark.c - 1.3 linux/drivers/sound/maestro3.c - 1.5 linux/drivers/sound/cs4281/cs4281m.c - 1.6 linux/arch/s390x/kernel/process.c - 1.4 linux/arch/arm/lib/io-readsl-armv3.S - 1.2 linux/arch/arm/lib/io-readsl-armv4.S - 1.2 linux/arch/s390x/kernel/linux32.c - 1.6 linux/arch/s390x/kernel/ioctl32.c - 1.2 linux/arch/s390x/kernel/entry.S - 1.6 linux/include/asm-s390x/softirq.h - 1.3 linux/include/asm-arm/mach/amba_kmi.h - 1.2 linux/include/asm-arm/arch-integrator/time.h - 1.2 linux/include/asm-arm/arch-integrator/system.h - 1.2 linux/include/asm-arm/arch-integrator/memory.h - 1.2 linux/drivers/scsi/aic7xxx/cam.h - 1.2 linux/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c - 1.3 linux/drivers/scsi/aic7xxx/aicasm/aicasm_scan.l - 1.2 linux/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y - 1.2 linux/drivers/scsi/aic7xxx/aicasm/aicasm.h - 1.2 linux/drivers/scsi/aic7xxx/aicasm/aicasm.c - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_seq.h - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_reg.h - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_proc.c - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_linux_pci.c - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_inline.h - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_93cx6.c - 1.2 linux/arch/arm/mach-integrator/Makefile - 1.2 linux/arch/arm/mach-integrator/arch.c - 1.2 linux/arch/arm/mach-integrator/pci.c - 1.2 linux/arch/arm/mach-integrator/pci_v3.c - 1.2 linux/arch/arm/mach-integrator/time.c - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx.h - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx.c - 1.5 linux/drivers/scsi/aic7xxx/aic7770_linux.c - 1.3 linux/drivers/scsi/aic7xxx/aic7770.c - 1.3 linux/drivers/scsi/aic7xxx/Makefile - 1.3 linux/drivers/isdn/hisax/sedlbauer_cs.c - 1.3 linux/arch/ppc/configs/TQM860L_defconfig - 1.5 linux/arch/ppc/configs/TQM850L_defconfig - 1.5 linux/arch/ppc/configs/TQM823L_defconfig - 1.5 linux/arch/ppc/configs/SPD823TS_defconfig - 1.5 linux/arch/ppc/configs/SM850_defconfig - 1.5 linux/arch/ppc/configs/IVMS8_defconfig - 1.5 linux/drivers/net/wan/sdla_ft1.c - 1.2 linux/drivers/net/wan/wanpipe_multppp.c - 1.3 linux/arch/arm/kernel/irq-arch.c - 1.2 linux/arch/arm/mach-ebsa110/io.c - 1.4 linux/arch/arm/mach-sa1100/dma-sa1100.c - 1.2 linux/arch/arm/mach-sa1100/dma-sa1111.c - 1.2 linux/arch/arm/mach-sa1100/dma.h - 1.3 linux/arch/mips/ite-boards/generic/irq.c - 1.2 linux/arch/ppc/kernel/apus_pci.c - 1.2 linux/Documentation/usb/philips.txt - 1.3 linux/arch/alpha/mm/numa.c - 1.2 linux/drivers/usb/pwc.h - 1.3 linux/drivers/usb/pwc-misc.c - 1.2 linux/drivers/usb/pwc-if.c - 1.3 linux/drivers/usb/pwc-ctrl.c - 1.3 linux/drivers/bluetooth/hci_uart.c - 1.2 linux/drivers/bluetooth/hci_usb.c - 1.2 linux/drivers/bluetooth/hci_emu.c - 1.2 linux/drivers/acorn/char/mouse_ps2.c - 1.2 linux/Documentation/sonypi.txt - 1.2 linux/drivers/char/w83877f_wdt.c - 1.2 linux/drivers/message/fusion/mptctl.c - 1.2 linux/drivers/ieee1394/sbp2.c - 1.2 linux/drivers/ieee1394/sbp2.h - 1.2 linux/drivers/ieee1394/nodemgr.c - 1.3 linux/drivers/ieee1394/nodemgr.h - 1.3 linux/fs/partitions/ldm.h - 1.3 linux/drivers/char/drm/drm_vm.h - 1.2 linux/drivers/char/drm/drm_scatter.h - 1.2 linux/drivers/char/drm/drm_context.h - 1.2 linux/drivers/char/drm/ati_pcigart.h - 1.2 linux/drivers/sound/emu10k1/joystick.c - 1.2 linux/drivers/sound/emu10k1/passthrough.h - 1.2 From owner-linux-xfs@oss.sgi.com Wed Aug 15 08:33:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FFXgT21977 for linux-xfs-outgoing; Wed, 15 Aug 2001 08:33:42 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FFXej21948 for ; Wed, 15 Aug 2001 08:33:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA25073 for ; Wed, 15 Aug 2001 08:33:24 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2719372; Wed, 15 Aug 2001 10:32:22 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA78790; Wed, 15 Aug 2001 10:32:22 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7FFUk400694; Wed, 15 Aug 2001 10:30:46 -0500 Message-Id: <200108151530.f7FFUk400694@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Ken Cross" cc: "Steve Lord" , "Linux XFS" Subject: Re: SPEC failures In-Reply-To: Message from "Ken Cross" of "Wed, 15 Aug 2001 11:09:09 EDT." <002f01c1259c$3cb3b260$0200a8c0@kjc2.com> Date: Wed, 15 Aug 2001 10:30:46 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Thanks for the quick response, Steve. > > I'd be happy to tackle the problem if you have an idea which module(s) > changed. Maybe nfsd would have more luck detecting XFS than the other way > around. > > Ken > Well, the ugly hack approach is to edit fs/xfs/linux/xfs_iops.c and change this code (line 91): if (!have_default_acl) { mode &= ~current->fs->umask; } to something like this: if (!have_default_acl && strcmp(current->comm, "nfsd")) { mode &= ~current->fs->umask; } In other words, do not apply the umask if being called from nfs. The problem is that this code is normally executed up above in the vfs layer and for xfs we explicitly delay it until we get into the filesystem so that we can make the determination about having an acl or not. Andrew had the approach of setting the umask of the nfsd process to 0 at startup, there was some other reason for this not being popular. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 15 09:08:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FG80930332 for linux-xfs-outgoing; Wed, 15 Aug 2001 09:08:00 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FG7uj30298 for ; Wed, 15 Aug 2001 09:07:57 -0700 Received: (qmail 23040 invoked from network); 15 Aug 2001 16:07:52 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 15 Aug 2001 16:07:52 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Steve Lord cc: "Ken Cross" , "Linux XFS" Subject: Re: SPEC failures In-reply-to: Your message of "Wed, 15 Aug 2001 10:30:46 EST." <200108151530.f7FFUk400694@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Aug 2001 02:07:51 +1000 Message-ID: <6313.997891671@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 15 Aug 2001 10:30:46 -0500, Steve Lord wrote: >Andrew had the approach of setting the umask of the nfsd process to 0 at >startup, there was some other reason for this not being popular. It set _all_ kernel thread umasks to 000, opening quite a few security loopholes. From owner-linux-xfs@oss.sgi.com Wed Aug 15 10:22:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FHMA612766 for linux-xfs-outgoing; Wed, 15 Aug 2001 10:22:10 -0700 Received: from web20209.mail.yahoo.com (web20209.mail.yahoo.com [216.136.226.64]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FHM8j12739 for ; Wed, 15 Aug 2001 10:22:08 -0700 Message-ID: <20010815172208.20794.qmail@web20209.mail.yahoo.com> Received: from [64.56.238.250] by web20209.mail.yahoo.com; Wed, 15 Aug 2001 10:22:08 PDT Date: Wed, 15 Aug 2001 10:22:08 -0700 (PDT) From: Nexus Subject: Installation Of XFS Patch For Kernel 2.4.8? To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I noticed there is now a patch for the final kernel 2.4.8 on the ftp site (patch-2.4.8-xfs-2001-08-15.bz2). Is this the only patch I need for a fresh kernel 2.4.8 for XFS support? Does this patch include the XFS 1.0.1 release? __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-xfs@oss.sgi.com Wed Aug 15 10:26:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FHQKm13847 for linux-xfs-outgoing; Wed, 15 Aug 2001 10:26:20 -0700 Received: from mplspop3.mpls.uswest.net (mplspop3.mpls.uswest.net [204.147.80.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FHQIj13822 for ; Wed, 15 Aug 2001 10:26:18 -0700 Received: (qmail 28329 invoked from network); 15 Aug 2001 17:26:16 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop3.mpls.uswest.net with SMTP; 15 Aug 2001 17:26:16 -0000 Date: Wed, 15 Aug 2001 12:23:15 -0500 Message-ID: <3B7AB003.484F714E@sgi.com> From: "Eric Sandeen" To: "Nexus" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: Installation Of XFS Patch For Kernel 2.4.8? References: <20010815172208.20794.qmail@web20209.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nexus wrote: > > I noticed there is now a patch for the final kernel > 2.4.8 on the ftp site > (patch-2.4.8-xfs-2001-08-15.bz2). Is this the only > patch I need for a fresh kernel 2.4.8 for XFS support? Yep, but as the README says, it's a development snapshot, so buyer beware. Of course you need the usererspace tools as well. > Does this patch include the XFS 1.0.1 release? It is further along than the 1.0.1 release, but not nearly as tested. -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 Aug 15 10:54:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FHsZY20037 for linux-xfs-outgoing; Wed, 15 Aug 2001 10:54:35 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FHsVj20009 for ; Wed, 15 Aug 2001 10:54:31 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id D1A641E110; Wed, 15 Aug 2001 19:54:25 +0200 (MEST) Date: Wed, 15 Aug 2001 19:54:24 +0200 From: Andi Kleen To: Steve Lord Cc: Ken Cross , Linux XFS Subject: Re: SPEC failures Message-ID: <20010815195424.A22872@gruyere.muc.suse.de> References: <200108151530.f7FFUk400694@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108151530.f7FFUk400694@jen.americas.sgi.com>; from lord@sgi.com on Wed, Aug 15, 2001 at 10:30:46AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 15, 2001 at 10:30:46AM -0500, Steve Lord wrote: > Andrew had the approach of setting the umask of the nfsd process to 0 at > startup, there was some other reason for this not being popular. He did it for init_task, which disturbed all other kernel threads too and opened tons of security holes. The right way IMHO is to give nfsd an own fs_struct and set umask there, as in this patch. -Andi --- linux-xfs/fs/nfsd/nfssvc.c-NFSUMASK Wed Jun 20 13:08:49 2001 +++ linux-xfs/fs/nfsd/nfssvc.c Wed Aug 15 19:32:11 2001 @@ -136,6 +136,18 @@ } } +int fork_fsstruct(void) +{ + struct fs_struct *oldfs = current->fs, *newfs; + newfs = copy_fs_struct(oldfs); + if (newfs) { + current->fs = newfs; + put_fs_struct(oldfs); + return 0; + } + return -1; +} + /* * This is the NFS server kernel thread */ @@ -150,6 +162,8 @@ MOD_INC_USE_COUNT; lock_kernel(); daemonize(); + if (!fork_fsstruct()) + current->fs->umask = 0; sprintf(current->comm, "nfsd"); current->rlim[RLIMIT_FSIZE].rlim_cur = RLIM_INFINITY; --- linux-xfs/kernel/ksyms.c-NFSUMASK Tue Aug 14 02:10:34 2001 +++ linux-xfs/kernel/ksyms.c Wed Aug 15 19:34:36 2001 @@ -298,6 +298,8 @@ EXPORT_SYMBOL(buffermem_pages); EXPORT_SYMBOL(nr_free_pages); EXPORT_SYMBOL(page_cache_size); +EXPORT_SYMBOL(copy_fs_struct); +EXPORT_SYMBOL(put_fs_struct); /* for stackable file systems (lofs, wrapfs, cryptfs, etc.) */ EXPORT_SYMBOL(default_llseek); From owner-linux-xfs@oss.sgi.com Wed Aug 15 12:33:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FJXAq11275 for linux-xfs-outgoing; Wed, 15 Aug 2001 12:33:10 -0700 Received: from mplspop3.mpls.uswest.net (mplspop3.mpls.uswest.net [204.147.80.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FJX7j11236 for ; Wed, 15 Aug 2001 12:33:07 -0700 Received: (qmail 51091 invoked from network); 15 Aug 2001 19:33:03 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop3.mpls.uswest.net with SMTP; 15 Aug 2001 19:33:03 -0000 Date: Wed, 15 Aug 2001 14:30:01 -0500 Message-ID: <3B7ACDB9.662C7104@sgi.com> From: "Eric Sandeen" To: "Tang Lingbo" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: error in xfs_logprint? References: <20010815150653.25401.qmail@sina.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Tang - your patch looks quite reasonable to me, I'll let the Australians take a look at it, since they "own" userspace. I didn't get a core dump, though - which version of xfsprogs do you have? Thanks! -Eric Tang Lingbo wrote: > > Hi, > > There was a core dump in xfs_logprint when I did as follows: > > 1)$ dd if=/dev/zero of=/tmp/xfs bs=1024 count=50000 > 2)$ mkfs.xfs /tmp/xfs > 3)$ mount -t xfs -o loop /tmp/xfs /xfs > 4)$ touch /xfs/test > 5)$ for((i=0;i<1024;i++));do echo -n 1 >> /tmp/dummy;done > 6)$ value=`cat /tmp/dummy`;attr -s test -V $value /xfs/test > 7)$ xfs_logprint /tmp/xfs > > output: > > ... > xlog_print_trans_inode: illegal inode type > > And I think the patch will be as follows: -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Aug 15 12:37:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FJbIi12384 for linux-xfs-outgoing; Wed, 15 Aug 2001 12:37:18 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FJbGj12359 for ; Wed, 15 Aug 2001 12:37:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA01970 for ; Wed, 15 Aug 2001 12:37:16 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2718374; Wed, 15 Aug 2001 14:35:59 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA58892; Wed, 15 Aug 2001 14:35:59 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7FJYLP01380; Wed, 15 Aug 2001 14:34:21 -0500 Message-Id: <200108151934.f7FJYLP01380@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: Steve Lord , Ken Cross , Linux XFS Subject: Re: SPEC failures In-Reply-To: Message from Andi Kleen of "Wed, 15 Aug 2001 19:54:24 +0200." <20010815195424.A22872@gruyere.muc.suse.de> Date: Wed, 15 Aug 2001 14:34:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Aug 15, 2001 at 10:30:46AM -0500, Steve Lord wrote: > > Andrew had the approach of setting the umask of the nfsd process to 0 at > > startup, there was some other reason for this not being popular. > > He did it for init_task, which disturbed all other kernel threads too > and opened tons of security holes. > The right way IMHO is to give nfsd an own fs_struct and set umask there, > as in this patch. > > -Andi Thanks, Care to try this one on Neil Brown or Trond? I wonder if the acl project has run into the same issue? The tricky part in justifying this is nothing in the main kernel needs this change right now. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 15 13:17:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FKHPX22551 for linux-xfs-outgoing; Wed, 15 Aug 2001 13:17:25 -0700 Received: from ntown.esper.com (root@ntown.esper.com [216.111.16.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FKHMj22521 for ; Wed, 15 Aug 2001 13:17:22 -0700 Received: from kjcwin2k (kcross.ntown.esper.com [216.111.19.212]) by ntown.esper.com (8.11.4/8.11.4) with SMTP id f7FKNiE07755 for ; Wed, 15 Aug 2001 16:23:44 -0400 Message-ID: <004b01c125c7$49d94560$0200a8c0@kjc2.com> From: "Ken Cross" To: "Linux XFS" Subject: Error compiling 2.4.9-pre4-xfs Date: Wed, 15 Aug 2001 16:17:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Using egcs 1.1.2, I'm getting the following error compiling the new (8/15) CVS sources: make[5]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/scsi/aic7xxx/aicasm' gcc -I/usr/include -I. -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm/aicasm_scan.l: In function `yylex': aicasm/aicasm_scan.l:115: `T_VERSION' undeclared (first use in this function) aicasm/aicasm_scan.l:115: (Each undeclared identifier is reported only once aicasm/aicasm_scan.l:115: for each function it appears in.) aicasm/aicasm_scan.l:132: `T_STRING' undeclared (first use in this function) make[5]: *** [aicasm] Error 1 Is it just me? Ken From owner-linux-xfs@oss.sgi.com Wed Aug 15 13:24:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FKOKr24404 for linux-xfs-outgoing; Wed, 15 Aug 2001 13:24:20 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FKOHj24374 for ; Wed, 15 Aug 2001 13:24:17 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA20128 for ; Wed, 15 Aug 2001 13:24:01 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2722050; Wed, 15 Aug 2001 15:23:00 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA99658; Wed, 15 Aug 2001 15:23:00 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7FKLLL02598; Wed, 15 Aug 2001 15:21:22 -0500 Message-Id: <200108152021.f7FKLLL02598@jen.americas.sgi.com> To: "Ken Cross" cc: "Linux XFS" Subject: Re: Error compiling 2.4.9-pre4-xfs References: <004b01c125c7$49d94560$0200a8c0@kjc2.com> Comments: In-reply-to "Ken Cross" message dated "Wed, 15 Aug 2001 16:17:20 -0400." Date: Wed, 15 Aug 2001 15:21:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Using egcs 1.1.2, I'm getting the following error compiling the new (8/15) > CVS sources: > > make[5]: Entering directory > `/usr/src/linux-2.4-xfs/linux/drivers/scsi/aic7xxx/aicasm' > gcc -I/usr/include -I. -ldb aicasm_gram.c aicasm_scan.c aicasm.c > aicasm_symbol.c -o aicasm > aicasm/aicasm_scan.l: In function `yylex': > aicasm/aicasm_scan.l:115: `T_VERSION' undeclared (first use in this > function) > aicasm/aicasm_scan.l:115: (Each undeclared identifier is reported only > once > aicasm/aicasm_scan.l:115: for each function it appears in.) > aicasm/aicasm_scan.l:132: `T_STRING' undeclared (first use in this > function) > make[5]: *** [aicasm] Error 1 > > > Is it just me? > > Ken > Hmm, are you building the adapter firmware? Try turning this off. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 15 13:29:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FKTU325898 for linux-xfs-outgoing; Wed, 15 Aug 2001 13:29:30 -0700 Received: from ntown.esper.com (root@ntown.esper.com [216.111.16.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FKTSj25870 for ; Wed, 15 Aug 2001 13:29:28 -0700 Received: from kjcwin2k (kcross.ntown.esper.com [216.111.19.212]) by ntown.esper.com (8.11.4/8.11.4) with SMTP id f7FKZZE08562; Wed, 15 Aug 2001 16:35:36 -0400 Message-ID: <005901c125c8$f2bc05e0$0200a8c0@kjc2.com> From: "Ken Cross" To: "Steve Lord" Cc: "Linux XFS" References: <004b01c125c7$49d94560$0200a8c0@kjc2.com> <200108152021.f7FKLLL02598@jen.americas.sgi.com> Subject: Re: Error compiling 2.4.9-pre4-xfs Date: Wed, 15 Aug 2001 16:29:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The system disk (in fact, all disks) are on the SCSI controller, so the aic7xxx module must be built into the kernel. It has a tough time booting without it. (The FAQs are very specific about this.) I'll look to see if it's something obvious... Ken ----- Original Message ----- From: "Steve Lord" To: "Ken Cross" Cc: "Linux XFS" Sent: Wednesday, August 15, 2001 4:21 PM Subject: Re: Error compiling 2.4.9-pre4-xfs > > Using egcs 1.1.2, I'm getting the following error compiling the new (8/15) > > CVS sources: > > > > make[5]: Entering directory > > `/usr/src/linux-2.4-xfs/linux/drivers/scsi/aic7xxx/aicasm' > > gcc -I/usr/include -I. -ldb aicasm_gram.c aicasm_scan.c aicasm.c > > aicasm_symbol.c -o aicasm > > aicasm/aicasm_scan.l: In function `yylex': > > aicasm/aicasm_scan.l:115: `T_VERSION' undeclared (first use in this > > function) > > aicasm/aicasm_scan.l:115: (Each undeclared identifier is reported only > > once > > aicasm/aicasm_scan.l:115: for each function it appears in.) > > aicasm/aicasm_scan.l:132: `T_STRING' undeclared (first use in this > > function) > > make[5]: *** [aicasm] Error 1 > > > > > > Is it just me? > > > > Ken > > > > Hmm, are you building the adapter firmware? Try turning this off. > > > Steve > From owner-linux-xfs@oss.sgi.com Wed Aug 15 13:33:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FKXtV26912 for linux-xfs-outgoing; Wed, 15 Aug 2001 13:33:55 -0700 Received: from codon.com (hunting.codon.com [64.78.130.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FKXrj26889 for ; Wed, 15 Aug 2001 13:33:53 -0700 Received: (qmail 27844 invoked by uid 516); 15 Aug 2001 20:45:06 -0000 Received: from nw@codon.com by helix with qmail-scanner-0.96 (. Clean. Processed in 0.051946 secs); 15 Aug 2001 20:45:06 -0000 Received: from weasel.local.iboats.com (HELO weasel) (64.78.130.80) by codon.com with SMTP; 15 Aug 2001 20:45:06 -0000 Message-ID: <004f01c125c9$09f6ada0$50824e40@iboats.com> From: "Steve Wolfe" To: "Linux XFS" References: <004b01c125c7$49d94560$0200a8c0@kjc2.com> <200108152021.f7FKLLL02598@jen.americas.sgi.com> <005901c125c8$f2bc05e0$0200a8c0@kjc2.com> Subject: Re: Error compiling 2.4.9-pre4-xfs Date: Wed, 15 Aug 2001 14:29:51 -0600 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 Ken said: > > > Is it just me? Steve Lord replied: > > Hmm, are you building the adapter firmware? Try turning this off. Ken replied: > The system disk (in fact, all disks) are on the SCSI controller, so the > aic7xxx module must be built into the kernel. It has a tough time booting > without it. (The FAQs are very specific about this.) > > I'll look to see if it's something obvious... I now reply: Without meaning to be rude, are you sure that you understand what the "firmware" is? Your reply doesn't seem to correlate in any way to what Steve (Lord) suggested. Steve (not Lord) From owner-linux-xfs@oss.sgi.com Wed Aug 15 13:40:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FKe4H28375 for linux-xfs-outgoing; Wed, 15 Aug 2001 13:40:04 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FKe3j28353 for ; Wed, 15 Aug 2001 13:40:03 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08356 for ; Wed, 15 Aug 2001 13:40:01 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2720585; Wed, 15 Aug 2001 15:38:36 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA17681; Wed, 15 Aug 2001 15:38:36 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7FKawJ04624; Wed, 15 Aug 2001 15:36:58 -0500 Message-Id: <200108152036.f7FKawJ04624@jen.americas.sgi.com> To: "Ken Cross" cc: "Steve Lord" , "Linux XFS" Subject: Re: Error compiling 2.4.9-pre4-xfs References: <004b01c125c7$49d94560$0200a8c0@kjc2.com> <200108152021.f7FKLLL02598@jen.americas.sgi.com> <005901c125c8$f2bc05e0$0200a8c0@kjc2.com> Comments: In-reply-to "Ken Cross" message dated "Wed, 15 Aug 2001 16:29:12 -0400." Date: Wed, 15 Aug 2001 15:36:58 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The system disk (in fact, all disks) are on the SCSI controller, so the > aic7xxx module must be built into the kernel. It has a tough time booting > without it. (The FAQs are very specific about this.) > > I'll look to see if it's something obvious... > > Ken You do not need to rebuild the adapter firmware, there is a config option to control this. If you turn off adapter firmware compilation it appears to work. I will have to try building the vanilla version and see if that has the issue too. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 15 14:08:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FL8h702490 for linux-xfs-outgoing; Wed, 15 Aug 2001 14:08:43 -0700 Received: from ntown.esper.com (root@ntown.esper.com [216.111.16.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FL8dj02455 for ; Wed, 15 Aug 2001 14:08:40 -0700 Received: from kjcwin2k (kcross.ntown.esper.com [216.111.19.212]) by ntown.esper.com (8.11.4/8.11.4) with SMTP id f7FLEvE12056; Wed, 15 Aug 2001 17:14:57 -0400 Message-ID: <006b01c125ce$71e07270$0200a8c0@kjc2.com> From: "Ken Cross" To: "Steve Wolfe" , "Linux XFS" References: <004b01c125c7$49d94560$0200a8c0@kjc2.com> <200108152021.f7FKLLL02598@jen.americas.sgi.com> <005901c125c8$f2bc05e0$0200a8c0@kjc2.com> <004f01c125c9$09f6ada0$50824e40@iboats.com> Subject: Re: Error compiling 2.4.9-pre4-xfs Date: Wed, 15 Aug 2001 17:08:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve (Lord & Wolfe): You're absolutely right -- I don't need to rebuild the firmware. (I didn't look close enough at what Steve L. said -- sorry). I removed that option and got an error that aic7xxx_seq.h was missing (blown away by previous errors). I re-loaded from CVS and it worked like a champ -- thanks to both of you. Furthermore, I put in the hack suggested by Steve L. this morning to fix the acl/mask problem with nfsd, and hack though it be, SPEC is happy now. Jeez - this was actually a productive day! Thanks much, Ken ----- Original Message ----- From: "Steve Wolfe" To: "Linux XFS" Sent: Wednesday, August 15, 2001 4:29 PM Subject: Re: Error compiling 2.4.9-pre4-xfs > > Ken said: > > > > > Is it just me? > > Steve Lord replied: > > > > Hmm, are you building the adapter firmware? Try turning this off. > > Ken replied: > > > The system disk (in fact, all disks) are on the SCSI controller, so the > > aic7xxx module must be built into the kernel. It has a tough time > booting > > without it. (The FAQs are very specific about this.) > > > > I'll look to see if it's something obvious... > > I now reply: > > Without meaning to be rude, are you sure that you understand what the > "firmware" is? Your reply doesn't seem to correlate in any way to what > Steve (Lord) suggested. > > Steve (not Lord) > From owner-linux-xfs@oss.sgi.com Wed Aug 15 14:17:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FLHdP04853 for linux-xfs-outgoing; Wed, 15 Aug 2001 14:17:39 -0700 Received: from musique.teaser.fr (musique.teaser.net [213.91.2.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FLHaj04822 for ; Wed, 15 Aug 2001 14:17:37 -0700 Received: from lucas.loria (d34-51.ppp.teaser.fr [213.91.34.51]) by musique.teaser.fr (Postfix) with ESMTP id D672B7252A; Wed, 15 Aug 2001 23:17:34 +0200 (CEST) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id AD192A5E3; Wed, 15 Aug 2001 13:14:14 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id 82CE65F8B5; Wed, 15 Aug 2001 13:14:13 +0200 (CEST) To: "Eric Sandeen" Cc: pac@fortuitous.com, linux-xfs@oss.sgi.com Subject: Re: 2.4.8 devel snapshot patch available References: <3B7818B0.FEF6356@sgi.com> <20010814191107.A18246@bistro.marx> <3B79DAA6.E85BC57E@sgi.com> X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E In-Reply-To: <3B79DAA6.E85BC57E@sgi.com> From: Vincent Bernat Date: 15 Aug 2001 13:14:11 +0200 Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) 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 OoO En ce milieu de nuit étoilée du mercredi 15 août 2001, vers 04:12, Eric Sandeen disait: > The "non-cvs" patch will just patch up a kernel to the state cvs was in > at the time, but does not construct a whole cvs tree. I have seen there is some issues with 2.4.8. Will you realease a new patch for it (if there is no new kernel in the meantime) when this will be fixed or do we have to track CVS changes ? From owner-linux-xfs@oss.sgi.com Wed Aug 15 14:21:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FLLBG05735 for linux-xfs-outgoing; Wed, 15 Aug 2001 14:21:11 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FLL9j05714 for ; Wed, 15 Aug 2001 14:21:09 -0700 Received: (qmail 88999 invoked from network); 15 Aug 2001 21:21:10 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop2.mpls.uswest.net with SMTP; 15 Aug 2001 21:21:10 -0000 Date: Wed, 15 Aug 2001 16:18:05 -0500 Message-ID: <3B7AE70D.62A73DAB@sgi.com> From: "Eric Sandeen" To: "Vincent Bernat" Cc: pac@fortuitous.com, linux-xfs@oss.sgi.com 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 Subject: Re: 2.4.8 devel snapshot patch available References: <3B7818B0.FEF6356@sgi.com> <20010814191107.A18246@bistro.marx> <3B79DAA6.E85BC57E@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Vincent Bernat wrote: > I have seen there is some issues with 2.4.8. Will you realease a new > patch for it (if there is no new kernel in the meantime) when this > will be fixed or do we have to track CVS changes ? There is a new patch as of this morning that fixes known XFS issues with 2.4.8 -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 Aug 15 14:24:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FLO1J06468 for linux-xfs-outgoing; Wed, 15 Aug 2001 14:24:01 -0700 Received: from frodo.ezprohosting.com ([216.74.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FLNuj06419 for ; Wed, 15 Aug 2001 14:23:56 -0700 Received: from c922720-a.sttln1.wa.home.com ([65.0.77.21] helo=windows) by frodo.ezprohosting.com with smtp (Exim 3.20 #1) id 15X88j-00024U-00 for linux-xfs@oss.sgi.com; Wed, 15 Aug 2001 17:23:49 -0400 Message-ID: <007201c125d0$06b205c0$020144c0@windows> From: "Eric Peters" To: Subject: ACL hierarchy & getfacl/setfacl ACE Ordering possibly fixed doing... Date: Wed, 15 Aug 2001 14:19:50 -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 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - frodo.ezprohosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - peters.org Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry I kinda cluster-frelled this email with probably two different threads :) I was writing the first ACl hierarchy question while I think I fixed the ACE ordering LOL This question is a little out of blue I suppose, but i'm looking to hopefully setup a system of directory permission access so I can have: /home/user1 /home/user1/subuser1 /home/user1/subuser1/subuser1subuser1 /home/user1/subuser1/subuser1subuser2 /home/user1/subuser2 Type of heirachy where the user1 can access everything under his /home/user1, subuser1 can access everything under his subuser1 home directory, and subuser2 acccess to his directory and etc. What type of configuration would need to be implemented so that ACLs would handle all of this. Basically I want the "controlling" account "user1" to be able and access any "subuser1", "subuser2" files, where "subuser1" also has access to his child accounts "subuser1subuser1", and "subuser1subuser2" (user1 could also access these/his "children's"-"child" accounts) The runtime problems I've had so far include when creating "files" - the executable bits often get set automatically (based upon defaults for a directory) - but if I dont' have the default x then a sub directory that gets created won't be able to be accessible as it doesn't have the +x bit. are there any specific umask flags or something I could set in the FTP Daemon or the shell profile which would remedy this? also If I go through and find ./ -type f -print0 | xargs -0 chacl files then it'll totally screw up "individually" delgated permissions for files if I were to have a means of "updating" permissions are there better ways to keep permissions? I recently started messing with the setfacl and getfacl commands as well, the recent quote "Andreas' code, however, does _not_ require the ACEs to be ordered from the user - unsurprisingly, his code sorts them. However, in the port of setfacl and associated missing libacl functions, it appears that something has gone wrong because unless the ACEs are in the correct order when given as an argument to setfacl, it gives an error message." I sure can't see where it sorts them :) It appears that the find_acl functions just look for the particular hosts rather than being dependant on the ordering... I do however see a ./include/acl.h:extern void acl_entry_sort (acl_t __acl); which could be called in the do_set() function - though I'm not sure if that is an appropriate place - I inserted a acl_entry_sort(acl); infront of: error = acl_check(acl, &which_entry); and a acl_entry_sort(default_acl); infton of: error = acl_check(default_acl, &which_entry); in: int do_set( const char *path_p, struct stat *st, .... in the do_set.c and I'm not getting the ordering error any longer... ( i havn't tested it enough to see if this really cleaned it up sorry - just toying with XFS at the moment :) I replicated the previous post on the ACE bug: [root@localhost er1c]# getfacl 1111 # file: 1111 # owner: root # group: root user::rwx group::rwx other::rwx user:er1c:rwx mask::rwx default:user::rwx default:group::rwx default:other::rwx default:user:er1c:rwx default:mask::rwx [root@localhost er1c]# setfacl -d -x u:er1c 1111 lt-setfacl: 1111: Resulting default ACL `user::rwx,group::rwx,other::rwx,mask::rwx': Missing or wrong entry at entry 4 after applying the "patch": [root@localhost er1c]# /usr/bin/setfacl -d -x u:er1c 1111 [root@localhost er1c]# getfacl 1111 # file: 1111 # owner: root # group: root user::rwx group::rwx other::rwx user:er1c:rwx mask::rwx default:user::rwx default:group::rwx default:mask::rwx default:other::rwx Cheers & Thanks, Eric From owner-linux-xfs@oss.sgi.com Wed Aug 15 19:52:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G2qcW04083 for linux-xfs-outgoing; Wed, 15 Aug 2001 19:52:38 -0700 Received: from mx.linux.net.cn ([210.52.24.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G2qZj04058 for ; Wed, 15 Aug 2001 19:52:36 -0700 Received: from dfbbb.cn.mvd (unknown [211.99.247.66]) by mx.linux.net.cn (Postfix) with ESMTP id 81CF7CCB for ; Thu, 16 Aug 2001 10:48:54 +0800 (CST) Received: (from dfbb@localhost) by dfbbb.cn.mvd (8.11.2/8.11.2) id f7G2rk109938 for linux-xfs@oss.sgi.com; Thu, 16 Aug 2001 10:53:46 +0800 Date: Thu, 16 Aug 2001 10:53:46 +0800 From: Fang Han To: linux-xfs@oss.sgi.com Subject: LVM 1.0 is released Message-ID: <20010816105345.A1664@dfbbb.cn.mvd> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, LVM 1.0 is announced, When XFS cvs tree will upgrade to that version? I think LVM 0.9.1_beta6 is the stable version working with XFS. Is it right? Dan From owner-linux-xfs@oss.sgi.com Wed Aug 15 19:59:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G2xrs05224 for linux-xfs-outgoing; Wed, 15 Aug 2001 19:59:53 -0700 Received: from mplspop6.mpls.uswest.net (pop.mpls.uswest.net [204.147.80.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G2xpj05198 for ; Wed, 15 Aug 2001 19:59:51 -0700 Received: (qmail 37649 invoked from network); 16 Aug 2001 02:59:53 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop6.mpls.uswest.net with SMTP; 16 Aug 2001 02:59:53 -0000 Date: Wed, 15 Aug 2001 21:56:48 -0500 Message-ID: <3B7B3670.4B9C5275@sgi.com> From: "Eric Sandeen" To: "Fang Han" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: LVM 1.0 is released References: <20010816105345.A1664@dfbbb.cn.mvd> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fang Han wrote: > > Hi, LVM 1.0 is announced, When XFS cvs tree will upgrade to that version? "When it's ready.(tm)" :-) Martin says he's working on it, (or will be soon.) > I think LVM 0.9.1_beta6 is the stable version working with XFS. Is it right? Yes, that is correct. -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 Aug 15 20:37:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G3biV09918 for linux-xfs-outgoing; Wed, 15 Aug 2001 20:37:44 -0700 Received: from frodo.ezprohosting.com ([216.74.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G3bfj09899 for ; Wed, 15 Aug 2001 20:37:41 -0700 Received: from c922720-a.sttln1.wa.home.com ([65.0.77.21] helo=windows) by frodo.ezprohosting.com with smtp (Exim 3.20 #1) id 15XDyH-00035E-00; Wed, 15 Aug 2001 23:37:26 -0400 Message-ID: <027401c12604$39dbdf00$020144c0@windows> From: "Eric Peters" To: "Fang Han" , References: <20010816105345.A1664@dfbbb.cn.mvd> Subject: Re: LVM 1.0 is released Date: Wed, 15 Aug 2001 20:33:29 -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 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - frodo.ezprohosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - peters.org Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At the risk of sounding ignorant, what's LVM and how does it effect XFS :) Thanks! Eric ----- Original Message ----- From: "Fang Han" To: Sent: Wednesday, August 15, 2001 7:53 PM Subject: LVM 1.0 is released > > Hi, LVM 1.0 is announced, When XFS cvs tree will upgrade to that version? > > I think LVM 0.9.1_beta6 is the stable version working with XFS. Is it right? > > > Dan > > From owner-linux-xfs@oss.sgi.com Wed Aug 15 21:07:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G47ej10689 for linux-xfs-outgoing; Wed, 15 Aug 2001 21:07:40 -0700 Received: from web11705.mail.yahoo.com (web11705.mail.yahoo.com [216.136.172.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G47cj10670 for ; Wed, 15 Aug 2001 21:07:38 -0700 Message-ID: <20010816040738.88980.qmail@web11705.mail.yahoo.com> Received: from [24.151.81.31] by web11705.mail.yahoo.com; Wed, 15 Aug 2001 21:07:38 PDT Date: Wed, 15 Aug 2001 21:07:38 -0700 (PDT) From: Sean Elble Subject: Re: LVM 1.0 is released To: Eric Peters , Fang Han , linux-xfs@oss.sgi.com In-Reply-To: <027401c12604$39dbdf00$020144c0@windows> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk LVM is the logical volume manager; it essentially lets you have multiple disks act like one single partition. XFS is a very good canidate for LVM because of its ability to handle large volumes well, with reliability, speed, and efficency. And, on another note, its never ignorant to ask questions (unless of course, the answer is in an obvious spot :-) ). Have a good one! Sean Elble --- Eric Peters wrote: > At the risk of sounding ignorant, what's LVM and how > does it effect XFS :) > > Thanks! > > Eric > > ----- Original Message ----- > From: "Fang Han" > To: > Sent: Wednesday, August 15, 2001 7:53 PM > Subject: LVM 1.0 is released > > > > > > Hi, LVM 1.0 is announced, When XFS cvs tree will > upgrade to that version? > > > > I think LVM 0.9.1_beta6 is the stable version > working with XFS. Is it > right? > > > > > > Dan > > > > > __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-xfs@oss.sgi.com Wed Aug 15 21:08:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G48oS10772 for linux-xfs-outgoing; Wed, 15 Aug 2001 21:08:50 -0700 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 f7G48mj10747 for ; Wed, 15 Aug 2001 21:08:48 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7G4DaS20928 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 15 Aug 2001 21:13:36 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id GAA42538 for ; Thu, 16 Aug 2001 06:08:40 +0200 (CEST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA98323; Thu, 16 Aug 2001 14:07:19 +1000 (EST) Date: Thu, 16 Aug 2001 14:07:19 +1000 From: Timothy Shimmin To: Steve Lord Cc: Andi Kleen , Ken Cross , Linux XFS Subject: Re: SPEC failures Message-ID: <20010816140719.B101292@boing.melbourne.sgi.com> References: <200108151934.f7FJYLP01380@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200108151934.f7FJYLP01380@jen.americas.sgi.com>; from lord@sgi.com on Wed, Aug 15, 2001 at 02:34:21PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 15, 2001 at 02:34:21PM -0500, Steve Lord wrote: > > On Wed, Aug 15, 2001 at 10:30:46AM -0500, Steve Lord wrote: > > > Andrew had the approach of setting the umask of the nfsd process to 0 at > > > startup, there was some other reason for this not being popular. > > > > He did it for init_task, which disturbed all other kernel threads too > > and opened tons of security holes. > > The right way IMHO is to give nfsd an own fs_struct and set umask there, > > as in this patch. > > > > -Andi > > Thanks, > > Care to try this one on Neil Brown or Trond? > I wonder if the acl project > has run into the same issue? I would say the answer is yes. On Aug 2, Andreas released a new patch, 0.7.15, for the 2.4.7 kernel. Having a quick scan of the patch he has definitely changed where the umask is applied in the case of no default ACL. He has also patched some nfsd code. It would be worth going through this patch carefully...:) > The tricky part in justifying this is nothing > in the main kernel needs this change right now. > Just to be sure I understand what is going on... Previously, the umask was applied to the mode in vfs_mkdir(), vfs_mknod() and vfs_create(). In 2.4.7, the umask code was moved to sys_mkdir(), sys_mknod() and open_namei() respectively, to just before where the vfs_*() calls are being made. The other caller of these particular vfs_*() calls is nfsd_create [linux/fs/nfsd/vfs.c]. So by moving the umask code out it means that nfsd_create() will no longer be calling the vfs functions which were setting the umask. But in the XFS inode operations, where we set up linvfs_create(), linvfs_mkdir() and linvfs_mknod(), we are still applying the umask if no default ACL exists. --Tim From owner-linux-xfs@oss.sgi.com Wed Aug 15 21:17:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G4HcB11226 for linux-xfs-outgoing; Wed, 15 Aug 2001 21:17:38 -0700 Received: from monmouth.edu (8e.dmz.monmouth.edu [206.30.71.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G4HYj11204 for ; Wed, 15 Aug 2001 21:17:34 -0700 Received: by monmouth.edu; id AAA08629; Thu, 16 Aug 2001 00:18:24 -0400 (EDT) Received: from cc247150-a.union1.nj.home.com(24.6.72.45) by webshield.monmouth.edu via csmap (V4.1) id srcAAAVUaG2q; Thu, 16 Aug 01 00:18:24 -0400 From: "Robert Carsey" To: Subject: RE: LVM 1.0 is released Date: Thu, 16 Aug 2001 00:17:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010816040738.88980.qmail@web11705.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk there are inherent problems with any filesystem like xfs, ext2, reiser... namely, you cant grow/shrink a filesystem without the sysadmin doing a lot of work. -- copying all the files off the partition, repartitioning, copying files back. Eek, maybe even a worse case is what happens when /home is 10G and tomorrow it needs to be 500GB? wish you could make /home span across multiple disks eh? What LVM does is it sits between the physical disks (or hardware raid array) and XFS (or ext2 or reiser). The filesystem thinks it resides on an honest-to-god disk/array, but in reality, xfs is talking to a virtual disk. If you need to make your /home 'partition' larger.. say, if a lot of your users like to download .mp3's :-), what you can do is tell LVM to make the /home partition bigger. Of course, just because the disk size magically changed from 5G to 10G, doesn't mean that xfs,ext2,etc knows about it. so then you also have to tell xfs to resize the filesystem. I've set up an NFS server, serving about 10 client machines. Each client has its own 'space' on the NFS server... i've allocated space for my WWW server, some space for a development server, some for homedirectories..etc etc. I don't know which partition will eventually run out of space first... and it'd really suck to take down my hefty NFS server to repartition -- actually, it would royally suck because if the NFS server is down, all 10 of my client machines cant operate either.... I'd really recommend you play with it, i think you'll like it. Just remember that you have to ste up the actual disks for LVM (using the pvcreate command) [Physical Volume] (this is performed on something like /dev/hdb1). Once you have all your disks initialized, you put them into a disk group which can be thought of as a "pool of storage space" by using the vgcreate command (if you name the group "data_group", then you'll see a /dev/data_group directory). And then the last step is to make a logical volume--this is the actual block device that you'll tell mkfs to format. You use the lvcreate command and you specify how much space this new virtual-disk will have.. and which volume-group to. (you'll get something like /dev/data_group/lvol1 -- which you can do a mkfs on and mount it). --- Eric Peters wrote: > At the risk of sounding ignorant, what's LVM and how > does it effect XFS :) > > Thanks! > > Eric > > ----- Original Message ----- > From: "Fang Han" > To: > Sent: Wednesday, August 15, 2001 7:53 PM > Subject: LVM 1.0 is released > > > > > > Hi, LVM 1.0 is announced, When XFS cvs tree will > upgrade to that version? > > > > I think LVM 0.9.1_beta6 is the stable version > working with XFS. Is it > right? > > > > > > Dan > > > > > __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-xfs@oss.sgi.com Wed Aug 15 22:19:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G5JH312592 for linux-xfs-outgoing; Wed, 15 Aug 2001 22:19:17 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G5JFj12573 for ; Wed, 15 Aug 2001 22:19:15 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA20830; Thu, 16 Aug 2001 07:18:07 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA19586; Thu, 16 Aug 2001 07:18:07 +0200 (CEST) Date: Thu, 16 Aug 2001 07:18:07 +0200 (CEST) From: Seth Mos To: Fang Han cc: linux-xfs@oss.sgi.com Subject: Re: LVM 1.0 is released In-Reply-To: <20010816105345.A1664@dfbbb.cn.mvd> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 16 Aug 2001, Fang Han wrote: > > Hi, LVM 1.0 is announced, When XFS cvs tree will upgrade to that version? When time permits and the linus tree also moves to 1.0. This is to keep the differences down. > I think LVM 0.9.1_beta6 is the stable version working with XFS. Is it right? Yes. LVM needed a bit of education on XFS IIRC and this version has it. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Aug 16 03:23:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GANnA22280 for linux-xfs-outgoing; Thu, 16 Aug 2001 03:23:49 -0700 Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GANjj22260 for ; Thu, 16 Aug 2001 03:23:46 -0700 Received: (qmail 11563 invoked by uid 0); 16 Aug 2001 10:23:39 -0000 Received: from pd904de60.dip.t-dialin.net (HELO powstat) (217.4.222.96) by mail.gmx.net (mail07) with SMTP; 16 Aug 2001 10:23:39 -0000 From: "christian mueller" To: linux-xfs@oss.sgi.com Date: Thu, 16 Aug 2001 12:25:04 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: minor problem with Message-ID: <3B7BBBA0.24974.12C2BAD@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi all, xfsprogs-1.3.5: make fails in libdisk/liblvm.h at line 46 #include on my SuSE 7.2 system. this is possible a little out of topic... on my system /usr/include/asm and /usr/include/linux aren't links to the kernelsrc-tree (current is linux-2.4.8-xfs) /usr/src/linux/... i guess they are copies from original SuSE-2.4.4 kernel. in there is no autoconf.h included. i looked myself at the FHS v2.1 on my system (homepage is down) and that explains... <...> 6.1.5 /usr/include : Header files included by C programs These symbolic links are required if a C or C++ compiler is installed and only for systems not based on glibc. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /usr/include/asm -> /usr/src/linux/include/asm- /usr/include/linux -> /usr/src/linux/include/linux 6.1.6 /usr/src : Source code <...> The only source code that should be placed in a specific location is the Linux kernel source code. It is located in /usr/src/linux. If a C or C++ compiler is installed, but the complete Linux kernel source code is not installed, then the include files from the kernel source code shall be located in these directories: /usr/src/linux/include/asm- /usr/src/linux/include/linux <...> BEGIN RATIONALE It is important that the kernel include files be located in /usr/src/linux and not in /usr/include so there are no problems when system administrators upgrade their kernel version for the first time. END RATIONALE <...> should these dirs always stay up-to-date with the current installed kernelsrc-tree or is it a configure/autoconf problem that should look into /usr/src/linux/include/ ? -chris btw xfsprogs-1.3.1 and other non-XFS-sources, make runs fine. From owner-linux-xfs@oss.sgi.com Thu Aug 16 05:43:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GChnX27126 for linux-xfs-outgoing; Thu, 16 Aug 2001 05:43:49 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GChkj27107 for ; Thu, 16 Aug 2001 05:43:46 -0700 Received: (qmail 31560 invoked from network); 16 Aug 2001 12:43:43 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Aug 2001 12:43:43 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "christian mueller" cc: linux-xfs@oss.sgi.com Subject: Re: minor problem with In-reply-to: Your message of "Thu, 16 Aug 2001 12:25:04 +0200." <3B7BBBA0.24974.12C2BAD@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Aug 2001 22:43:42 +1000 Message-ID: <16831.997965822@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 16 Aug 2001 12:25:04 +0200, "christian mueller" wrote: >xfsprogs-1.3.5: make fails in libdisk/liblvm.h at line 46 >#include >on my SuSE 7.2 system. The only reason to include autoconf.h is to extract the values of CONFIG_ variables. The only reference to CONFIG_ in libdisk is to test for s390. So unless you are building on s390, you can remove #include . We will look at building xfsprogs without autoconf, there is no guarantee that a distribution will install that file. From owner-linux-xfs@oss.sgi.com Thu Aug 16 05:44:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GCipZ27197 for linux-xfs-outgoing; Thu, 16 Aug 2001 05:44:51 -0700 Received: from mplspop4.mpls.uswest.net (mplspop4.mpls.uswest.net [204.147.80.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GCinj27177 for ; Thu, 16 Aug 2001 05:44:49 -0700 Received: (qmail 29061 invoked from network); 16 Aug 2001 12:44:46 -0000 Received: from mplsdslgw14poola24.mpls.uswest.net (HELO beaver.iucha.org) (63.229.192.24) by mplspop4.mpls.uswest.net with SMTP; 16 Aug 2001 12:44:46 -0000 Received: (from florin@localhost) by beaver.iucha.org (8.11.3/8.11.3) id f7GCij916531; Thu, 16 Aug 2001 07:44:45 -0500 (CDT) Date: Thu, 16 Aug 2001 07:44:43 -0500 Message-ID: <20010816074443.A7925@beaver.iucha.org> From: "Florin Iucha" To: "Steve Lord" Cc: linux-xfs@oss.sgi.com Subject: Re: oops with 2.4.8-xfs References: <200108151338.f7FDcFA32694@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108151338.f7FDcFA32694@jen.americas.sgi.com>; from lord@sgi.com on Wed, Aug 15, 2001 at 08:38:15AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 15, 2001 at 08:38:15AM -0500, Steve Lord wrote: > > I have got the oops too. > > > > I have a cron backup script that runs at 4 am and used to make a tar archive > > of > > a reiserfs directory. Last Sunday I converted the partition to xfs and the > > script to use tar. > > > > What is interesting is the fact that if I run the script from the interactive > > session it works fine; it crashes only when run from the cron. > > > > I am using 2.4.8-xfs with > > xfsdump-1.0.9 > > xfsprogs-1.3.4-0 > > from Debian unstable/testing on a _dual_ P90. > > I just placed new patches on oss for 2.4.8, can you possibly try these, there > were at least a couple of bugs which needed working out of the original > 2.4.8 checkin. CVS 2.4.8-xfs from yesterday morning fixed the problem. Thank you, florin -- "If it's not broken, is because you are not fixing it enough." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4 From owner-linux-xfs@oss.sgi.com Thu Aug 16 06:36:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GDa0O28718 for linux-xfs-outgoing; Thu, 16 Aug 2001 06:36:00 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GDZvj28699 for ; Thu, 16 Aug 2001 06:35:57 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.31 #1) id 15XNJK-0001G7-00; Thu, 16 Aug 2001 15:35:47 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f7GDaBN03801; Thu, 16 Aug 2001 09:36:11 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Eric Sandeen" Cc: "Fang Han" , linux-xfs@oss.sgi.com Subject: Re: LVM 1.0 is released References: <20010816105345.A1664@dfbbb.cn.mvd> <3B7B3670.4B9C5275@sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 16 Aug 2001 09:36:11 -0400 In-Reply-To: <3B7B3670.4B9C5275@sgi.com> Message-ID: Lines: 16 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 >>>>> "Eric" == Eric Sandeen writes: >> Hi, LVM 1.0 is announced, When XFS cvs tree will upgrade to that >> version? Eric> "When it's ready.(tm)" :-) Martin says he's working on it, (or Eric> will be soon.) Yep. Since the LVM folks didn't provide a migration path (*sigh*) I need that in place first, though. I don't want to cut off the users out there with existing installations. -- 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 Aug 16 08:41:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GFfeh32180 for linux-xfs-outgoing; Thu, 16 Aug 2001 08:41:40 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GFfcj32160 for ; Thu, 16 Aug 2001 08:41:38 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 10:40:49 -0500 Message-ID: <85063BBE668FD411944400D0B744267A6436DF@AUSMAIL> From: "Gonyou, Austin" To: "'Martin K. Petersen'" , Eric Sandeen Cc: Fang Han , linux-xfs@oss.sgi.com Subject: RE: LVM 1.0 is released Date: Thu, 16 Aug 2001 10:40:49 -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 Yeah. I experienced this first hand. I upgraded LVM, and then I couldn't use my XFS filesystems that were on the LV's anymore. I reformatted them, and all was fine. Good thing it wasn't production. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Martin K. Petersen [mailto:mkp@linuxcare.com] > Sent: Thursday, August 16, 2001 8:36 AM > To: Eric Sandeen > Cc: Fang Han; linux-xfs@oss.sgi.com > Subject: Re: LVM 1.0 is released > > > >>>>> "Eric" == Eric Sandeen writes: > > >> Hi, LVM 1.0 is announced, When XFS cvs tree will upgrade to that > >> version? > > Eric> "When it's ready.(tm)" :-) Martin says he's working on it, (or > Eric> will be soon.) > > Yep. Since the LVM folks didn't provide a migration path (*sigh*) I > need that in place first, though. I don't want to cut off the users > out there with existing installations. > > -- > 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 Aug 16 12:15:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GJFF805214 for linux-xfs-outgoing; Thu, 16 Aug 2001 12:15:15 -0700 Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GJFDj05194 for ; Thu, 16 Aug 2001 12:15:13 -0700 Received: from webmail.worldnet.att.net ([204.127.135.40]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010816191507.BKOM15499.mtiwmhc22.worldnet.att.net@webmail.worldnet.att.net> for ; Thu, 16 Aug 2001 19:15:07 +0000 Received: from [208.253.203.116] by webmail.worldnet.att.net; Thu, 16 Aug 2001 19:15:07 +0000 From: mmontegut@att.net To: linux-xfs@oss.sgi.com Subject: FS Buff cache taking all the memory Date: Thu, 16 Aug 2001 19:15:07 +0000 X-Mailer: AT&T Message Center Version 1 (May 2 2001) Message-Id: <20010816191507.BKOM15499.mtiwmhc22.worldnet.att.net@webmail.worldnet.att.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I had a question about the memory access (specifically the buffer cache) behavior of the files systems on REDHAT 7.1 with the 2.4.2 kernal . uname -a reports: Linux 2.4.2-SGI_XFS_1.0smp #1 SMP Fri Apr 27 19:07:34 CDT 2001 i686 unknown The problem is that LINUX appears to be gradually use up all the memory as you open and access more and more files. We are just reading the files at this point. Eventually the system (we record this with top) runs so low on memory that it become unstable. The file system does not appear to relinquish the memory in time to keep applications that need memory stable. Is there some sort of tuning parameters for XFS or ext2 that would help this? Any help is greatly appreciated. Michael From owner-linux-xfs@oss.sgi.com Thu Aug 16 12:30:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GJUmh05764 for linux-xfs-outgoing; Thu, 16 Aug 2001 12:30:48 -0700 Received: from issun6.hti.com (sunmgr.hti.com [130.210.206.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GJUkj05744 for ; Thu, 16 Aug 2001 12:30:46 -0700 Received: from issun5.hti.com ([130.210.202.3]) by issun6.hti.com (Netscape Messaging Server 3.6) with ESMTP id AAA415B for ; Thu, 16 Aug 2001 14:25:48 -0500 Received: from link.com ([130.210.69.180]) by issun5.hti.com (Netscape Messaging Server 3.6) with ESMTP id AAA35F6 for ; Thu, 16 Aug 2001 14:30:39 -0500 Message-ID: <3B7C1F36.5A86335B@link.com> Date: Thu, 16 Aug 2001 14:29:58 -0500 From: "Jeffrey K Butkovich" Organization: L3 Link Simulation and Training X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Diskless Content-Type: multipart/mixed; boundary="------------4641CE22739316DAC1F59EB3" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------4641CE22739316DAC1F59EB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a RedHat 7.1 machine setup with the SGI XFS filesystem. It works great. However, I'm trying to set this machine up as a server for diskless machines. We are using vmic single board computers and like the capabilities of the XFS filesystem. We want to use a diskless solution so we won't need to maintain as many SBC's. Just setup for net boot, then we're done. I'm having trouble doing this. The kernel net boot image is too big. Do you know what I can do to overcome this? Do you know of anyone that has succeeded in doing this? Please forgive me if these next questions sound stupid, This is my first crack at setting up a diskless workstation. Possibly could I shrink the kernel by making the XFS support a module? If I did this, where would the kernel load the module from? ...since no filesystems would be mounted at this time. Am I out of Luck? Thanks in advance for your help, Jeff Butkovich --------------4641CE22739316DAC1F59EB3 Content-Type: text/x-vcard; charset=us-ascii; name="jkbutkovich.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jeffrey K. Butkovich Content-Disposition: attachment; filename="jkbutkovich.vcf" begin:vcard n:Butkovich;Jeff tel;fax:X-4021 tel;work:X-8631 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:td22913@link.com x-mozilla-cpt:;-1 fn:Jeff Butkovich end:vcard --------------4641CE22739316DAC1F59EB3-- From owner-linux-xfs@oss.sgi.com Thu Aug 16 12:44:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GJitp06142 for linux-xfs-outgoing; Thu, 16 Aug 2001 12:44:55 -0700 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 f7GJisj06123 for ; Thu, 16 Aug 2001 12:44:54 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7GJni817914 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 16 Aug 2001 12:49:45 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA102462 for ; Thu, 16 Aug 2001 21:44:47 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2725863; Thu, 16 Aug 2001 14:43:29 -0500 (CDT) Received: from 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 OAA72188; Thu, 16 Aug 2001 14:43:29 -0500 (CDT) Message-ID: <3B7C225F.1CFC0FFB@sgi.com> Date: Thu, 16 Aug 2001 14:43:27 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey K Butkovich CC: linux-xfs@oss.sgi.com Subject: Re: Diskless References: <3B7C1F36.5A86335B@link.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jeffrey K Butkovich wrote: > I'm having trouble doing this. The kernel net boot image is too big. Too big for what? I'm not well versed in net booting, but I thought it just NFS mounted a remote filesystem to get it's kernel? If there's some type of restriction on the size of an actual kernel image, would an initial ramdisk help you? (man mkinitrd). -Eric From owner-linux-xfs@oss.sgi.com Thu Aug 16 12:49:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GJnNq06390 for linux-xfs-outgoing; Thu, 16 Aug 2001 12:49:23 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GJnLj06371 for ; Thu, 16 Aug 2001 12:49:21 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.31 #1) id 15XT8m-0001cp-00; Thu, 16 Aug 2001 21:49:17 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f7GJnbB03975; Thu, 16 Aug 2001 15:49:37 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Jeffrey K Butkovich" Cc: linux-xfs@oss.sgi.com Subject: Re: Diskless References: <3B7C1F36.5A86335B@link.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 16 Aug 2001 15:49:36 -0400 In-Reply-To: <3B7C1F36.5A86335B@link.com> 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 >>>>> "Jeff" == Jeffrey K Butkovich writes: Jeff> We are using vmic single board computers and like the Jeff> capabilities of the XFS filesystem. We want to use a diskless Jeff> solution so we won't need to maintain as many SBC's. Just setup Jeff> for net boot, then we're done. Jeff> I'm having trouble doing this. The kernel net boot image is too Jeff> big. If the clients are diskless, why do you need XFS in the net boot image? -- 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 Aug 16 12:49:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GJnq806507 for linux-xfs-outgoing; Thu, 16 Aug 2001 12:49:52 -0700 Received: from codon.com (gingerstamp.com [64.78.130.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GJnoj06486 for ; Thu, 16 Aug 2001 12:49:50 -0700 Received: (qmail 9698 invoked by uid 516); 16 Aug 2001 20:01:13 -0000 Received: from nw@codon.com by helix with qmail-scanner-0.96 (. Clean. Processed in 0.051742 secs); 16 Aug 2001 20:01:13 -0000 Received: from weasel.local.iboats.com (HELO weasel) (64.78.130.80) by codon.com with SMTP; 16 Aug 2001 20:01:13 -0000 Message-ID: <001901c1268c$01873680$50824e40@iboats.com> From: "Steve Wolfe" To: References: <3B7C1F36.5A86335B@link.com> <3B7C225F.1CFC0FFB@sgi.com> Subject: Re: Diskless Date: Thu, 16 Aug 2001 13:45:28 -0600 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 > > I'm having trouble doing this. The kernel net boot image is too big. > > Too big for what? I'm not well versed in net booting, but I thought it > just NFS mounted a remote filesystem to get it's kernel? If there's > some type of restriction on the size of an actual kernel image, would an > initial ramdisk help you? (man mkinitrd). I would guess that he means "too big to fit in the flash RAM", in which case, use a bigger flash RAM, use fewer kernel features, and/or use "make bzImage", not "make zImage". steve From owner-linux-xfs@oss.sgi.com Thu Aug 16 12:56:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GJuoh06772 for linux-xfs-outgoing; Thu, 16 Aug 2001 12:56:50 -0700 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 f7GJumj06752 for ; Thu, 16 Aug 2001 12:56:48 -0700 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 f7GK1d818848 for ; Thu, 16 Aug 2001 13:01:39 -0700 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 OAA2732139; Thu, 16 Aug 2001 14:55:27 -0500 (CDT) Received: from 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 OAA65748; Thu, 16 Aug 2001 14:55:27 -0500 (CDT) Message-ID: <3B7C252D.2A4E481D@sgi.com> Date: Thu, 16 Aug 2001 14:55:25 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey K Butkovich , linux-xfs@oss.sgi.com Subject: Re: Diskless References: <3B7C1F36.5A86335B@link.com> <3B7C225F.1CFC0FFB@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: > I'm not well versed in net booting, but I thought it > just NFS mounted a remote filesystem to get it's kernel? Uh... ok turn brain on, Eric. How do you NFS mount something w/o a kernel? :) I'll leave this to someone who knows what they're talking about. :) From owner-linux-xfs@oss.sgi.com Thu Aug 16 13:00:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GK0ES06987 for linux-xfs-outgoing; Thu, 16 Aug 2001 13:00:14 -0700 Received: from acmez.gatech.edu (acmez.gatech.edu [130.207.165.24]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GK0Cj06968 for ; Thu, 16 Aug 2001 13:00:12 -0700 Received: from [130.207.197.237] ([130.207.197.237]) by acmez.gatech.edu (8.9.2/8.9.2) with ESMTP id QAA14861; Thu, 16 Aug 2001 16:00:04 -0400 (EDT) Subject: Re: Diskless From: Rob Myers To: Jeffrey K Butkovich Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B7C225F.1CFC0FFB@sgi.com> References: <3B7C1F36.5A86335B@link.com> <3B7C225F.1CFC0FFB@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12.99 (Preview Release) Date: 16 Aug 2001 16:03:04 -0400 Message-Id: <997992185.514.130.camel@ransom> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk jeff- are you trying to do pure network booting? (ie, not nfsroot) if you havent checked out the network interface loader, do so at: http://www.nilo.org/ i remember vanilla pxe boot having a limit of a 512kb kernel (either due to pxe or the tftp server i was using) a few years ago, but it looks like there are several work arounds for this now. i doubt that you could compile your own kernel and get xfs and all the other bits you needed into an image that small. but it may be worth a shot, and let the list know of your success or failure ;) fwiw, i considered it a victory when i got xfs and all the hardware support parts i needed onto a floppy for nfs booting. ;) good luck! rob. On 16 Aug 2001 14:43:27 -0500, Eric Sandeen wrote: > Jeffrey K Butkovich wrote: > > > I'm having trouble doing this. The kernel net boot image is too big. > > Too big for what? I'm not well versed in net booting, but I thought it > just NFS mounted a remote filesystem to get it's kernel? If there's > some type of restriction on the size of an actual kernel image, would an > initial ramdisk help you? (man mkinitrd). > > -Eric From owner-linux-xfs@oss.sgi.com Thu Aug 16 13:25:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GKPcC07843 for linux-xfs-outgoing; Thu, 16 Aug 2001 13:25:38 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GKPZj07824 for ; Thu, 16 Aug 2001 13:25:35 -0700 Received: from [195.20.224.208] (helo=mrvdom01.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15XThs-00007A-00; Thu, 16 Aug 2001 22:25:32 +0200 Received: from pd901e3b3.dip.t-dialin.net ([217.1.227.179] helo=kernelpanix.aura.of.mankind) by mrvdom01.schlund.de with esmtp (Exim 2.12 #2) id 15XThr-0003Nh-00; Thu, 16 Aug 2001 22:25:32 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f7GJnDW04405; Thu, 16 Aug 2001 21:49:13 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Thu, 16 Aug 2001 21:49:13 +0200 From: utz lehmann To: Jeffrey K Butkovich Cc: linux-xfs@oss.sgi.com Subject: Re: Diskless Message-ID: <20010816214913.A4223@s2y4n2c.de> References: <3B7C1F36.5A86335B@link.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7C1F36.5A86335B@link.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I dont think you need the net boot image at all. Look at etherboot (http://etherboot.sourceforge.net/) The booting works this way: 1. Diskless computer (DC) broadcasts MAC address with bootp: Who am I? 2. Bootp or DHCP server on S looks up DB: Your IP address is X.X.X.X, your server is S, your boot file is vmlinuz.myname, etc. 3. DC asks to load file from TFTP server on S: Please give me vmlinuz.myname 4. S: Here you are (/tftpdir/vmlinuz.myname) DC thinks a while (booting Linux). 5. DC: Please let me mount / with NFS 6. S: Here is your root FS (/tftpboot/IPnumber). (In 2.2 kernels, /tftpboot/domainname.) 7. DC: Please let me mount other NFSes (/usr, /home/, etc) 8. S: Here you are 9. DC: Runs intended application Network boot ROM contains code to do 1 and 3. The kernel image is on the server and tranfered via tftp. Be carefull with the tftp server setup. A wrong setup is a security hole. chrooting the tftp server is really necessary. Many years ago, a had a linux based diskless X terminal booting with etherboot. have fun. utz Jeffrey K Butkovich [jkbutkovich@link.com] wrote: > Hi, > > I have a RedHat 7.1 machine setup with the SGI XFS filesystem. > > It works great. > > However, I'm trying to set this machine up as a server for > diskless machines. > > We are using vmic single board computers and like the capabilities of > the XFS filesystem. We want to use a diskless solution so we won't > need to maintain as many SBC's. Just setup for net boot, then we're done. > > I'm having trouble doing this. The kernel net boot image is too big. > > Do you know what I can do to overcome this? > > Do you know of anyone that has succeeded in doing this? > > Please forgive me if these next questions sound stupid, This is my > first crack at setting up a diskless workstation. > > Possibly could I shrink the kernel by making the XFS support a module? > If I did this, where would the kernel load the module from? ...since > no filesystems would be mounted at this time. > > Am I out of Luck? > > Thanks in advance for your help, > > Jeff Butkovich From owner-linux-xfs@oss.sgi.com Thu Aug 16 13:39:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GKdfH08470 for linux-xfs-outgoing; Thu, 16 Aug 2001 13:39:41 -0700 Received: from epithumia.math.uh.edu (IDENT:root@epithumia.math.uh.edu [129.7.128.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GKddj08451 for ; Thu, 16 Aug 2001 13:39:39 -0700 Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.11.0/8.11.1) id f7GKddp10040; Thu, 16 Aug 2001 15:39:39 -0500 To: linux-xfs@oss.sgi.com Subject: Re: Diskless References: <3B7C1F36.5A86335B@link.com> <3B7C225F.1CFC0FFB@sgi.com> From: Jason L Tibbitts III Date: 16 Aug 2001 15:39:39 -0500 In-Reply-To: Eric Sandeen's message of "Thu, 16 Aug 2001 14:43:27 -0500" Message-ID: Lines: 16 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "ES" == Eric Sandeen writes: ES> I'm not well versed in net booting, but I thought it just NFS mounted a ES> remote filesystem to get it's kernel? I guess you could write an NFS implementation and stick it in ROM, but that would be the hard way. Most netboot clients I've seen use TFTP to pull down the kernel and initrd. I use PXE compliant Ethernet cards, which do DHCP to get an IP address and boot server, then use TFTP to pull down pxelinux. pxelinux is just syslinux made to work over the network. It then uses TFTP to pull down a vmlinuz and initrd.img, and from that point it's as if everything was loaded off of brown and round. - J< From owner-linux-xfs@oss.sgi.com Thu Aug 16 13:40:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GKeU608617 for linux-xfs-outgoing; Thu, 16 Aug 2001 13:40:30 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GKeRj08597 for ; Thu, 16 Aug 2001 13:40:27 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA03868 for ; Thu, 16 Aug 2001 13:40:27 -0700 (PDT) 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 PAA2734789 for ; Thu, 16 Aug 2001 15:39:10 -0500 (CDT) 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 PAA92663 for ; Thu, 16 Aug 2001 15:39:10 -0500 (CDT) From: eric@sgi.com Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7GKd7v01685; Thu, 16 Aug 2001 15:39:07 -0500 Message-Id: <200108162039.f7GKd7v01685@stout.americas.sgi.com> Date: Thu, 16 Aug 2001 15:39:07 -0500 Subject: TAKE - "Merge" of irix6.5f:irix:100627b Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This isn't really much of a merge, since Steve implemented the freeze/thaw stuff a while ago, but this brings Linux in line with what Irix now looks like. Some of it is purely cosmetic. xfs_fd_to_mp and xfs_check_frozen get some new arguments. xfs_fs_freeze and xfs_fs_thaw are now their own functions called out of xfs_ioctl.c, rather than having all the code in the case statement. Just to keep things in sync with Irix. Date: Thu Aug 16 13:34:51 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100940a linux/fs/xfs/xfs_log.c - 1.239 linux/fs/xfs/xfs_rw.c - 1.342 linux/fs/xfs/xfs_itable.c - 1.99 linux/fs/xfs/xfs_itable.h - 1.33 linux/fs/xfs/xfs_mount.h - 1.130 linux/fs/xfs/xfs_mount.c - 1.259 linux/fs/xfs/xfs_trans.c - 1.122 linux/fs/xfs/xfs_utils.c - 1.39 - "Merge" of irix6.5f:irix:100627b linux/fs/xfs/xfs_fsops.h - 1.19 - "Merge" of irix6.5f:irix:100627b xfs_fs_freeze/thaw prototypes linux/fs/xfs/xfs_fsops.c - 1.66 - "Merge" of irix6.5f:irix:100627b Add xfs_fs_freeze, thaw functions linux/fs/xfs/linux/xfs_lrw.c - 1.105 - "Merge" of irix6.5f:irix:100627b linux/fs/xfs/linux/xfs_ioctl.c - 1.47 - "Merge" of irix6.5f:irix:100627b Move freeze/thaw ioctls out of case statements into functions From owner-linux-xfs@oss.sgi.com Thu Aug 16 14:52:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GLqjA10881 for linux-xfs-outgoing; Thu, 16 Aug 2001 14:52:45 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GLqgj10862 for ; Thu, 16 Aug 2001 14:52:42 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA06771; Thu, 16 Aug 2001 23:52:37 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA09167; Thu, 16 Aug 2001 23:52:37 +0200 (CEST) Date: Thu, 16 Aug 2001 23:52:36 +0200 (CEST) From: Seth Mos To: Eric Sandeen cc: Jeffrey K Butkovich , linux-xfs@oss.sgi.com Subject: Re: Diskless In-Reply-To: <3B7C252D.2A4E481D@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 16 Aug 2001, Eric Sandeen wrote: > Eric Sandeen wrote: > > > I'm not well versed in net booting, but I thought it > > just NFS mounted a remote filesystem to get it's kernel? > > Uh... ok turn brain on, Eric. How do you NFS mount something w/o a > kernel? :) Thinclient: System boots up. Sends out a bootp request for the filename and tftp server. Fetches kernel image and tries to put it in the temporary ram or main ram (too large? stops here) Kernel boots and NFS mounts it's root fs. Standard kernel that is in the system (SGI XFS 1.0.1 kernel) is fully compiled and probably copied to the tftpboot dir. After fetching the kernel the thin client might give up because the kernel doens't fit in the temporary ram. Solution: Recompile kernel without XFS and other FS crap you don't need on a thinclient. Bootfloppy method: Copy kernel to mount root NFS to boot floppy with initrd and scripts with neccesary information to mount NFS server. (too large? stops here) Boot floppy/kernel mount root NFS filesystem and continue startup via NFS mounted root. Networkcard EEPROM boot: Boot from Boot prom on networkcard, send bootprequest to server and fetch kernel. (too large? stopping here) Boot kernel and mount root NFS filesystem. Bootfloppy method: Copy SGI XFS 1.0.1 kernel to floppy, doesn't fit complete with initrd for NFS mounting root. (stops right here during creation of boot floppy) Solution: Recompile kernel without XFS and other stuff you don't need or make it a module. and build your initrd. Can't think of any other methods. I have never did this before but I did fumble with a NCD thinclient before. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Aug 16 15:24:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GMO9J11988 for linux-xfs-outgoing; Thu, 16 Aug 2001 15:24:09 -0700 Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GMO7j11968 for ; Thu, 16 Aug 2001 15:24:07 -0700 Received: from lucas.loria (strasbourg-2-a7-50-143.dial.proxad.net [212.27.50.143]) by postfix2-2.free.fr (Postfix) with ESMTP id 70CE75F7C4; Fri, 17 Aug 2001 00:24:04 +0200 (CEST) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id 320BCA61D; Thu, 16 Aug 2001 22:36:30 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id 76839A0F38; Thu, 16 Aug 2001 22:36:28 +0200 (CEST) To: "Steve Wolfe" Cc: Subject: Re: Diskless References: <3B7C1F36.5A86335B@link.com> <3B7C225F.1CFC0FFB@sgi.com> <001901c1268c$01873680$50824e40@iboats.com> X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E In-Reply-To: <001901c1268c$01873680$50824e40@iboats.com> From: Vincent Bernat Date: 16 Aug 2001 22:36:28 +0200 Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) 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 OoO En ce début de soirée du jeudi 16 août 2001, vers 21:45, Steve Wolfe disait: > I would guess that he means "too big to fit in the flash RAM", in which > case, use a bigger flash RAM, use fewer kernel features, and/or use "make > bzImage", not "make zImage". The code in the flash RAM is just a simple code to download kernel throught tftp after getting an IP with bootp. It is a simple little code which takes only 32 Kb. http://www.etherboot.org http://www.ltsp.org From owner-linux-xfs@oss.sgi.com Thu Aug 16 15:50:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GMo3V12962 for linux-xfs-outgoing; Thu, 16 Aug 2001 15:50:03 -0700 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 f7GMo2j12943 for ; Thu, 16 Aug 2001 15:50:02 -0700 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 f7GMsr801235 for ; Thu, 16 Aug 2001 15:54:53 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02215; Fri, 17 Aug 2001 08:48:38 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA84662; Fri, 17 Aug 2001 08:48:37 +1000 (AEST) Date: Fri, 17 Aug 2001 08:48:36 +1000 From: Nathan Scott To: christian mueller Cc: linux-xfs@oss.sgi.com Subject: Re: minor problem with Message-ID: <20010817084835.A309870@wobbly.melbourne.sgi.com> References: <3B7BBBA0.24974.12C2BAD@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7BBBA0.24974.12C2BAD@localhost>; from christian.mueller1@gmx.de on Thu, Aug 16, 2001 at 12:25:04PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 16, 2001 at 12:25:04PM +0200, christian mueller wrote: > hi all, > > xfsprogs-1.3.5: make fails in libdisk/liblvm.h at line 46 > #include > on my SuSE 7.2 system. Fixed, thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 16 16:22:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GNMLI14055 for linux-xfs-outgoing; Thu, 16 Aug 2001 16:22:21 -0700 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 f7GNMJj14036 for ; Thu, 16 Aug 2001 16:22:19 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7GNSDa24868 for ; Thu, 16 Aug 2001 16:28:13 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA14437; Fri, 17 Aug 2001 09:20:48 +1000 (EST) Date: Fri, 17 Aug 2001 09:20:48 +1000 (EST) From: Nathan Scott Message-Id: <200108162320.JAA14437@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: eric@peters.org, dm@belkam.com Subject: TAKE - setfacl + ACE ordering Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Eric, this is basically what you've suggested as a fix, just in a different place. Seems to work just fine in my testing. cheers. Date: Thu Aug 16 16:15:02 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100959a cmd/acl/libacl/libacl.c - 1.2 - fix the ACE ordering issue for setfacl, based on suggestions from Eric Peters. From owner-linux-xfs@oss.sgi.com Fri Aug 17 04:06:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HB6Xf30736 for linux-xfs-outgoing; Fri, 17 Aug 2001 04:06:33 -0700 Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HB6Tj30717 for ; Fri, 17 Aug 2001 04:06:29 -0700 Received: from lucas.loria (213.36.122.237) by mail.libertysurf.net (5.1.053) id 3B7C7CB500009A14 for linux-xfs@oss.sgi.com; Fri, 17 Aug 2001 13:06:22 +0200 Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id 806EFA629 for ; Fri, 17 Aug 2001 11:20:01 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id 8538CA0F38; Fri, 17 Aug 2001 11:19:57 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: XFS behaviour on "bad" disks. X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E From: Vincent Bernat Date: 17 Aug 2001 11:19:57 +0200 In-Reply-To: <200108162320.JAA14437@snort.melbourne.sgi.com> Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi ! I am currently using xfs on SCSI disks and I have some problem with the SCSI card : my box crashed several time under heavy condition. I am investigating the problem and I have a proper backup of all my data. Suppose that the SCSI card or the SCSI disk is not reliable, not because it can crash the system (I suppose this is correctly handled, like a power shortage) but because : 1. it can read an incorrect bit 2. it can write an incorrrect bit 3. it can produce a permanent failure error (like a bad sector on a floppy disk) What is the behaviour of XFS in regards of these three cases ? I don't think the first two cases happen really but I care about the last one. -- I CAN'T SEE DEAD PEOPLE I CAN'T SEE DEAD PEOPLE I CAN'T SEE DEAD PEOPLE -+- Bart Simpson on chalkboard in episode BABF05 From owner-linux-xfs@oss.sgi.com Fri Aug 17 04:42:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HBg4N31610 for linux-xfs-outgoing; Fri, 17 Aug 2001 04:42:04 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HBg1j31591 for ; Fri, 17 Aug 2001 04:42:01 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id BE8141E39A; Fri, 17 Aug 2001 13:41:55 +0200 (MEST) Date: Fri, 17 Aug 2001 13:41:50 +0200 From: Andi Kleen To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] XFS OOM hardening Message-ID: <20010817134150.A28958@gruyere.muc.suse.de> References: <200108142221.f7EMLcQ15900@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108142221.f7EMLcQ15900@jen.americas.sgi.com>; from lord@sgi.com on Tue, Aug 14, 2001 at 05:21:38PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Aug 14, 2001 at 05:21:38PM -0500, Steve Lord wrote: > > Thanks Andi, I know you have sent most of this before, things are a just > a 'leetle bit' hectic around here right now, so things are taking longer > than they otherwise would. The problem with the code which does some > xfs memory allocation failure detection is that you can never get to > all of them, this is why I have never checked in the stuff about > seeing a NULL and doing an error return. There are also places in xfs > where failure is not an option - once a transaction has dirtied > metadata there is no turning back. So really the only option which will > fly long term is making sure memory allocations do not return failure > when they get back up to xfs proper. I do have some other ideas it is > just a matter of finding the time. In case you really want to defer this patch for some me hypothetic better solution I would suggest at least applying the pagebuf errno fixes, as they are independent. Here are they extracted again. -Andi --- linux-xfs/fs/pagebuf/page_buf.c-XFSMEM Tue Aug 14 01:12:43 2001 +++ linux-xfs/fs/pagebuf/page_buf.c Tue Aug 14 20:43:57 2001 @@ -1200,7 +1202,7 @@ page = bh->b_page; if (!test_bit(BH_Uptodate, &bh->b_state)) { set_bit(PG_error, &page->flags); - pb->pb_error = -EIO; + pb->pb_error = EIO; } unlock_buffer(bh); @@ -1221,7 +1223,7 @@ page = bh->b_page; if (!test_bit(BH_Uptodate, &bh->b_state)) { set_bit(PG_error, &page->flags); - pb->pb_error = -EIO; + pb->pb_error = EIO; } unlock_buffer(bh); @@ -1244,7 +1246,7 @@ page = bh->b_page; if (!test_bit(BH_Uptodate, &bh->b_state)) { set_bit(PG_error, &page->flags); - pb->pb_error = -EIO; + pb->pb_error = EIO; } unlock_buffer(bh); From owner-linux-xfs@oss.sgi.com Fri Aug 17 04:42:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HBgEI31663 for linux-xfs-outgoing; Fri, 17 Aug 2001 04:42:14 -0700 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 f7HBgDj31632 for ; Fri, 17 Aug 2001 04:42:13 -0700 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 f7HBm9a07711 for ; Fri, 17 Aug 2001 04:48:09 -0700 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 GAA2731865 for ; Fri, 17 Aug 2001 06:40:52 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA46740 for ; Fri, 17 Aug 2001 06:40:52 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7HBfqL08174; Fri, 17 Aug 2001 06:41:52 -0500 Message-Id: <200108171141.f7HBfqL08174@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: TAKE - merge up to 2.4.9 Date: Fri, 17 Aug 2001 06:41:51 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk For some reason I want to call this one "Mr Torvalds goes to Finland", which will confuse people who do not read the linux kernel mailing list. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 17 05:18:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HCIbS00392 for linux-xfs-outgoing; Fri, 17 Aug 2001 05:18:37 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HCIZj00368 for ; Fri, 17 Aug 2001 05:18:35 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA09057 for ; Fri, 17 Aug 2001 05:18:19 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA2728870 for ; Fri, 17 Aug 2001 07:17:19 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA11695 for ; Fri, 17 Aug 2001 07:17:19 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7HCIIA08416; Fri, 17 Aug 2001 07:18:18 -0500 Message-Id: <200108171218.f7HCIIA08416@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: email problems Date: Fri, 17 Aug 2001 07:18:18 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Something odd is happening with email right now, I can send email and it appears to go places, but nothing is getting delivered to me. I see a message from Andi Kleen to me in the mail archives, but it has not made my mailbox yet. The abbreviated take message I sent out was because the original with the filenames in it appears to hit some sort of spam filter - must have been something in the filenames. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 17 05:21:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HCL8a00598 for linux-xfs-outgoing; Fri, 17 Aug 2001 05:21:08 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HCL6j00578 for ; Fri, 17 Aug 2001 05:21:06 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA09297 for ; Fri, 17 Aug 2001 05:20:50 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA2671993 for ; Fri, 17 Aug 2001 07:19:50 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA08987 for ; Fri, 17 Aug 2001 07:19:50 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f7HCKng08497; Fri, 17 Aug 2001 07:20:49 -0500 Message-Id: <200108171220.f7HCKng08497@jen.americas.sgi.com> Date: Fri, 17 Aug 2001 07:20:49 -0500 Subject: TAKE - fix error return sign from pagebuf Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Patch from Andi Kleen. Date: Fri Aug 17 05:19:14 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100969a linux/fs/pagebuf/page_buf.c - 1.97 - fix sign on error return from pagebuf From owner-linux-xfs@oss.sgi.com Fri Aug 17 05:50:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HCoBO01413 for linux-xfs-outgoing; Fri, 17 Aug 2001 05:50:11 -0700 Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HCo8j01393 for ; Fri, 17 Aug 2001 05:50:08 -0700 Received: from inter.nl.net (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.11.0/8.8.7) with ESMTP id f7HCWlc04421; Fri, 17 Aug 2001 14:32:47 +0200 Message-ID: <3B7D1300.70007@inter.nl.net> Date: Fri, 17 Aug 2001 14:50:08 +0200 From: Jurgen Kramer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.4.9 References: <200108171141.f7HBfqL08174@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is 2.4.9 "stable" enough? Its awfully fast after 2.4.8. Linus only brought it out because he is away for a week+. (Yes I read the LKML). Oh the Linuxx kernel mailing list a read about various compile failures 'n stuff. But alas if it doesn't work it's only for a week...;-) Keep up the good work! Steve Lord wrote: >For some reason I want to call this one "Mr Torvalds goes to Finland", >which will confuse people who do not read the linux kernel mailing >list. > >Steve > > > From owner-linux-xfs@oss.sgi.com Fri Aug 17 06:05:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HD5QA01841 for linux-xfs-outgoing; Fri, 17 Aug 2001 06:05:26 -0700 Received: from tigger.cc-concepts.com (64-40-83-10.mb.dsl.mebtel.net [64.40.83.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HD5Nj01822 for ; Fri, 17 Aug 2001 06:05:23 -0700 Received: from baptistefamily.net (gwy3.cc-concepts.com [64.40.83.12]) by tigger.cc-concepts.com (8.9.3/8.9.3) with ESMTP id JAA15344; Fri, 17 Aug 2001 09:05:16 -0400 Message-ID: <3B7D168F.9050003@baptistefamily.net> Date: Fri, 17 Aug 2001 09:05:19 -0400 From: Mike Baptiste User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Jurgen Kramer CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.4.9 References: <200108171141.f7HBfqL08174@jen.americas.sgi.com> <3B7D1300.70007@inter.nl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm running it on two boxes and so far it seems fine. I had problems with 2.4.7 and 2.4.8 locking up hard (Athlon/AMD Irongate systems) about once every day or two (these were desktops runnign X). Problem seemed to be fixed around 9-pre2. It was pretty fast, heck two pre releases came out within 24 hours of each other, but 2.4.9 was a small release - most new kernels have like 8-10 pre-release patches, 2.4.9 had only 4. Mike Jurgen Kramer wrote: > Is 2.4.9 "stable" enough? Its awfully fast after 2.4.8. Linus only > brought it out because he is away for a week+. > (Yes I read the LKML). Oh the Linuxx kernel mailing list a read about > various compile failures 'n stuff. But alas if it doesn't work it's only > for a week...;-) > > Keep up the good work! > > Steve Lord wrote: > >> For some reason I want to call this one "Mr Torvalds goes to Finland", >> which will confuse people who do not read the linux kernel mailing >> list. >> >> Steve >> >> >> > From owner-linux-xfs@oss.sgi.com Fri Aug 17 06:11:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HDBfr02108 for linux-xfs-outgoing; Fri, 17 Aug 2001 06:11:41 -0700 Received: from citadel.oehansen.pp.se (gw.hby.thalamus.se [212.31.160.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HDBcj02089 for ; Fri, 17 Aug 2001 06:11:39 -0700 Received: from there (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f7HDEN001619; Fri, 17 Aug 2001 15:14:24 +0200 Message-Id: <200108171314.f7HDEN001619@citadel.oehansen.pp.se> Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Organization: Private To: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: email problems Date: Fri, 17 Aug 2001 15:14:23 +0200 X-Mailer: KMail [version 1.3.1] References: <200108171218.f7HCIIA08416@jen.americas.sgi.com> In-Reply-To: <200108171218.f7HCIIA08416@jen.americas.sgi.com> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 Something odd is happening with email right now, I can send email and it > appears to go places, but nothing is getting delivered to me. I see a > message from Andi Kleen to me in the mail archives, but it has not made > my mailbox yet. The abbreviated take message I sent out was because the > original with the filenames in it appears to hit some sort of spam > filter - must have been something in the filenames. > I had an add, just a few days, or week ago ... I'm sorry I didn't bother to keep it but the sender appeared as 'oss.sgi.com'. I usually don't bother with such mail and just hit 'trash' ... but when you mention this, a second thought just runs through my head. Orn From owner-linux-xfs@oss.sgi.com Fri Aug 17 06:42:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HDg4f02766 for linux-xfs-outgoing; Fri, 17 Aug 2001 06:42:04 -0700 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 f7HDg2j02747 for ; Fri, 17 Aug 2001 06:42:02 -0700 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 f7HDkt816524 for ; Fri, 17 Aug 2001 06:46:55 -0700 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 IAA2735566; Fri, 17 Aug 2001 08:40:40 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA43054; Fri, 17 Aug 2001 08:40:40 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7HDfdo08600; Fri, 17 Aug 2001 08:41:39 -0500 Message-Id: <200108171341.f7HDfdo08600@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jurgen Kramer cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.4.9 In-Reply-To: Message from Jurgen Kramer of "Fri, 17 Aug 2001 14:50:08 +0200." <3B7D1300.70007@inter.nl.net> Date: Fri, 17 Aug 2001 08:41:39 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Is 2.4.9 "stable" enough? Its awfully fast after 2.4.8. Linus only > brought it out because he is away for a week+. > (Yes I read the LKML). Oh the Linuxx kernel mailing list a read about > various compile failures 'n stuff. But alas if it doesn't work it's only > for a week...;-) > 2.4.8 is still available in patch form, the does not compile messages only appear to affect the ntfs filesystem and several versions of a patch to make it compile have been posted. It all appears to be about the min and max macros getting changed to have three arguments! Steve p.s. this does mean I am getting some email, but other messages are still MIA. From owner-linux-xfs@oss.sgi.com Fri Aug 17 09:17:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HGH6H06189 for linux-xfs-outgoing; Fri, 17 Aug 2001 09:17:06 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HGH2j06170 for ; Fri, 17 Aug 2001 09:17:02 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 60110C00FC9 for ; Fri, 17 Aug 2001 23:57:22 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0FF92C00FC8 for ; Fri, 17 Aug 2001 23:57:21 +0800 (PHT) Received: from 192.168.0.1 ( [192.168.0.1]) as user jijo@localhost by horde.leathercollection.ph with HTTP; Fri, 17 Aug 2001 23:57:20 +0800 Message-ID: <998063840.3b7d3ee1007e5@horde.leathercollection.ph> Date: Fri, 17 Aug 2001 23:57:21 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: XFS behaviour on "bad" disks. References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs X-Originating-IP: 192.168.0.1 X-Organization: The Leather Collection, Inc. X-URL: http X-Admin-Contact: root@leather-collection.com X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Quoting Vincent Bernat : > I am currently using xfs on SCSI disks and I have some problem with the SCSI > card : my box crashed several time under heavy condition. I am investigating > the problem and I have a proper backup of all my data. Just a thought: I'm using a 3ware Escalade 6400 and not just once but at least twice and maybe thrice (my brain logs are screwed up) my system running Linux 2.4.7 with XFS froze. Not even the Magic SysRq key combinations would unfreeze the darned thing. The only solution would be to reboot (cold). 100% of the time this happened was when a single faulty drive among a total of four in my RAID5 system hit a bad sector causing the 3ware card to mark that drive as "offline". For some reason this has been messing things up. It is unfortunate that this is a server, and us being an SME in a 3rd world country, is the only one with such "advanced" a controller as 3ware's (we got it because we couldn't afford a SCSI RAID system but needed RAID). Thus I cannot test how the system would fare if it were using ext2, ext3, ReiserFS or JFS, and cannot conclude whether it's XFS-specific, or if it's an issue with the controller. Dan Yocum has been doing some work, though, basically doing really agressive tests from what I gather. It looks like he's noticing issues with NFS, and in his case, user space. I don't use user space NFS, but have support for v3 kernel NFS built into my kernel. The last time my system hung up I had the nfs daemons off (including portmap). I did this hoping I could isolate the issue. Unfortunately I cannot permanently remove NFS because I am under pressure to get file sharing for a number of Linux boxes and I do this via NFS. I do not know if there is any other decent alternative to share /home complete with proper permissions. Samba's great, but it's just not designed to do such things. I don't know how Coda is, or AFS, or what have you. Maybe someone else on the list more authoritative can let us know. In the meantime I am hoping my hard drives will hold up. I'm also upgrading to 2.4.9 (thanks Steve for that wonderful TAKE) as soon as I can take the server offline for a short while. Hopefully while keeping up with updates I'll be able to narrow down the issue to find out which darned part of the system is causing the fatal freezes. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG key: From owner-linux-xfs@oss.sgi.com Fri Aug 17 18:40:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7I1e9918805 for linux-xfs-outgoing; Fri, 17 Aug 2001 18:40:09 -0700 Received: from www.fortuitous.com (cs666824-51.austin.rr.com [66.68.24.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7I1e7j18786 for ; Fri, 17 Aug 2001 18:40:07 -0700 Received: by www.fortuitous.com (Postfix, from userid 500) id 1C22183F; Fri, 17 Aug 2001 20:37:25 -0500 (CDT) Date: Fri, 17 Aug 2001 20:37:25 -0500 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Re: Cannot compile xfsdump Message-ID: <20010817203725.A3433@bistro.marx> Reply-To: pac@fortuitous.com References: <4.3.2.7.2.20010801094731.03250768@pop.xs4all.nl> <20010801181231.A228095@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010801181231.A228095@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Aug 01, 2001 at 06:12:31PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 01, 2001 at 06:12:31PM +1000, Nathan Scott wrote: > hi, > > On Wed, Aug 01, 2001 at 09:47:37AM +0200, Seth Mos wrote: > > At 09:14 1-8-2001 +0200, you wrote: > > >At 16:14 31-7-2001 -0500, Steve Lord wrote: > > >> > Hello, > > >>Let's add this solution to this part of the configure script. can i assume the fix is in the 2.4.8 xfs tree? Im running conectiva.. Im not sure if the redhat rpms will install correctly. Im having the same problems with the 2.4.4 version of the cvs tree... Thanks. -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 Fri Aug 17 19:02:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7I22He19393 for linux-xfs-outgoing; Fri, 17 Aug 2001 19:02:17 -0700 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 f7I22Fj19373 for ; Fri, 17 Aug 2001 19:02:15 -0700 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 f7I278831941 for ; Fri, 17 Aug 2001 19:07:08 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA08718; Sat, 18 Aug 2001 12:00:51 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA58265; Sat, 18 Aug 2001 12:00:50 +1000 (AEST) Date: Sat, 18 Aug 2001 12:00:49 +1000 From: Nathan Scott To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com Subject: Re: Cannot compile xfsdump Message-ID: <20010818120049.A235002@wobbly.melbourne.sgi.com> References: <4.3.2.7.2.20010801094731.03250768@pop.xs4all.nl> <20010801181231.A228095@wobbly.melbourne.sgi.com> <20010817203725.A3433@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010817203725.A3433@bistro.marx>; from pac@fortuitous.com on Fri, Aug 17, 2001 at 08:37:25PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 17, 2001 at 08:37:25PM -0500, pac@fortuitous.com wrote: > On Wed, Aug 01, 2001 at 06:12:31PM +1000, Nathan Scott wrote: > > hi, > > > > On Wed, Aug 01, 2001 at 09:47:37AM +0200, Seth Mos wrote: > > > At 09:14 1-8-2001 +0200, you wrote: > > > >At 16:14 31-7-2001 -0500, Steve Lord wrote: > > > >> > Hello, > > > >>Let's add this solution to this part of the configure script. > > can i assume the fix is in the 2.4.8 xfs tree? > Im running conectiva.. Im not sure if the redhat rpms will install > correctly. > > Im having the same problems with the 2.4.4 version of the cvs tree... > Thanks. what problem was that exactly? if I remember correctly, the "solution" above was just a change to the diagnostic reported by the xfsdump configure script... suggesting a "make install-dev" in xfsprogs so that xfsdump is then built against current XFS headers. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Aug 17 22:52:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7I5qit23454 for linux-xfs-outgoing; Fri, 17 Aug 2001 22:52:44 -0700 Received: from www.fortuitous.com (cs666824-51.austin.rr.com [66.68.24.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7I5qgj23435 for ; Fri, 17 Aug 2001 22:52:42 -0700 Received: by www.fortuitous.com (Postfix, from userid 500) id 5A185842; Sat, 18 Aug 2001 00:49:58 -0500 (CDT) Date: Sat, 18 Aug 2001 00:49:58 -0500 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Re: Cannot compile xfsdump Message-ID: <20010818004958.A11942@bistro.marx> Reply-To: pac@fortuitous.com References: <4.3.2.7.2.20010801094731.03250768@pop.xs4all.nl> <20010801181231.A228095@wobbly.melbourne.sgi.com> <20010817203725.A3433@bistro.marx> <20010818120049.A235002@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010818120049.A235002@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Sat, Aug 18, 2001 at 12:00:49PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > what problem was that exactly? if I remember correctly, > the "solution" above was just a change to the diagnostic > reported by the xfsdump configure script... suggesting > a "make install-dev" in xfsprogs so that xfsdump is then > built against current XFS headers. I finally got it, after several make install-dev, ldconfig's, and make install's.. Of course i'm using a 2.4.4 version which may be part of the problem. Any chance the libs can be search locally instead of systemwide? Otherwise you have to toggle between user and root make's, or am i missing something? -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 Sat Aug 18 00:26:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7I7QIG25240 for linux-xfs-outgoing; Sat, 18 Aug 2001 00:26:18 -0700 Received: from bobas.nowytarg.top.pl (ghostwheel.underley.eu.org [217.97.235.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7I7Q9j25217 for ; Sat, 18 Aug 2001 00:26:16 -0700 Received: by bobas.nowytarg.top.pl with BSMTP id ; Sat, 18 Aug 2001 09:28:46 +0200 Received: by witch.underley.eu.org id ; Sat, 18 Aug 2001 09:27:18 +0200 Date: Sat, 18 Aug 2001 09:27:18 +0200 From: Daniel Podlejski To: linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.4.9 Message-ID: <20010818092717.A28016@witch.underley.eu.org> References: <3B7D1300.70007@inter.nl.net> <200108171341.f7HDfdo08600@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200108171341.f7HDfdo08600@jen.americas.sgi.com> User-Agent: Mutt/1.3.20i X-PGP-Fingerprint: 4D 72 53 F8 FE 8C 53 B9 66 AD F6 EA C9 17 CD 82 X-GPG-Fingerprint: 299F 1820 582B 283A 5F50 37D9 AA0B 6E10 03D4 EA5D X-Homepage: http://www.underley.eu.org/ X-Cert: http://www.brainbench.com/transcript.jsp?pid=124954 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: [...] : 2.4.8 is still available in patch form, why you dont add cvs tag on each release and merge with current kernel version ? It's very easy and usefull. -- Daniel Podlejski ... Seven deadly sins, Seven ways to win Seven holy paths to hell, And your trip begins ... From owner-linux-xfs@oss.sgi.com Sat Aug 18 07:12:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7IECP931174 for linux-xfs-outgoing; Sat, 18 Aug 2001 07:12:25 -0700 Received: from mplspop4.mpls.uswest.net (mplspop4.mpls.uswest.net [204.147.80.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7IECDj31155 for ; Sat, 18 Aug 2001 07:12:13 -0700 Received: (qmail 59164 invoked from network); 18 Aug 2001 14:12:08 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop4.mpls.uswest.net with SMTP; 18 Aug 2001 14:12:08 -0000 Date: Sat, 18 Aug 2001 09:09:05 -0500 Message-ID: <3B7E7701.797AED17@sgi.com> From: "Eric Sandeen" To: "Daniel Podlejski" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: TAKE - merge up to 2.4.9 References: <3B7D1300.70007@inter.nl.net> <200108171341.f7HDfdo08600@jen.americas.sgi.com> <20010818092717.A28016@witch.underley.eu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Daniel Podlejski wrote: > > Steve Lord wrote: > [...] > : 2.4.8 is still available in patch form, > > why you dont add cvs tag on each release and merge with current > kernel version ? It's very easy and usefull. Mostly because we don't use cvs internally - it's just exported from our internal tools - and adding a tag is actually not completely straightforward or fast. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Aug 18 08:17:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7IFHAL32401 for linux-xfs-outgoing; Sat, 18 Aug 2001 08:17:10 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7IFH7j32382 for ; Sat, 18 Aug 2001 08:17:08 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id DBBD0C00FB9 for ; Sat, 18 Aug 2001 23:17:02 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 7B91CC00FB0 for ; Sat, 18 Aug 2001 23:17:01 +0800 (PHT) Date: Sat, 18 Aug 2001 23:17:01 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: TAKE - merge up to 2.4.9 In-Reply-To: <3B7E7701.797AED17@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 On Sat, 18 Aug 2001 at 09:09, Eric Sandeen wrote: > Mostly because we don't use cvs internally - it's just exported from > our internal tools - and adding a tag is actually not completely > straightforward or fast. Hmm, "internal tools" suddenly makes me curious. ;> --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sat Aug 18 08:55:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7IFtHc00785 for linux-xfs-outgoing; Sat, 18 Aug 2001 08:55:17 -0700 Received: from mplspop4.mpls.uswest.net (mplspop4.mpls.uswest.net [204.147.80.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7IFtFj00766 for ; Sat, 18 Aug 2001 08:55:15 -0700 Received: (qmail 54795 invoked from network); 18 Aug 2001 15:55:09 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop4.mpls.uswest.net with SMTP; 18 Aug 2001 15:55:09 -0000 Date: Sat, 18 Aug 2001 10:52:06 -0500 Message-ID: <3B7E8F26.3592F8AA@sgi.com> From: "Eric Sandeen" To: "Federico Sevilla III" Cc: "Linux XFS Mailing List" 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 Subject: Re: TAKE - merge up to 2.4.9 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III wrote: > > On Sat, 18 Aug 2001 at 09:09, Eric Sandeen wrote: > > Mostly because we don't use cvs internally - it's just exported from > > our internal tools > Hmm, "internal tools" suddenly makes me curious. ;> nothing terribly exciting, it's another RCS-backed code control system called ptools... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Aug 18 14:08:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7IL87005948 for linux-xfs-outgoing; Sat, 18 Aug 2001 14:08:07 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7IL82j05929 for ; Sat, 18 Aug 2001 14:08:02 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7IL7eXi074822; Sat, 18 Aug 2001 16:07:40 -0500 (CDT) Message-ID: <3B7ED916.6A8A5B25@thebarn.com> Date: Sat, 18 Aug 2001 16:07:35 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Daniel Podlejski , linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.4.9 References: <3B7D1300.70007@inter.nl.net> <200108171341.f7HDfdo08600@jen.americas.sgi.com> <20010818092717.A28016@witch.underley.eu.org> <3B7E7701.797AED17@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: > Daniel Podlejski wrote: > > > > Steve Lord wrote: > > [...] > > : 2.4.8 is still available in patch form, > > > > why you dont add cvs tag on each release and merge with current > > kernel version ? It's very easy and usefull. > > Mostly because we don't use cvs internally - it's just exported from our > internal tools - and adding a tag is actually not completely > straightforward or fast. Actually it's not that hard ... I wrote a simple script to take a census file and add an RCS tag to all the files in the census file, but yes it does take an hour or so to do. I would volunteer to do it but I'm not sure I have permission anymore. > > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sat Aug 18 17:22:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7J0MZL08463 for linux-xfs-outgoing; Sat, 18 Aug 2001 17:22:35 -0700 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7J0MTj08444 for ; Sat, 18 Aug 2001 17:22:30 -0700 Received: (qmail 1034 invoked by uid 0); 19 Aug 2001 00:22:22 -0000 Received: from f-6-212.cvx-leipzig.ipdial.viaginterkom.de (HELO temple) (62.180.212.6) by mail.gmx.net (mp002-rz3) with SMTP; 19 Aug 2001 00:22:22 -0000 Message-ID: <001601c12845$e55a7650$01000001@temple> Reply-To: "Andreas Piesk" From: "Andreas Piesk" To: "xfs ML" Subject: Date: Sun, 19 Aug 2001 02:28:11 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_01C12856.972D6E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C12856.972D6E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit in kernel 2.4.9 the macros 'min' and 'max' were changed. i found, that not all places in the code are changed. attached you will find a small patch to solve this issue. ciao -ap -- Andreas Piesk a.piesk@gmx.net PGP-Fingerprint: 23CB A7E2 2E53 373C DBCD 8EFC 7777 61C1 ------=_NextPart_000_0013_01C12856.972D6E40 Content-Type: application/octet-stream; name="xfs-min.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xfs-min.patch" diff -Pur linux.org/fs/pagebuf/page_buf_io.c = linux/fs/pagebuf/page_buf_io.c=0A= --- linux.org/fs/pagebuf/page_buf_io.c Sun Aug 19 00:26:08 2001=0A= +++ linux/fs/pagebuf/page_buf_io.c Sun Aug 19 00:37:03 2001=0A= @@ -255,13 +255,13 @@=0A= iovecp =3D iodp->io_iovec[iodp->io_iovec_index];=0A= user_addr =3D iovecp->iov_base + iodp->io_iovec_offset;=0A= iov_left_len =3D iovecp->iov_len - iodp->io_iovec_offset;=0A= - copy_len =3D min(iov_left_len, len);=0A= + copy_len =3D min(size_t, iov_left_len, len);=0A= =0A= /*=0A= * Restrict read/zero size to what is left=0A= * in the file.=0A= */=0A= - copy_len =3D min(copy_len,=0A= + copy_len =3D min(size_t, copy_len,=0A= iodp->io_i_size - iodp->io_offset);=0A= =0A= /* Use __clear_user since we don't need=0A= @@ -374,7 +374,7 @@=0A= off_t offset;=0A= ulong max_io =3D pb_params.p_un.max_dio << PAGE_SHIFT;=0A= =0A= - pb_size =3D min(pb_size, max_io);=0A= + pb_size =3D min(size_t, pb_size, max_io);=0A= =0A= pb_flags =3D (rdwr ? PBF_WRITE : PBF_READ) | PBF_FORCEIO;=0A= =0A= @@ -559,7 +559,7 @@=0A= */=0A= =0A= map_size =3D mp->pbm_bsize - mp->pbm_delta;=0A= - size =3D min(map_size, rounded_size);=0A= + size =3D min(long, map_size, rounded_size);=0A= =0A= if (mp->pbm_flags & (PBMF_HOLE|PBMF_UNWRITTEN)) {=0A= =0A= @@ -594,7 +594,7 @@=0A= */=0A= =0A= pb_size =3D=0A= - min(chunksize, size - pb_done);=0A= + min(long, chunksize, size - pb_done);=0A= } /* End of for chunksizes to get/read/copy pbs */=0A= } /* End of else we need to do I/O */=0A= map_entry++;=0A= @@ -1032,7 +1032,7 @@=0A= if (bytes_in_page > len) {=0A= bytes_in_page =3D len;=0A= }=0A= - bytes_in_page =3D min(bytes_in_page, size);=0A= + bytes_in_page =3D min(int, bytes_in_page, size);=0A= at_eof =3D foff =3D=3D inode->i_size;=0A= =0A= err =3D __pb_block_prepare_write_async(inode, page,=0A= @@ -1158,7 +1158,7 @@=0A= */=0A= =0A= map_size =3D map.pbm_bsize - map.pbm_delta;=0A= - size =3D min(map_size, size);=0A= + size =3D min(long, map_size, size);=0A= =0A= /*=0A= * Holes mean we came to the end of the space returned=0A= @@ -1178,7 +1178,7 @@=0A= rounded_offset, size, buf,=0A= len, &foff, &map);=0A= } else {=0A= - int io_size =3D min(size, len);=0A= + int io_size =3D min(long, size, len);=0A= =0A= status =3D _pb_direct_io(inode, rounded_offset,=0A= io_size, &map, buf, NULL, 1);=0A= diff -Pur linux.org/include/linux/page_buf.h = linux/include/linux/page_buf.h=0A= --- linux.org/include/linux/page_buf.h Sun Aug 19 00:26:12 2001=0A= +++ linux/include/linux/page_buf.h Sun Aug 19 00:34:22 2001=0A= @@ -674,8 +674,10 @@=0A= =0A= #define assert(x) do { } while (0)=0A= #define bzero(loc,size) memset(loc,0,size)=0A= -#define min(a,b) ((a) < (b) ? (a) : (b))=0A= -=0A= +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 9)=0A= +#define min(type,x,y) ({ type __x =3D (x), __y =3D (y); __x < __y ? = __x: __y; })=0A= +#endif=0A= + =0A= =0A= #endif /* _PAGE_BUF_INTERNAL_ */=0A= =0A= ------=_NextPart_000_0013_01C12856.972D6E40-- From owner-linux-xfs@oss.sgi.com Sat Aug 18 18:05:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7J15Wt09080 for linux-xfs-outgoing; Sat, 18 Aug 2001 18:05:32 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7J15Tj09061 for ; Sat, 18 Aug 2001 18:05:29 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA06453 for ; Sat, 18 Aug 2001 18:05:29 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12270; Sun, 19 Aug 2001 11:04:11 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA24984; Sun, 19 Aug 2001 11:04:10 +1000 (AEST) Date: Sun, 19 Aug 2001 11:04:09 +1000 From: Nathan Scott To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com Subject: Re: Cannot compile xfsdump Message-ID: <20010819110409.A319082@wobbly.melbourne.sgi.com> References: <4.3.2.7.2.20010801094731.03250768@pop.xs4all.nl> <20010801181231.A228095@wobbly.melbourne.sgi.com> <20010817203725.A3433@bistro.marx> <20010818120049.A235002@wobbly.melbourne.sgi.com> <20010818004958.A11942@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010818004958.A11942@bistro.marx>; from pac@fortuitous.com on Sat, Aug 18, 2001 at 12:49:58AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sat, Aug 18, 2001 at 12:49:58AM -0500, pac@fortuitous.com wrote: > > what problem was that exactly? if I remember correctly, > > the "solution" above was just a change to the diagnostic > > reported by the xfsdump configure script... suggesting > > a "make install-dev" in xfsprogs so that xfsdump is then > > built against current XFS headers. > > I finally got it, after several make install-dev, ldconfig's, and > make install's.. There's documentation in the cmd/*/doc/{INSTALL,PORTING} files about building the user tools, but it sounds like you've figured it all out now, so its a bit late for that suggestion perhaps. > Of course i'm using a 2.4.4 version which may be > part of the problem. The 2.4.x kernel version has no influence on the userspace build. > Any chance the libs can be search locally > instead of systemwide? That introduces some subtle inter-package build dependency issues if we continue to keep xfsdump as a separate package - they could be solved by folding the xfsdump code into xfsprogs, but that introduces its own, different set of issues. So, the status quo is unlikely to change. The current build scheme is the best of a set of imperfect options - there is no silver bullet here. > Otherwise you have to toggle between > user and root make's, or am i missing something? That is correct if you're installing to "/" (or anywhere else requiring root permission to write to, obviously). This is no different to how the ext2 "dump" package gets built though, as an example. It is possible to build everything as an ordinary user using a chroot'ed build environment, but that can be a bit of a pain to setup. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Aug 18 18:16:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7J1GW009351 for linux-xfs-outgoing; Sat, 18 Aug 2001 18:16:32 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7J1GUj09332 for ; Sat, 18 Aug 2001 18:16:31 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA21700 for ; Sat, 18 Aug 2001 18:16:13 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12286; Sun, 19 Aug 2001 11:15:13 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA07907; Sun, 19 Aug 2001 11:15:12 +1000 (AEST) Date: Sun, 19 Aug 2001 11:15:11 +1000 From: Nathan Scott To: Andreas Piesk Cc: xfs ML Subject: Re: your mail Message-ID: <20010819111511.B319082@wobbly.melbourne.sgi.com> References: <001601c12845$e55a7650$01000001@temple> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001601c12845$e55a7650$01000001@temple>; from a.piesk@gmx.net on Sun, Aug 19, 2001 at 02:28:11AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Andreas, On Sun, Aug 19, 2001 at 02:28:11AM +0200, Andreas Piesk wrote: > in kernel 2.4.9 the macros 'min' and 'max' were changed. > i found, that not all places in the code are changed. > attached you will find a small patch to solve this issue. > Yup, noticed these ones too - I have similar changes in my workarea (tied in with some changes to get debug pagebuf module running again) & will push it all in on Monday after a bit more testing. many thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 19 00:53:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7J7rs813599 for linux-xfs-outgoing; Sun, 19 Aug 2001 00:53:54 -0700 Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7J7rqj13579 for ; Sun, 19 Aug 2001 00:53:52 -0700 Received: from lucas.loria (213.36.136.134) by mail.libertysurf.net (5.1.053) id 3B7F5FB100000E19 for linux-xfs@oss.sgi.com; Sun, 19 Aug 2001 09:53:45 +0200 Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id D2598A53C for ; Sun, 19 Aug 2001 09:53:48 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id 8B3D5A0F39; Sun, 19 Aug 2001 09:53:47 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: On disk error, remounting read only ? X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E From: Vincent Bernat Date: 19 Aug 2001 09:53:47 +0200 Message-ID: Lines: 5 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi ! On disk errors, XFS is unmounting the partition. It is a very annoying behaviour when for example there is only an SCSI bus reset. Is it possible to remount the partition read-only instead ? From owner-linux-xfs@oss.sgi.com Sun Aug 19 01:33:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7J8XGR14832 for linux-xfs-outgoing; Sun, 19 Aug 2001 01:33:16 -0700 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 f7J8XEj14812 for ; Sun, 19 Aug 2001 01:33:14 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7J8cC829641 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Sun, 19 Aug 2001 01:38:12 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id KAA181788 for ; Sun, 19 Aug 2001 10:33:05 +0200 (CEST) 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 SAA13341; Sun, 19 Aug 2001 18:31:45 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA17044; Sun, 19 Aug 2001 18:31:44 +1000 (AEST) Date: Sun, 19 Aug 2001 18:31:43 +1000 From: Nathan Scott To: Tang Lingbo Cc: linux-xfs@oss.sgi.com Subject: Re: error in xfs_logprint? Message-ID: <20010819183143.B289205@wobbly.melbourne.sgi.com> References: <20010815150653.25401.qmail@sina.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010815150653.25401.qmail@sina.com>; from tanglb@sina.com on Wed, Aug 15, 2001 at 11:06:52PM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi there, On Wed, Aug 15, 2001 at 11:06:52PM +0800, Tang Lingbo wrote: > Hi, > > There was a core dump in xfs_logprint when I did as follows: > I didn't see a core dump when I ran this, but I did see the error message you describe below... > 1)$ dd if=/dev/zero of=/tmp/xfs bs=1024 count=50000 > 2)$ mkfs.xfs /tmp/xfs > 3)$ mount -t xfs -o loop /tmp/xfs /xfs > 4)$ touch /xfs/test > 5)$ for((i=0;i<1024;i++));do echo -n 1 >> /tmp/dummy;done > 6)$ value=`cat /tmp/dummy`;attr -s test -V $value /xfs/test > 7)$ xfs_logprint /tmp/xfs > > output: > > ... > xlog_print_trans_inode: illegal inode type > > And I think the patch will be as follows: > ...[snip]... > Any comments? > This patch looks good - I'll apply it shortly if that hasn't happened already. Thanks! -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 19 02:58:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7J9wOL16051 for linux-xfs-outgoing; Sun, 19 Aug 2001 02:58:24 -0700 Received: from sina.com ([202.106.187.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7J9wJj16031 for ; Sun, 19 Aug 2001 02:58:21 -0700 Received: (qmail 21401 invoked from network); 19 Aug 2001 09:47:22 -0000 Received: from unknown (HELO linux) (211.156.39.177) by 202.106.187.156 with SMTP; 19 Aug 2001 09:47:22 -0000 Message-ID: <000b01c12895$36ad4dd0$010510ac@linux> From: "Tang Lingbo \(SINA\)" To: "Nathan Scott" Cc: References: <20010815150653.25401.qmail@sina.com> <20010819183143.B289205@wobbly.melbourne.sgi.com> Subject: Re: error in xfs_logprint? Date: Sun, 19 Aug 2001 17:55:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f7J9wMj16033 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > hi there, > > On Wed, Aug 15, 2001 at 11:06:52PM +0800, Tang Lingbo wrote: > > Hi, > > > > There was a core dump in xfs_logprint when I did as follows: > > > > I didn't see a core dump when I ran this, but I did see > the error message you describe below... > Yes, you're right. I did not get a core dump neither. The mistake occured because another error which is not about xfs bored me several days ago. I'm so sorry. > > This patch looks good - I'll apply it shortly if that hasn't > happened already. > I think the information in function xlog_recover_do_inode_trans (in xfs_log_recover.c) will be useful for dealing with the log on disk. My previous patch looks too simpler because there is a possibility to log the modification of the inode's data fork and attribute fork simultaneously. Anything I missed? Thank you for nice work on XFS! Best Regards, Tang Lingbo From owner-linux-xfs@oss.sgi.com Sun Aug 19 03:03:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JA3ZI16265 for linux-xfs-outgoing; Sun, 19 Aug 2001 03:03:35 -0700 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 f7JA3Xj16246 for ; Sun, 19 Aug 2001 03:03:33 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7JA9Xa18712 for ; Sun, 19 Aug 2001 03:09:33 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA85443 for linux-xfs@oss.sgi.com; Sun, 19 Aug 2001 20:02:08 +1000 (EST) Date: Sun, 19 Aug 2001 20:02:08 +1000 (EST) From: Nathan Scott Message-Id: <200108191002.UAA85443@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Aug 16 15:36:38 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:100956a cmd/xfsprogs/libdisk/liblvm.h - 1.3 - nuke include of linux/autoconf.h as it seems to cause problems on some distros. Date: Sun Aug 19 02:59:52 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101028a cmd/xfsprogs/mkfs/proto.c - 1.4 - fix up the error handling for certain corner cases - an error code isn't particularly useful on its own. cmd/xfsprogs/logprint/log_misc.c - 1.7 - fix a bug in the reporting of extended attributes. thanks to Tang Lingbo for the fix. cmd/xfsprogs/libxfs/util.c - 1.4 - its possible to get a successful return result from xfs_dialloc (via xfs_fix_freelist indirectly) where an inode was not successfully allocated &n error did not occur - we explicitly guard against this case now and propogate a meaningful return status back up the stack, so that mkfs/repair can make appropriate diagnostics. cmd/xfsprogs/doc/CHANGES - 1.33 - document things changed so far. From owner-linux-xfs@oss.sgi.com Sun Aug 19 10:40:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JHeqV26593 for linux-xfs-outgoing; Sun, 19 Aug 2001 10:40:52 -0700 Received: from reefedge.reefedge.com (IDENT:root@reefedge.com [216.10.14.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JHeoj26574 for ; Sun, 19 Aug 2001 10:40:50 -0700 Received: (from tls@localhost) by reefedge.reefedge.com (8.10.1/8.10.1) id f7JHenH28754 for linux-xfs@oss.sgi.com; Sun, 19 Aug 2001 13:40:49 -0400 Date: Sun, 19 Aug 2001 13:40:49 -0400 From: tls@reefedge.com To: linux-xfs@oss.sgi.com Subject: "0-order allocation failed" Message-ID: <20010819134049.A28720@reefedge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We're building a server for a CVS repository consisting of several tens of thousands of files; about 1.5GB of data total. It's a two-processor Pentium-III machine with a Mylex RAID controller and 4GB of RAM. We installed from the RH7.1/XFS 1.0.1 media, built a 2.4.5 kernel with the XFS 1.0.1 patches, copied the repository into place and ran a small script that copied the repository four times, copied the resulting directory, then removed both copies. I let it run overnight -- came in this morning to find that the first time I ran any command that generated any disk I/O on the box, I got dozens of "0 order alloc failed" messages on the console and then a hard hang. I see mention of this bug in a list message from April, but nothing since then. Has it been fixed, or even analyzed? If it's been fixed, is there a simple patch against 1.0.1 or will I need to run the latest from CVS? Thor From owner-linux-xfs@oss.sgi.com Sun Aug 19 11:00:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JI0Kj26925 for linux-xfs-outgoing; Sun, 19 Aug 2001 11:00:20 -0700 Received: from smtp7.xs4all.nl (smtp7.xs4all.nl [194.109.127.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JI0Hj26906 for ; Sun, 19 Aug 2001 11:00:17 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp7.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA14363; Sun, 19 Aug 2001 20:00:13 +0200 (CEST) Message-Id: <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 19 Aug 2001 19:59:39 +0200 To: tls@reefedge.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: "0-order allocation failed" In-Reply-To: <20010819134049.A28720@reefedge.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:40 19-8-2001 -0400, tls@reefedge.com wrote: >We're building a server for a CVS repository consisting of several tens >of thousands of files; about 1.5GB of data total. It's a two-processor >Pentium-III machine with a Mylex RAID controller and 4GB of RAM. > >We installed from the RH7.1/XFS 1.0.1 media, built a 2.4.5 kernel with >the XFS 1.0.1 patches, copied the repository into place and ran a small >script that copied the repository four times, copied the resulting directory, >then removed both copies. > >I let it run overnight -- came in this morning to find that the first time >I ran any command that generated any disk I/O on the box, I got dozens of >"0 order alloc failed" messages on the console and then a hard hang. The error message is a general kernel error message which seems to be a highmem problem. >I see mention of this bug in a list message from April, but nothing since >then. Has it been fixed, or even analyzed? If it's been fixed, is there a >simple patch against 1.0.1 or will I need to run the latest from CVS? I guess that using a kernel later then 2.4.5 may help but this is not directly a XFS related error but XFS will help exposing this message because it pushes the VM harder. I don't know if the highmem stuff is significantly better in 2.4.9. That is the current CVS tree version which is probably your best bet for testing. A 2.4.8 patch is also available on the FTP site. Cheers >Thor -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Aug 19 11:10:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JIAXF27174 for linux-xfs-outgoing; Sun, 19 Aug 2001 11:10:33 -0700 Received: from mx0.break.net (mx0.break.net [194.134.79.76]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JIAVj27154 for ; Sun, 19 Aug 2001 11:10:31 -0700 Received: from hurricane.euronet.nl (node0844.a2000.nl [62.108.8.68]) by mx0.break.net (8.11.4/8.11.4) with ESMTP id f7JIJrE12416 for ; Sun, 19 Aug 2001 20:19:53 +0200 X-NCC-RegID: nl.euronet Message-Id: <5.1.0.14.2.20010819200936.02a026c0@pop.euronet.nl> X-Sender: sengaia@pop.euronet.nl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 19 Aug 2001 20:09:44 +0200 To: linux-xfs@oss.sgi.com From: Arjen Wolfs Subject: Re: "0-order allocation failed" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 07:40 PM 8/19/2001, you wrote: >We're building a server for a CVS repository consisting of several tens >of thousands of files; about 1.5GB of data total. It's a two-processor >Pentium-III machine with a Mylex RAID controller and 4GB of RAM. > >We installed from the RH7.1/XFS 1.0.1 media, built a 2.4.5 kernel with >the XFS 1.0.1 patches, copied the repository into place and ran a small >script that copied the repository four times, copied the resulting directory, >then removed both copies. > >I let it run overnight -- came in this morning to find that the first time >I ran any command that generated any disk I/O on the box, I got dozens of >"0 order alloc failed" messages on the console and then a hard hang. > >I see mention of this bug in a list message from April, but nothing since >then. Has it been fixed, or even analyzed? If it's been fixed, is there a >simple patch against 1.0.1 or will I need to run the latest from CVS? Hi, I've had the sampe problem with highmem+smp kernels, random hangs and 0-order allocation failed messages. The first version that worked for me was the patch against 2.4.7; it's been very stable so far. Give it a try... Arjen Wolfs From owner-linux-xfs@oss.sgi.com Sun Aug 19 12:00:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JJ0sa27879 for linux-xfs-outgoing; Sun, 19 Aug 2001 12:00:54 -0700 Received: from reefedge.reefedge.com (IDENT:root@reefedge.com [216.10.14.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JJ0pj27860 for ; Sun, 19 Aug 2001 12:00:51 -0700 Received: (from tls@localhost) by reefedge.reefedge.com (8.10.1/8.10.1) id f7JJ0oY29372 for linux-xfs@oss.sgi.com; Sun, 19 Aug 2001 15:00:50 -0400 Date: Sun, 19 Aug 2001 15:00:50 -0400 From: tls@reefedge.com To: linux-xfs@oss.sgi.com Subject: Re: "0-order allocation failed" Message-ID: <20010819150050.A29326@reefedge.com> References: <20010819134049.A28720@reefedge.com> <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl>; from knuffie@xs4all.nl on Sun, Aug 19, 2001 at 07:59:39PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Aug 19, 2001 at 07:59:39PM +0200, Seth Mos wrote: > > The error message is a general kernel error message which seems to be a > highmem problem. I don't see it unless I use XFS. I don't see it, on this exact same system, with ext2 or reiserfs. > >I see mention of this bug in a list message from April, but nothing since > >then. Has it been fixed, or even analyzed? If it's been fixed, is there a > >simple patch against 1.0.1 or will I need to run the latest from CVS? > > I guess that using a kernel later then 2.4.5 may help but this is not > directly a XFS related error but XFS will help exposing this message > because it pushes the VM harder. What does "pushes the VM harder" mean, in this context? > I don't know if the highmem stuff is significantly better in 2.4.9. > That is the current CVS tree version which is probably your best bet for > testing. A 2.4.8 patch is also available on the FTP site. I noticed a later list message suggesting that a change to XFS in the 2.4.6 timeframe should significantly improve stability on highmem machines; I also found a message suggesting that there were deadlocks elsewhere in the Linux kernel on highmem machines until 2.4.7. So I had high hopes for the 2.4.9 patch. Unfortunately, though I haven't gotten the machine to hang hard yet, I'm now running 2.4.9 and a simple cp -R of our CVS repository from one directory on an XFS filesystem to another produces the "0 order alloc" messages. Is this actually believed to be fixed at the moment, or not? Looks like not, but I'll leave this running for a few hours and see if I can get an actual hang. Thor From owner-linux-xfs@oss.sgi.com Sun Aug 19 12:16:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JJGbF28192 for linux-xfs-outgoing; Sun, 19 Aug 2001 12:16:37 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JJGXj28173 for ; Sun, 19 Aug 2001 12:16:33 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA27327; Sun, 19 Aug 2001 21:16:30 +0200 (CEST) Message-Id: <4.3.2.7.2.20010819210820.042d8790@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 19 Aug 2001 21:15:55 +0200 To: tls@reefedge.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: "0-order allocation failed" In-Reply-To: <20010819150050.A29326@reefedge.com> References: <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> <20010819134049.A28720@reefedge.com> <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:00 19-8-2001 -0400, tls@reefedge.com wrote: >On Sun, Aug 19, 2001 at 07:59:39PM +0200, Seth Mos wrote: > > > > The error message is a general kernel error message which seems to be a > > highmem problem. > >I don't see it unless I use XFS. I don't see it, on this exact same >system, with ext2 or reiserfs. That's possible, but it is not limited to XFS. > > >I see mention of this bug in a list message from April, but nothing since > > >then. Has it been fixed, or even analyzed? If it's been fixed, is > there a > > >simple patch against 1.0.1 or will I need to run the latest from CVS? > > > > I guess that using a kernel later then 2.4.5 may help but this is not > > directly a XFS related error but XFS will help exposing this message > > because it pushes the VM harder. > >What does "pushes the VM harder" mean, in this context? If the filesystem endures high throughput will put more pressure on the memory that is being used. The "0 order allocation" message is trying to tll you that it didn't succeed in allocating memory. > > I don't know if the highmem stuff is significantly better in 2.4.9. > > That is the current CVS tree version which is probably your best bet for > > testing. A 2.4.8 patch is also available on the FTP site. > >I noticed a later list message suggesting that a change to XFS in the 2.4.6 >timeframe should significantly improve stability on highmem machines; I also >found a message suggesting that there were deadlocks elsewhere in the Linux >kernel on highmem machines until 2.4.7. So I had high hopes for the 2.4.9 >patch. 2.4.9 is not available as a patch on the FTP site yet and you will need to fetch it from CVS. >Unfortunately, though I haven't gotten the machine to hang hard yet, I'm >now running 2.4.9 and a simple cp -R of our CVS repository from one directory >on an XFS filesystem to another produces the "0 order alloc" messages. These are rather irritating but not related to XFS. If you push ext2 or reiserfs hard enough they will show up as well. >Is this actually believed to be fixed at the moment, or not? Looks like >not, but I'll leave this running for a few hours and see if I can get an >actual hang. The message is fairly harmless for now but the box should at least survive this. Stability on highmem is at least better then what it used to be. >Thor 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 Sun Aug 19 12:26:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JJQim28421 for linux-xfs-outgoing; Sun, 19 Aug 2001 12:26:44 -0700 Received: from reefedge.reefedge.com (IDENT:root@reefedge.com [216.10.14.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JJQfj28402 for ; Sun, 19 Aug 2001 12:26:41 -0700 Received: (from tls@localhost) by reefedge.reefedge.com (8.10.1/8.10.1) id f7JJQe929661 for linux-xfs@oss.sgi.com; Sun, 19 Aug 2001 15:26:40 -0400 Date: Sun, 19 Aug 2001 15:26:40 -0400 From: tls@reefedge.com To: linux-xfs@oss.sgi.com Subject: Re: "0-order allocation failed" Message-ID: <20010819152640.A29627@reefedge.com> References: <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> <20010819134049.A28720@reefedge.com> <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> <20010819150050.A29326@reefedge.com> <4.3.2.7.2.20010819210820.042d8790@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <4.3.2.7.2.20010819210820.042d8790@pop.xs4all.nl>; from knuffie@xs4all.nl on Sun, Aug 19, 2001 at 09:15:55PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Aug 19, 2001 at 09:15:55PM +0200, Seth Mos wrote: > > > >I noticed a later list message suggesting that a change to XFS in the 2.4.6 > >timeframe should significantly improve stability on highmem machines; I also > >found a message suggesting that there were deadlocks elsewhere in the Linux > >kernel on highmem machines until 2.4.7. So I had high hopes for the 2.4.9 > >patch. > > 2.4.9 is not available as a patch on the FTP site yet and you will need to > fetch it from CVS. Actually, it appears to have been on the FTP site for a couple of days. Do you see any reason I shouldn't run it? > >Unfortunately, though I haven't gotten the machine to hang hard yet, I'm > >now running 2.4.9 and a simple cp -R of our CVS repository from one directory > >on an XFS filesystem to another produces the "0 order alloc" messages. > > These are rather irritating but not related to XFS. If you push ext2 or > reiserfs hard enough they will show up as well. Hm. I can't seem to make it happen, but I'll take your word for it. Is it too complex, or would you mind giving me a thumbnail sketch of how the memory-allocation path differs in highmem systems that would cause allocation to fail more frequently? I've got a decent background WRT the Unix kernel but the guts of the Linux VM system aren't something I've looked at before in any detail. > >Is this actually believed to be fixed at the moment, or not? Looks like > >not, but I'll leave this running for a few hours and see if I can get an > >actual hang. > > The message is fairly harmless for now but the box should at least survive > this. Stability on highmem is at least better then what it used to be. My copy-copy-delete test has, indeed, been running since I sent the original message and so far it hasn't hung, with 2.4.9 and the patch from the FTP site. I guess I'll have to get over my nervousness about the messages. :-/ Thanks for the help! Thor From owner-linux-xfs@oss.sgi.com Sun Aug 19 12:53:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JJrOq28921 for linux-xfs-outgoing; Sun, 19 Aug 2001 12:53:24 -0700 Received: from smtp7.xs4all.nl (smtp7.xs4all.nl [194.109.127.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JJrLj28900 for ; Sun, 19 Aug 2001 12:53:21 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp7.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA20226; Sun, 19 Aug 2001 21:53:15 +0200 (CEST) Message-Id: <4.3.2.7.2.20010819214824.03deb670@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 19 Aug 2001 21:52:42 +0200 To: tls@reefedge.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: "0-order allocation failed" In-Reply-To: <20010819152640.A29627@reefedge.com> References: <4.3.2.7.2.20010819210820.042d8790@pop.xs4all.nl> <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> <20010819134049.A28720@reefedge.com> <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> <20010819150050.A29326@reefedge.com> <4.3.2.7.2.20010819210820.042d8790@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:26 19-8-2001 -0400, tls@reefedge.com wrote: >On Sun, Aug 19, 2001 at 09:15:55PM +0200, Seth Mos wrote: > > > > > >I noticed a later list message suggesting that a change to XFS in the > 2.4.6 > > >timeframe should significantly improve stability on highmem machines; > I also > > >found a message suggesting that there were deadlocks elsewhere in the > Linux > > >kernel on highmem machines until 2.4.7. So I had high hopes for the 2.4.9 > > >patch. > > > > 2.4.9 is not available as a patch on the FTP site yet and you will need to > > fetch it from CVS. > >Actually, it appears to have been on the FTP site for a couple of days. Do >you see any reason I shouldn't run it? I have been tied up last week which means I have not completely tracked all changes or additions to the FTP site. You can run it safely, it works on my home box but you might check for some patches mentioned on the lkml list for making some stuff compile. > > >Unfortunately, though I haven't gotten the machine to hang hard yet, I'm > > >now running 2.4.9 and a simple cp -R of our CVS repository from one > directory > > >on an XFS filesystem to another produces the "0 order alloc" messages. > > > > These are rather irritating but not related to XFS. If you push ext2 or > > reiserfs hard enough they will show up as well. > >Hm. I can't seem to make it happen, but I'll take your word for it. > >Is it too complex, or would you mind giving me a thumbnail sketch of how >the memory-allocation path differs in highmem systems that would cause >allocation to fail more frequently? I've got a decent background WRT the >Unix kernel but the guts of the Linux VM system aren't something I've looked >at before in any detail. I can't give you an explanation because I have no clue whatsoever. I just follow the list and remember what the smart people say about it so I can answer questions, and they can code. > > >Is this actually believed to be fixed at the moment, or not? Looks like > > >not, but I'll leave this running for a few hours and see if I can get an > > >actual hang. > > > > The message is fairly harmless for now but the box should at least survive > > this. Stability on highmem is at least better then what it used to be. > >My copy-copy-delete test has, indeed, been running since I sent the original >message and so far it hasn't hung, with 2.4.9 and the patch from the FTP >site. I guess I'll have to get over my nervousness about the messages. :-/ Ok :-) >Thanks for the help! > >Thor -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Aug 19 13:41:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JKfuT29887 for linux-xfs-outgoing; Sun, 19 Aug 2001 13:41:56 -0700 Received: from ajpmail.ajpark.co.nz ([203.97.85.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JKfqj29866 for ; Sun, 19 Aug 2001 13:41:53 -0700 Received: from mason.ajpark.int (not verified[192.168.1.202]) by ajpmail.ajpark.co.nz with MailMarshal (4,0,9,0) id ; Mon, 20 Aug 2001 08:38:06 +1200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: oops on reboot damaged filesystem Date: Mon, 20 Aug 2001 08:41:39 +1200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <09259B1E9A747045AEFC8FD791FDC21007B068@mason.ajpark.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: oops on reboot damaged filesystem Thread-Index: AcEo74AU5WzqUZVFEdWO7ABQuh9pSQ== From: "Godfrey Livingstone" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7JKfrj29869 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ___________________________________________________________ This e-mail is intended for the addressee only and may contain privileged and/or confidential information ___________________________________________________________ I have been trying to test out xfs for a while not but the system hard locked up on a regular basis until 2.4.9 which seems reasonably stable. I can get it to crash with a "make -j bzImage" but make -j 20 bzImage" does not crash. As a side note can anyone issue "make -j bzImage" or "make -j modules" and not crash their machine? smp dual celeron 433 with 512mb of ram Anyway my problem is that when I shut down for a reboot I got an oops on reboot. Tried the rescue disk and when the rescue disk looked for installed partitions it found the damaged file system and crashed. How can I get the rescue disk to not look for partitions so that I can effect a repair? Godfrey Livingstone _____________________________________________ A J Park Intellectual Property Lawyers and Consultants Patent and Trade Mark Attorneys New Zealand www.ajpark.com _____________________________________________ From owner-linux-xfs@oss.sgi.com Sun Aug 19 14:02:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JL2IQ30428 for linux-xfs-outgoing; Sun, 19 Aug 2001 14:02:18 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JL2Gj30409 for ; Sun, 19 Aug 2001 14:02:16 -0700 Received: (qmail 82768 invoked from network); 19 Aug 2001 21:02:16 -0000 Received: from mplsdslgw15poola173.mpls.uswest.net (HELO sgi.com) (63.229.196.173) by mplspop2.mpls.uswest.net with SMTP; 19 Aug 2001 21:02:16 -0000 Date: Sun, 19 Aug 2001 15:59:15 -0500 Message-ID: <3B8028A3.F1CEE54@sgi.com> From: "Eric Sandeen" To: "Godfrey Livingstone" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: oops on reboot damaged filesystem References: <09259B1E9A747045AEFC8FD791FDC21007B068@mason.ajpark.int> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Godfrey Livingstone wrote: > How can I get the rescue disk to not look for partitions so that I can > effect a repair? Are you using the 1.0.1 installer with "linux rescue?" What does the crash say? Any informational messages? -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 Aug 19 14:16:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JLGIG30742 for linux-xfs-outgoing; Sun, 19 Aug 2001 14:16:18 -0700 Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JLGFj30723 for ; Sun, 19 Aug 2001 14:16:15 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA24694; Sun, 19 Aug 2001 23:16:10 +0200 (CEST) Message-Id: <4.3.2.7.2.20010819230553.03df5318@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 19 Aug 2001 23:15:32 +0200 To: "Godfrey Livingstone" , From: Seth Mos Subject: Re: oops on reboot damaged filesystem In-Reply-To: <09259B1E9A747045AEFC8FD791FDC21007B068@mason.ajpark.int> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:41 20-8-2001 +1200, Godfrey Livingstone wrote: >I have been trying to test out xfs for a while not but the system hard >locked up on a regular basis until 2.4.9 which seems reasonably stable. >I can get it to crash with a "make -j bzImage" but make -j 20 bzImage" >does not crash. > >As a side note can anyone issue "make -j bzImage" or "make -j modules" >and not crash their machine? I have not encounterd it and I can still play Quake3 as well. >smp dual celeron 433 with 512mb of ram Abit dual celeron motherboard? Do you have the latest bios? A lot of people have reported problems with that motherboard before. Even NT4 can have a hard time operating. (I have a friend with such a motherboard) >Anyway my problem is that when I shut down for a reboot I got an oops on >reboot. Tried the rescue disk and when the rescue disk looked for >installed partitions it found the damaged file system and crashed. > >How can I get the rescue disk to not look for partitions so that I can >effect a repair? AIEE!! Crap. Start the installer just like you would installing the OS. I think you could switch to the second console with ctrl+alt+F2 and then repair the FS but I am not quite sure if you can do it from within the installer. Another thing you could do is follow the link within the FAQ to the rescue boot disks section and download the XFS floppy boot disks. Maybe a last resort but that should always work. http://oss.sgi.com/projects/xfs/faq.html#xfsbootdisks >Godfrey Livingstone 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 Sun Aug 19 14:21:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JLLFF30959 for linux-xfs-outgoing; Sun, 19 Aug 2001 14:21:15 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JLLCj30939 for ; Sun, 19 Aug 2001 14:21:13 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA01412; Sun, 19 Aug 2001 23:21:05 +0200 (CEST) Message-Id: <4.3.2.7.2.20010819231759.03d72630@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 19 Aug 2001 23:20:31 +0200 To: "Eric Sandeen" , "Godfrey Livingstone" From: Seth Mos Subject: Re: oops on reboot damaged filesystem Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B8028A3.F1CEE54@sgi.com> References: <09259B1E9A747045AEFC8FD791FDC21007B068@mason.ajpark.int> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:59 19-8-2001 -0500, Eric Sandeen wrote: >Godfrey Livingstone wrote: > > > How can I get the rescue disk to not look for partitions so that I can > > effect a repair? > >Are you using the 1.0.1 installer with "linux rescue?" What does the >crash say? Any informational messages? As soon as one of the partitions does NOT contain a valid fs it hangs during testing for a partition that contains the /etc/fstab file. It doesn't matter what fs was on it or what state it was in. It seems to be the partition detection code. If the fs was not formatted it would also hang. I guess a damaged fs also works. 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 Sun Aug 19 16:03:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JN3eI32525 for linux-xfs-outgoing; Sun, 19 Aug 2001 16:03:40 -0700 Received: from femail14.sdc1.sfba.home.com (femail14.sdc1.sfba.home.com [24.0.95.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JN3cj32506 for ; Sun, 19 Aug 2001 16:03:38 -0700 Received: from cc983785a ([24.9.84.205]) by femail14.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010819230332.PNYV17193.femail14.sdc1.sfba.home.com@cc983785a> for ; Sun, 19 Aug 2001 16:03:32 -0700 Message-ID: <001e01c12924$b0566ce0$9865fea9@cc983785a> From: "James" To: Subject: Mounting XFS Date: Sun, 19 Aug 2001 23:03:29 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C12903.28F54D50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C12903.28F54D50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings! How should I (or what is the command) to mount a harddrive with = Linux XFS filesystem from a FreeBSD 4.3 box? Thanks in advance James ------=_NextPart_000_001B_01C12903.28F54D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greetings!
    How should I (or = what is the=20 command) to mount a harddrive with Linux XFS filesystem from a FreeBSD = 4.3=20 box?
Thanks in advance
James
------=_NextPart_000_001B_01C12903.28F54D50-- From owner-linux-xfs@oss.sgi.com Sun Aug 19 16:23:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JNNdN00419 for linux-xfs-outgoing; Sun, 19 Aug 2001 16:23:39 -0700 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 f7JNNbj00400 for ; Sun, 19 Aug 2001 16:23:37 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7JNTfa23307 for ; Sun, 19 Aug 2001 16:29:41 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA23336; Mon, 20 Aug 2001 09:22:14 +1000 (EST) Message-Id: <200108192322.JAA23336@snort.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "James" cc: linux-xfs@oss.sgi.com Subject: Re: Mounting XFS In-reply-to: Your message of "Sun, 19 Aug 2001 23:03:29 -0400." <001e01c12924$b0566ce0$9865fea9@cc983785a> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Aug 2001 09:22:14 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "James" writes: => Greetings! => How should I (or what is the command) to mount a harddrive with = => Linux XFS filesystem from a FreeBSD 4.3 box? => Thanks in advance => James SGI has released XFS for Linux, not FreeBSD. Whilst it would be possible to port to FreeBSD, I'm pretty sure the port does not exist. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Aug 19 16:51:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JNp8Z00818 for linux-xfs-outgoing; Sun, 19 Aug 2001 16:51:08 -0700 Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JNp6j00799 for ; Sun, 19 Aug 2001 16:51:06 -0700 Received: from cc983785a ([24.9.84.205]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010819235100.PYUK18956.femail3.sdc1.sfba.home.com@cc983785a>; Sun, 19 Aug 2001 16:51:00 -0700 Message-ID: <000c01c1292b$51d54b30$9865fea9@cc983785a> From: "James" To: "Daniel Moore" Cc: References: <200108192322.JAA23336@snort.melbourne.sgi.com> Subject: Re: Mounting XFS Date: Sun, 19 Aug 2001 23:50:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have some files on a Linux Hard-drive that I need. But the server is running Freebsd now, not linux (Harddrive is still in box) I just want to mount it and pull the files. I need to know the filesystem type to put in the command line mount -t ??? /dev/adc1 /linux Thanks Again! James ----- Original Message ----- From: "Daniel Moore" To: "James" Cc: Sent: Sunday, August 19, 2001 7:22 PM Subject: Re: Mounting XFS > > "James" writes: > > => Greetings! > => How should I (or what is the command) to mount a harddrive with = > => Linux XFS filesystem from a FreeBSD 4.3 box? > => Thanks in advance > => James > > SGI has released XFS for Linux, not FreeBSD. Whilst it would be possible > to port to FreeBSD, I'm pretty sure the port does not exist. > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- > From owner-linux-xfs@oss.sgi.com Sun Aug 19 16:54:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JNsAH00960 for linux-xfs-outgoing; Sun, 19 Aug 2001 16:54:10 -0700 Received: from mplspop6.mpls.uswest.net (pop.mpls.uswest.net [204.147.80.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JNs7j00941 for ; Sun, 19 Aug 2001 16:54:07 -0700 Received: (qmail 61594 invoked from network); 19 Aug 2001 23:54:07 -0000 Received: from mplsdslgw15poolc32.mpls.uswest.net (HELO sgi.com) (63.229.198.32) by mplspop6.mpls.uswest.net with SMTP; 19 Aug 2001 23:54:07 -0000 Date: Sun, 19 Aug 2001 18:51:06 -0500 Message-ID: <3B8050EA.E3AEED4A@sgi.com> From: "Eric Sandeen" To: "James" Cc: "Daniel Moore" , linux-xfs@oss.sgi.com 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 Subject: Re: Mounting XFS References: <200108192322.JAA23336@snort.melbourne.sgi.com> <000c01c1292b$51d54b30$9865fea9@cc983785a> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you're running BSD, and it's an XFS drive, the short answer is, you cannot do it. -Eric James wrote: > > I have some files on a Linux Hard-drive that I need. > But the server is running Freebsd now, not linux (Harddrive is still in box) > I just want to mount it and pull the files. I need to know the filesystem > type to put in the command line > mount -t ??? /dev/adc1 /linux > Thanks Again! > James > ----- Original Message ----- > From: "Daniel Moore" > To: "James" > Cc: > Sent: Sunday, August 19, 2001 7:22 PM > Subject: Re: Mounting XFS > > > > > "James" writes: > > > > => Greetings! > > => How should I (or what is the command) to mount a harddrive with = > > => Linux XFS filesystem from a FreeBSD 4.3 box? > > => Thanks in advance > > => James > > > > SGI has released XFS for Linux, not FreeBSD. Whilst it would be possible > > to port to FreeBSD, I'm pretty sure the port does not exist. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Aug 19 16:55:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7JNtpx01068 for linux-xfs-outgoing; Sun, 19 Aug 2001 16:55:51 -0700 Received: from ntown.esper.com (root@ntown.esper.com [216.111.16.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7JNtmj01049 for ; Sun, 19 Aug 2001 16:55:48 -0700 Received: from kjcwin2k (kcross.ntown.esper.com [216.111.19.212]) by ntown.esper.com (8.11.4/8.11.4) with SMTP id f7K02gE08152; Sun, 19 Aug 2001 20:02:42 -0400 Message-ID: <018301c1290a$6ea42ef0$0200a8c0@kjc2.com> From: "Ken Cross" To: "James" , "Daniel Moore" Cc: References: <200108192322.JAA23336@snort.melbourne.sgi.com> <000c01c1292b$51d54b30$9865fea9@cc983785a> Subject: Re: Mounting XFS Date: Sun, 19 Aug 2001 19:55:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Assuming it's a normal filesystem (not XFS), the command is: mount -t ext2fs /dev/xxx /mnt HTH, Ken ----- Original Message ----- From: "James" To: "Daniel Moore" Cc: Sent: Sunday, August 19, 2001 11:50 PM Subject: Re: Mounting XFS > I have some files on a Linux Hard-drive that I need. > But the server is running Freebsd now, not linux (Harddrive is still in box) > I just want to mount it and pull the files. I need to know the filesystem > type to put in the command line > mount -t ??? /dev/adc1 /linux > Thanks Again! > James > ----- Original Message ----- > From: "Daniel Moore" > To: "James" > Cc: > Sent: Sunday, August 19, 2001 7:22 PM > Subject: Re: Mounting XFS > > > > > > "James" writes: > > > > => Greetings! > > => How should I (or what is the command) to mount a harddrive with = > > => Linux XFS filesystem from a FreeBSD 4.3 box? > > => Thanks in advance > > => James > > > > SGI has released XFS for Linux, not FreeBSD. Whilst it would be possible > > to port to FreeBSD, I'm pretty sure the port does not exist. > > > > ----------------------------------------------------- > > Daniel Moore dxm@sgi.com > > R&D Software Engineer Phone: +61-3-98348209 > > SGI Performance Tools Group Fax: +61-3-98132378 > > ----------------------------------------------------- > > From owner-linux-xfs@oss.sgi.com Sun Aug 19 17:01:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K01ZK01308 for linux-xfs-outgoing; Sun, 19 Aug 2001 17:01:35 -0700 Received: from femail20.sdc1.sfba.home.com (femail20.sdc1.sfba.home.com [24.0.95.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K01Wj01288 for ; Sun, 19 Aug 2001 17:01:32 -0700 Received: from cc983785a ([24.9.84.205]) by femail20.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010820000126.OTBQ14762.femail20.sdc1.sfba.home.com@cc983785a> for ; Sun, 19 Aug 2001 17:01:26 -0700 Message-ID: <004901c1292c$c71eaa20$9865fea9@cc983785a> From: "James" To: References: <200108192322.JAA23336@snort.melbourne.sgi.com> <000c01c1292b$51d54b30$9865fea9@cc983785a> <018301c1290a$6ea42ef0$0200a8c0@kjc2.com> Subject: Re: Mounting XFS Date: Mon, 20 Aug 2001 00:01:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The linux Hard-drive is ide, straight XFS no ext2. Freebsd 4.3 is on a Compaq Raid 5 array. Is there anyway to mount a hardrive from a IRIX box, using Freebsd? cause if so its the same filesystem. Oh well I'm SOL I guess :-). Thanks for the info!! James ----- Original Message ----- From: "Ken Cross" To: "James" ; "Daniel Moore" Cc: Sent: Sunday, August 19, 2001 7:55 PM Subject: Re: Mounting XFS > Assuming it's a normal filesystem (not XFS), the command is: > > mount -t ext2fs /dev/xxx /mnt > > HTH, > Ken > > > ----- Original Message ----- > From: "James" > To: "Daniel Moore" > Cc: > Sent: Sunday, August 19, 2001 11:50 PM > Subject: Re: Mounting XFS > > > > I have some files on a Linux Hard-drive that I need. > > But the server is running Freebsd now, not linux (Harddrive is still in > box) > > I just want to mount it and pull the files. I need to know the filesystem > > type to put in the command line > > mount -t ??? /dev/adc1 /linux > > Thanks Again! > > James > > ----- Original Message ----- > > From: "Daniel Moore" > > To: "James" > > Cc: > > Sent: Sunday, August 19, 2001 7:22 PM > > Subject: Re: Mounting XFS > > > > > > > > > > "James" writes: > > > > > > => Greetings! > > > => How should I (or what is the command) to mount a harddrive with > = > > > => Linux XFS filesystem from a FreeBSD 4.3 box? > > > => Thanks in advance > > > => James > > > > > > SGI has released XFS for Linux, not FreeBSD. Whilst it would be possible > > > to port to FreeBSD, I'm pretty sure the port does not exist. > > > > > > ----------------------------------------------------- > > > Daniel Moore dxm@sgi.com > > > R&D Software Engineer Phone: +61-3-98348209 > > > SGI Performance Tools Group Fax: +61-3-98132378 > > > ----------------------------------------------------- > > > > From owner-linux-xfs@oss.sgi.com Sun Aug 19 17:24:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K0OmQ01764 for linux-xfs-outgoing; Sun, 19 Aug 2001 17:24:48 -0700 Received: from mail.seefried.com ([205.215.35.60]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K0Okj01745 for ; Sun, 19 Aug 2001 17:24:47 -0700 Received: (qmail 18622 invoked by uid 500); 20 Aug 2001 00:18:17 -0000 Message-ID: <20010820001817.18621.qmail@mail.seefried.com> References: <200108192322.JAA23336@snort.melbourne.sgi.com> <000c01c1292b$51d54b30$9865fea9@cc983785a> <018301c1290a$6ea42ef0$0200a8c0@kjc2.com> <004901c1292c$c71eaa20$9865fea9@cc983785a> In-Reply-To: <004901c1292c$c71eaa20$9865fea9@cc983785a> From: "Ken Seefried" To: "James" Cc: linux-xfs@oss.sgi.com Subject: Re: Mounting XFS Date: Mon, 20 Aug 2001 00:18:17 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 James writes: > Is there anyway to mount a hardrive from a IRIX box, using Freebsd? cause > if so its the same filesystem. No. At least, not until the FreeBSD folks port XFS. Of course, it's really quite easy to load Linux+XFS, if you've got a spare PC laying about. Ken From owner-linux-xfs@oss.sgi.com Sun Aug 19 17:35:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K0Zp302122 for linux-xfs-outgoing; Sun, 19 Aug 2001 17:35:51 -0700 Received: from femail7.sdc1.sfba.home.com (femail7.sdc1.sfba.home.com [24.0.95.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K0Znj02103 for ; Sun, 19 Aug 2001 17:35:49 -0700 Received: from cc983785a ([24.9.84.205]) by femail7.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010820003543.RPRL817.femail7.sdc1.sfba.home.com@cc983785a>; Sun, 19 Aug 2001 17:35:43 -0700 Message-ID: <006a01c12931$91851980$9865fea9@cc983785a> From: "James" To: "Ken Seefried" Cc: References: <200108192322.JAA23336@snort.melbourne.sgi.com> <000c01c1292b$51d54b30$9865fea9@cc983785a> <018301c1290a$6ea42ef0$0200a8c0@kjc2.com> <004901c1292c$c71eaa20$9865fea9@cc983785a> <20010820001817.18621.qmail@mail.seefried.com> Subject: Re: Mounting XFS Date: Mon, 20 Aug 2001 00:35:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk true, I do got another PC, I'll load or bring the HD over to it and ftp the files over. I knew I'll get the answer :-) So do the XFS need to be ported over so FreeBSD will have a XFS filesystem or Support for XFS (reading and writing to) need to be ported over? Sorry I'm not a UNIX guru but I'm learning. But I am a Sun Field Engineer so I'm not too stupid LoL. James PS. I did seen post dealing with FreeBSD and XFS So I'm not trying to start a repeat of what was said. ----- Original Message ----- From: "Ken Seefried" To: "James" Cc: Sent: Sunday, August 19, 2001 8:18 PM Subject: Re: Mounting XFS > James writes: > > Is there anyway to mount a hardrive from a IRIX box, using Freebsd? cause > > if so its the same filesystem. > > No. At least, not until the FreeBSD folks port XFS. > > Of course, it's really quite easy to load Linux+XFS, if you've got a spare > PC laying about. > > Ken > From owner-linux-xfs@oss.sgi.com Sun Aug 19 17:44:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K0i4r02350 for linux-xfs-outgoing; Sun, 19 Aug 2001 17:44:04 -0700 Received: from ntown.esper.com (root@ntown.esper.com [216.111.16.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K0i1j02331 for ; Sun, 19 Aug 2001 17:44:02 -0700 Received: from kjcwin2k (kcross.ntown.esper.com [216.111.19.212]) by ntown.esper.com (8.11.4/8.11.4) with SMTP id f7K0oaE10438; Sun, 19 Aug 2001 20:50:36 -0400 Message-ID: <01b301c12911$1f5bd760$0200a8c0@kjc2.com> From: "Ken Cross" To: "James" , "Ken Seefried" Cc: References: <200108192322.JAA23336@snort.melbourne.sgi.com> <000c01c1292b$51d54b30$9865fea9@cc983785a> <018301c1290a$6ea42ef0$0200a8c0@kjc2.com> <004901c1292c$c71eaa20$9865fea9@cc983785a> <20010820001817.18621.qmail@mail.seefried.com> <006a01c12931$91851980$9865fea9@cc983785a> Subject: Re: Mounting XFS Date: Sun, 19 Aug 2001 20:43:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Don't count on XFS in FreeBSD anytime soon -- I suspect that there are licensing issues that probably eclipse the technical ones. Ken ----- Original Message ----- From: "James" To: "Ken Seefried" Cc: Sent: Monday, August 20, 2001 12:35 AM Subject: Re: Mounting XFS > true, I do got another PC, I'll load or bring the HD over to it and ftp the > files over. > I knew I'll get the answer :-) > So do the XFS need to be ported over so FreeBSD will have a XFS filesystem > or Support for XFS (reading and writing to) need to be ported over? Sorry > I'm not a UNIX guru but I'm learning. But I am a Sun Field Engineer so I'm > not too stupid LoL. > James > PS. I did seen post dealing with FreeBSD and XFS > So I'm not trying to start a repeat of what was said. > > ----- Original Message ----- > From: "Ken Seefried" > To: "James" > Cc: > Sent: Sunday, August 19, 2001 8:18 PM > Subject: Re: Mounting XFS > > > > James writes: > > > Is there anyway to mount a hardrive from a IRIX box, using Freebsd? > cause > > > if so its the same filesystem. > > > > No. At least, not until the FreeBSD folks port XFS. > > > > Of course, it's really quite easy to load Linux+XFS, if you've got a spare > > PC laying about. > > > > Ken > > From owner-linux-xfs@oss.sgi.com Sun Aug 19 18:55:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K1tu103426 for linux-xfs-outgoing; Sun, 19 Aug 2001 18:55:56 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K1trj03406 for ; Sun, 19 Aug 2001 18:55:53 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id E34781E698; Mon, 20 Aug 2001 03:55:47 +0200 (MEST) Date: Mon, 20 Aug 2001 03:55:39 +0200 From: Andi Kleen To: Ken Cross Cc: James , Ken Seefried , linux-xfs@oss.sgi.com Subject: Re: Mounting XFS Message-ID: <20010820035539.A32009@gruyere.muc.suse.de> References: <200108192322.JAA23336@snort.melbourne.sgi.com> <000c01c1292b$51d54b30$9865fea9@cc983785a> <018301c1290a$6ea42ef0$0200a8c0@kjc2.com> <004901c1292c$c71eaa20$9865fea9@cc983785a> <20010820001817.18621.qmail@mail.seefried.com> <006a01c12931$91851980$9865fea9@cc983785a> <01b301c12911$1f5bd760$0200a8c0@kjc2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01b301c12911$1f5bd760$0200a8c0@kjc2.com>; from kcross@ntown.com on Sun, Aug 19, 2001 at 08:43:25PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Aug 19, 2001 at 08:43:25PM -0400, Ken Cross wrote: > Don't count on XFS in FreeBSD anytime soon -- I suspect that there are > licensing issues that probably eclipse the technical ones. There shouldn't be. FreeBSD already has GPLed file systems even in tree, like their ext2 port. -Andi From owner-linux-xfs@oss.sgi.com Sun Aug 19 19:13:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K2DuC03827 for linux-xfs-outgoing; Sun, 19 Aug 2001 19:13:56 -0700 Received: from mail.1ar.org ([202.88.157.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K2Dpj03808 for ; Sun, 19 Aug 2001 19:13:52 -0700 Received: from localhost (localhost.1ar.org [127.0.0.1]) by mail.1ar.org (Postfix) with ESMTP id 5D49E1C00091; Mon, 20 Aug 2001 07:43:45 +0530 (IST) Date: Mon, 20 Aug 2001 07:43:45 +0530 (IST) From: Ajay Ramaswamy To: Eric Sandeen Cc: Subject: Installer rescue mode In-Reply-To: <3B8028A3.F1CEE54@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, I had the same problem with the installer, that rescue mode did not work, I found that the problem is in the modules included in the boot disk, some whare in the anaconda-xfs.patch you have a line in the file anaconda/scripts/mk-images.i386 which loads the vfat file system modules. here you should also load msdos and fat along with vfat. I just created a hybrid installer using the latest xfs userspace tools and the redhat updates over the 1.0.1, but since I hacked away many of the install screens my patch would need to be regenerated ( no sgi confirm screen, no firewall config, many extra packages in comps etc etc) As Seth mentions In case I dont have any non xfs or ext2 which are in the kernel the rescue mode works fine but when I have vfat / fat / ntfs partitions too it hangs Hope this helps regards Ajay From owner-linux-xfs@oss.sgi.com Sun Aug 19 20:02:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K32i104623 for linux-xfs-outgoing; Sun, 19 Aug 2001 20:02:44 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K32fj04604 for ; Sun, 19 Aug 2001 20:02:41 -0700 Received: (qmail 21946 invoked from network); 20 Aug 2001 03:02:43 -0000 Received: from mplsdslgw15poolc32.mpls.uswest.net (HELO sgi.com) (63.229.198.32) by mplspop2.mpls.uswest.net with SMTP; 20 Aug 2001 03:02:43 -0000 Date: Sun, 19 Aug 2001 21:59:39 -0500 Message-ID: <3B807D1B.E7E6E898@sgi.com> From: "Eric Sandeen" To: "Ajay Ramaswamy" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: Installer rescue mode References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ajay Ramaswamy wrote: > > Eric, > I had the same problem with the installer, that rescue mode did not work, > I found that the problem is in the modules included in the boot disk, some > whare in the anaconda-xfs.patch you have a line in the file > anaconda/scripts/mk-images.i386 which loads the vfat file system modules. > here you should also load msdos and fat along with vfat. Interesting, I don't think we changed any of this, looking at the patch for mk-images.i386, all we do is add XFS to the mix. msdos and vfat are available in the second stage of the installer: -SECSTAGE="msdos vfat raid0 raid1 raid5 $IDEMODS $SCSIMODS $LATEUSBMODS" +SECSTAGE="xfs msdos vfat raid0 raid1 raid5 $IDEMODS $SCSIMODS $LATEUSBMODS" but Red Hat never had the fat module available on i386, although they do in ia64... so not sure what's going on! Perhaps this is a bug in Red Hat as well? One way around this might be to turn off the controller (or otherwise BIOS-disable) the drive with the offending filesystem, assuming it's on a separate drive... -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 Aug 19 20:37:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K3bm305166 for linux-xfs-outgoing; Sun, 19 Aug 2001 20:37:48 -0700 Received: from ntown.esper.com (root@ntown.esper.com [216.111.16.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K3bkj05147 for ; Sun, 19 Aug 2001 20:37:46 -0700 Received: from kjcwin2k (kcross.ntown.esper.com [216.111.19.212]) by ntown.esper.com (8.11.4/8.11.4) with SMTP id f7K3iOE18353; Sun, 19 Aug 2001 23:44:25 -0400 Message-ID: <021001c12929$668dede0$0200a8c0@kjc2.com> From: "Ken Cross" To: "James" , "Ken Seefried" , References: <200108192322.JAA23336@snort.melbourne.sgi.com> <000c01c1292b$51d54b30$9865fea9@cc983785a> <018301c1290a$6ea42ef0$0200a8c0@kjc2.com> <004901c1292c$c71eaa20$9865fea9@cc983785a> <20010820001817.18621.qmail@mail.seefried.com> <006a01c12931$91851980$9865fea9@cc983785a> <01b301c12911$1f5bd760$0200a8c0@kjc2.com> <20010820035539.A32009@gruyere.muc.suse.de> Subject: Re: Mounting XFS Date: Sun, 19 Aug 2001 23:37:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, that's true, but if you include ext2 support, the build process warns you that it is "contaminated" (their word, not mine) with GPL code for ext2 support. Still, if they can do it for ext2, they could do it for XFS if they wanted to. Ken > On Sun, Aug 19, 2001 at 08:43:25PM -0400, Ken Cross wrote: > > Don't count on XFS in FreeBSD anytime soon -- I suspect that there are > > licensing issues that probably eclipse the technical ones. > > There shouldn't be. FreeBSD already has GPLed file systems even in tree, > like their ext2 port. > > -Andi From owner-linux-xfs@oss.sgi.com Sun Aug 19 23:48:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K6mDi08084 for linux-xfs-outgoing; Sun, 19 Aug 2001 23:48:13 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K6mAj08065 for ; Sun, 19 Aug 2001 23:48:11 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA15159 for ; Mon, 20 Aug 2001 08:48:08 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA08855 for linux-xfs@oss.sgi.com; Mon, 20 Aug 2001 08:48:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 24A4E57306 for ; Mon, 20 Aug 2001 08:47:11 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id EAA5325835 for ; Mon, 20 Aug 2001 08:47:10 +0200 (CEST) Message-ID: <3B80B26E.1451FA7@ch.sauter-bc.com> Date: Mon, 20 Aug 2001 08:47:10 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Mandrake Linux 8.1 beta without XFS Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The Mandrake people have released 8.1 beta but unfortunately without support for the XFS filesystem. They included ReiserFS, JFS and ext3. It's sad to realize that my favorite distributions RedHat and Mandrake seem not to include XFS support in their next releases. What is the problem with XFS? I know it's difficult to patch the kernel if you already apply tons of patches anyway. But beside that it's one of the best filesystems our planet has. It's GPL and very well integrated into Linux. What do they want more. If they want their distributions to be enterprise ready, LVM and XFS are a must. I hate to say this but even win2k has it already (I mean 'dynamic disks' and journaling filesystem). I hope they will change their mind and include XFS as well. What do you think about it? -Simon From owner-linux-xfs@oss.sgi.com Sun Aug 19 23:58:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K6w4b08352 for linux-xfs-outgoing; Sun, 19 Aug 2001 23:58:04 -0700 Received: from rebel.net.au (IDENT:root@www.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K6w2j08333 for ; Sun, 19 Aug 2001 23:58:02 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id QAA11550; Mon, 20 Aug 2001 16:27:43 +0930 Message-ID: <3B80B63E.22BD088B@rebel.net.au> Date: Mon, 20 Aug 2001 16:33:26 +0930 From: David Lloyd 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: Simon Matter CC: linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > What do you think about it? It's not in because it's not in an approved Linus kernel. ReiserFS etc etc are... DSL From owner-linux-xfs@oss.sgi.com Mon Aug 20 00:06:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K76oF08605 for linux-xfs-outgoing; Mon, 20 Aug 2001 00:06:50 -0700 Received: from mail.spylog.com (mail.spylog.com [194.67.35.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K76lj08586 for ; Mon, 20 Aug 2001 00:06:48 -0700 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id C53622C1ED for ; Mon, 20 Aug 2001 11:06:41 +0400 (MSD) Received: by an.local (Postfix, from userid 1000) id 73C37142C1; Mon, 20 Aug 2001 11:06:41 +0400 (MSD) Date: Mon, 20 Aug 2001 11:06:41 +0400 From: Andrey Nekrasov To: linux-xfs@oss.sgi.com Subject: Re: "0-order allocation failed" Message-ID: <20010820110641.B8572@spylog.ru> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010819134049.A28720@reefedge.com> <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20010819195213.03383778@pop.xs4all.nl> User-Agent: Mutt/1.3.20i Organization: SpyLOG ltd. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Seth Mos, > >of thousands of files; about 1.5GB of data total. It's a two-processor > >Pentium-III machine with a Mylex RAID controller and 4GB of RAM. > > > >We installed from the RH7.1/XFS 1.0.1 media, built a 2.4.5 kernel with > >the XFS 1.0.1 patches, copied the repository into place and ran a small > >script that copied the repository four times, copied the resulting > >directory, > >then removed both copies. > > > >I let it run overnight -- came in this morning to find that the first time > >I ran any command that generated any disk I/O on the box, I got dozens of > >"0 order alloc failed" messages on the console and then a hard hang. > > The error message is a general kernel error message which seems to be a > highmem problem. linux kernel 2.4.8-ac7 not has this problem, but not have XFS. :-( > >I see mention of this bug in a list message from April, but nothing since > >then. Has it been fixed, or even analyzed? If it's been fixed, is there a > >simple patch against 1.0.1 or will I need to run the latest from CVS? > > I guess that using a kernel later then 2.4.5 may help but this is not > directly a XFS related error but XFS will help exposing this message > because it pushes the VM harder. > > I don't know if the highmem stuff is significantly better in 2.4.9. > That is the current CVS tree version which is probably your best bet for > testing. A 2.4.8 patch is also available on the FTP site. -- bye. Andrey Nekrasov, SpyLOG. From owner-linux-xfs@oss.sgi.com Mon Aug 20 00:11:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K7BeJ08837 for linux-xfs-outgoing; Mon, 20 Aug 2001 00:11:40 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K7Bbj08815 for ; Mon, 20 Aug 2001 00:11:37 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA19032; Mon, 20 Aug 2001 09:11:20 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA10554; Mon, 20 Aug 2001 09:11:20 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 2051B57306; Mon, 20 Aug 2001 09:06:39 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 1554C25835; Mon, 20 Aug 2001 09:06:38 +0200 (CEST) Message-ID: <3B80B6FD.7ACC024C@ch.sauter-bc.com> Date: Mon, 20 Aug 2001 09:06:37 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: David Lloyd Cc: linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B80B63E.22BD088B@rebel.net.au> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk David Lloyd schrieb: > > > > > What do you think about it? > > It's not in because it's not in an approved Linus kernel. ReiserFS etc > etc are... Am I dreaming? What Linus approved kernel do you have with ext3 and JFS? > > DSL BTW, here's the link http://www.linux-mandrake.com/en/test81beta1.php3 -Simon From owner-linux-xfs@oss.sgi.com Mon Aug 20 00:33:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K7XHc09260 for linux-xfs-outgoing; Mon, 20 Aug 2001 00:33:17 -0700 Received: from rebel.net.au (IDENT:root@news.tellurian.com.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K7XFj09241 for ; Mon, 20 Aug 2001 00:33:15 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id RAA12584; Mon, 20 Aug 2001 17:03:06 +0930 Message-ID: <3B80BE88.3406B333@rebel.net.au> Date: Mon, 20 Aug 2001 17:08:48 +0930 From: David Lloyd 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: Simon Matter CC: linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B80B63E.22BD088B@rebel.net.au> <3B80B6FD.7ACC024C@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk No, you're not dreaming ;-P > Am I dreaming? What Linus approved kernel do you have with ext3 and JFS? A lot of the distribution makers don't include stuff not included with the Linus approved kernel. Some of them do - at their own peril - and it's hit and miss what extras are included and what extras are not. DSL From owner-linux-xfs@oss.sgi.com Mon Aug 20 01:01:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K81HZ09771 for linux-xfs-outgoing; Mon, 20 Aug 2001 01:01:17 -0700 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 f7K81Cj09752 for ; Mon, 20 Aug 2001 01:01:12 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7K87Ga29479 for ; Mon, 20 Aug 2001 01:07:17 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA06728 for linux-xfs@oss.sgi.com; Mon, 20 Aug 2001 17:59:49 +1000 (EST) Date: Mon, 20 Aug 2001 17:59:49 +1000 (EST) From: Nathan Scott Message-Id: <200108200759.RAA06728@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - external logs, debug builds Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Several kernel fixes: - external logs and realtime devices should now do correct reference counting (thanks to Andrew Morton for sending us the patch implementing this in the ext3 external log code - we do things in a similar way now); - several cleanups on the mount path as aresult of this; - the min macro stuff for pagebuf (got condition min define from Andreas Piesk's patch - thanks!); - accidentally stumbled across several problems when STATIC is defined to be "static", so made various minor fixes to get this back to how its supposed to be; - debug builds didn't do everything they once did - some cflags got dropped in the Makefile rework; - fix a vnode reference count problem in the unfreeze code - some cosmetic read_super and arg parsing tidyups. cheers. Date: Sun Aug 19 22:43:29 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101036a linux/include/linux/page_buf.h - 1.98 - remove old definition of "min". linux/fs/pagebuf/page_buf_io.c - 1.93 - fix up use of the "min" macro - now takes three args. Date: Mon Aug 20 00:39:46 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101038a linux/fs/xfs/xfs_rw.c - 1.343 linux/fs/xfs/xfs_qm_syscalls.c - 1.53 - remove a prototype for a non-existant function. linux/fs/xfs/xfs_buf.h - 1.75 - add a block_device pointer to the buftarg structure. needed for the external log/realtime volume device ref counting fixups. linux/fs/xfs/xfs_vfsops.c - 1.323 - fixups related to external log/realtime volume device ref counting. remove a bunch of dead code dealing with mounting root on IRIX, and the mount ABI on IRIX. linux/fs/xfs/xfs_clnt.h - 1.24 - add a big comment about differences between mount on IRIX and Linux. rework so that all the IRIX ABI structures are no longer there and add fields to the xfs_args struct needed for the external log/realtime volume device ref counting fixups. linux/fs/xfs/xfs_mount.c - 1.260 - fixups related to external log/realtime volume device ref counting. linux/fs/xfs/xfs_trans.c - 1.123 - fix a compile warning generated in that last sync with IRIX code (NULL isn't an integer). linux/fs/xfs/xfs_acl.c - 1.6 linux/fs/xfs/xfs_dmapi.h - 1.16 linux/fs/xfs/linux/xfs_lrw.h - 1.18 linux/fs/xfs/linux/xfs_lrw.c - 1.107 - fix up STATIC functions. linux/fs/xfs/linux/xfs_linux.h - 1.51 - default to STATIC being "static", but not so for debug builds. linux/fs/xfs/Makefile - 1.122 linux/fs/xfs/Makefile.in - 1.2 linux/fs/xfs/linux/Makefile - 1.42 - fix up static for debug builds, also want -g for debug builds. linux/fs/xfs/linux/xfs_super.h - 1.11 - add prototypes for routines which initialize a buftarg structure, and release one. needed for the external log/realtime volume device ref counting fixups. linux/fs/xfs/linux/xfs_super.c - 1.133 - fix up STATIC functions. fix up inline ifdefs, somewhat. reworked the argument parsing routine such that we can correctly handle external log devices and realtime devices, and make mount error messages consistent with other error messages we produce. reworked spectodevs routine to work with new external devices handling code also. make read_super routine a tad more readable. misc formatting changes to make this code match up with the way the rest of XFS is written. fix a VNODE reference count leak in the linvfs_unfreeze_fs routine (missing a VN_RELE). linux/fs/xfs/linux/xfs_ioctl.c - 1.48 - fix up STATIC functions, remove unneeded function prototypes that fell out of the wordwork from doing this. From owner-linux-xfs@oss.sgi.com Mon Aug 20 01:42:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K8gQ110552 for linux-xfs-outgoing; Mon, 20 Aug 2001 01:42:26 -0700 Received: from to.com (fw.to.com [194.221.251.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K8gNj10532 for ; Mon, 20 Aug 2001 01:42:23 -0700 Received: from elwood.think (unknown [192.168.10.15]) by to.com (Postfix) with ESMTP id 290BD17004F for ; Mon, 20 Aug 2001 10:42:22 +0200 (CEST) Date: Mon, 20 Aug 2001 10:42:22 +0200 (CEST) From: Klaus Jaehne X-X-Sender: To: Subject: Crash in 2.4.8 with patch 2001-08-13 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 Hi, We have a 4-way Xeon machine with 2G RAM running the latest XFS-patched Kernel - currently 2.4.8 with patch 2001-08-13 - on RedHat 7.1. We have kernel crashes every three or four days with messages like this: Unable to handle kernel paging request at virtual address 0400000d c012f632 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 04000000 ebx: c03819d0 ecx: c1b63fc4 edx: c03ef3a8 esi: c15caf48 edi: c1b63fe0 ebp: c15caf64 esp: f7be5f94 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 7, stackpage=f7be5000) Stack: 000000c0 00000000 f7be4331 0008e000 00000405 c1b63fe0 00000040 00000000 00000000 0001a3bb 00000000 c0130252 000000c0 00000000 f7be4000 c02a66b1 f7be4331 c01302de 000000c0 00000000 00010f00 c3237fb4 c0105000 c010576f Call Trace: [] [] [] [] Code: 80 78 0d 01 0f 85 f8 00 00 00 8d 6e 1c 8b 46 1c 8b 55 04 89 >>EIP; c012f632 <===== Trace; c0130252 Trace; c01302de Trace; c0105000 <_stext+0/0> Trace; c010576f Code; c012f632 00000000 <_EIP>: Code; c012f632 <===== 0: 80 78 0d 01 cmpb $0x1,0xd(%eax) <===== Code; c012f636 4: 0f 85 f8 00 00 00 jne 102 <_EIP+0x102> c012f734 Code; c012f63c a: 8d 6e 1c lea 0x1c(%esi),%ebp Code; c012f63f d: 8b 46 1c mov 0x1c(%esi),%eax Code; c012f642 10: 8b 55 04 mov 0x4(%ebp),%edx Code; c012f645 13: 89 00 mov %eax,(%eax) Might this be an XFS problem that will be fixed some day or could it be a hardware error? -- greetings, Klaus Jähne ________________________________________________________________________ Thinking Objects Software GmbH, Lilienthalstr. 2, 70825 Stuttgart, DE phone 49 711 88770 400, fax 449, klaus.jaehne@to.com, http://www.to.com/ ======================================================================== Linux without limits: http://linux.s390.org/ ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Mon Aug 20 02:34:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K9YBv11703 for linux-xfs-outgoing; Mon, 20 Aug 2001 02:34:11 -0700 Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K9Y6j11682; Mon, 20 Aug 2001 02:34:06 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA21570; Mon, 20 Aug 2001 11:33:58 +0200 Received: from d12ml014.de.ibm.com (d12ml014_cs0 [9.165.223.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7K9Xrs17402; Mon, 20 Aug 2001 11:33:58 +0200 Subject: Re: XFS for Linux/390 To: Christian Mueller Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Holger Smolinski" Date: Mon, 20 Aug 2001 10:37:41 +0200 X-MIMETrack: Serialize by Router on D12ML014/12/M/IBM(Release 5.0.6 |December 14, 2000) at 20/08/2001 11:28:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Folks, we tried to make XFS run eith Linux/390 and ran into various deadlock situations when running an SMP kernel. Currently we are analysing. With non-SMP kernel there was no deadlock, but I'm not sure if XFS ran properly. Gruesse / Regards Dr. Holger Smolinski -- Linux for eServer Development, IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, D-71032 Boeblingen Phone/FAX: +49 7031 16 (x902) - 4652/3456 From owner-linux-xfs@oss.sgi.com Mon Aug 20 02:45:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7K9jrp11987 for linux-xfs-outgoing; Mon, 20 Aug 2001 02:45:53 -0700 Received: from server.hotswap (atbode95.informatik.tu-muenchen.de [131.159.32.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K9jmj11968 for ; Mon, 20 Aug 2001 02:45:49 -0700 Received: from localhost (localhost [127.0.0.1]) by server.hotswap (swapfix) with ESMTP id 003C839654DF for ; Mon, 20 Aug 2001 11:45:42 +0200 (CEST) Received: from cs.tum.edu (kuschel.hotswap [172.16.16.190]) by server.hotswap (swapfix) with ESMTP id 0A3D239654D3 for ; Mon, 20 Aug 2001 11:45:42 +0200 (CEST) Message-ID: <3B80DC41.EB038BB6@cs.tum.edu> Date: Mon, 20 Aug 2001 11:45:37 +0200 From: Deti Fliegl Reply-To: fliegl@cs.tum.edu Organization: Munich University of Technology, CS, LRR X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-pre2-xfs i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: XFS-Oops Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Running a 2.4.7-pre3-xfs CVS kernel after 27 days uptime an oops happened: Unable to handle kernel NULL pointer dereference at virtual address 00000152 c01cfbf2 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: ffffffe8 ecx: c1239688 edx: c03592c0 esi: c5f2264c edi: c7a77800 ebp: 00000000 esp: c140bce4 ds: 0018 es: 0018 ss: 0018 Process mot (pid: 4237, stackpage=c140b000) Stack: 000e090b 00000000 c7a77800 00000008 c01e677c c7a77800 00000000 04f7e2a6 00000000 00000000 c140bdc8 00000000 00000000 00000000 c140bdd8 c140bdc0 c140be94 00000000 00000000 c01d078b 00000000 c2587b40 c4647040 c7a77800 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 37 >>EIP; c01cfbf2 <===== Trace; c01e677c Trace; c01d078b Trace; c01bafa0 Trace; c01dffba Trace; c01e0490 Trace; c01cf7c4 Trace; c01e0647 Trace; c01e0490 Trace; c01e0490 Trace; c014530b Trace; c01e678c Trace; c01d0096 Trace; c01d00b3 Trace; c01e51a2 Trace; c01d01ef Trace; c01e51a2 Trace; c01d01ef Trace; c01f5198 Trace; c01e0490 Trace; c013daae Trace; c013db39 Trace; c013dd3c Trace; c0106eb3 Code; c01cfbf2 00000000 <_EIP>: Code; c01cfbf2 <===== 0: 66 83 bb 6a 01 00 00 cmpw $0x0,0x16a(%ebx) <===== Code; c01cfbf9 7: 00 Code; c01cfbfa 8: 75 10 jne 1a <_EIP+0x1a> c01cfc0c Code; c01cfbfc a: 80 a3 50 01 00 00 f7 andb $0xf7,0x150(%ebx) Code; c01cfc03 11: 53 push %ebx Code; c01cfc04 12: e8 37 00 00 00 call 4e <_EIP+0x4e> c01cfc40 maybe this helps... From owner-linux-xfs@oss.sgi.com Mon Aug 20 07:38:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KEcN121360 for linux-xfs-outgoing; Mon, 20 Aug 2001 07:38:23 -0700 Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KEcKj21341 for ; Mon, 20 Aug 2001 07:38:21 -0700 Received: from lucas.loria (213.36.104.210) by mail.libertysurf.net (5.1.053) id 3B80AD690000CDD2; Mon, 20 Aug 2001 16:38:13 +0200 Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id E37BEA589; Mon, 20 Aug 2001 09:20:57 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id D7899A0F39; Mon, 20 Aug 2001 09:20:56 +0200 (CEST) To: David Lloyd Cc: Simon Matter , linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B80B63E.22BD088B@rebel.net.au> X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E In-Reply-To: <3B80B63E.22BD088B@rebel.net.au> From: Vincent Bernat Date: 20 Aug 2001 09:20:56 +0200 Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id f7KEcLj21342 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OoO En cette matinée ensoleillée du lundi 20 août 2001, vers 09:03, David Lloyd disait: >> What do you think about it? > It's not in because it's not in an approved Linus kernel. ReiserFS etc > etc are... JFS and ext3 are not in an approved Linus kernel too. I think they include JFS and ext3 because they have people to do it (maybe some of the developers) and they have no one for XFS. Or maybe it is just a matter of asking : users who want XFS in the Mandrake kernel may just ask for it. -- BOFH excuse #130: new management From owner-linux-xfs@oss.sgi.com Mon Aug 20 07:43:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KEhtC21584 for linux-xfs-outgoing; Mon, 20 Aug 2001 07:43:55 -0700 Received: from rebel.net.au (IDENT:root@ftp.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KEhqj21565 for ; Mon, 20 Aug 2001 07:43:53 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id AAA22485; Tue, 21 Aug 2001 00:13:39 +0930 Message-ID: <3B812373.7536CBBB@rebel.net.au> Date: Tue, 21 Aug 2001 00:19:23 +0930 From: David Lloyd 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: Vincent Bernat CC: Simon Matter , linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B80B63E.22BD088B@rebel.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Vincent! > > It's not in because it's not in an approved Linus kernel. ReiserFS etc > > etc are... > > JFS and ext3 are not in an approved Linus kernel too. > I think they include JFS and ext3 because they have people to do it > (maybe some of the developers) and they have no one for XFS. Or maybe > it is just a matter of asking : users who want XFS in the Mandrake > kernel may just ask for it. I should have been clearer. If it's not in an approved Linux Kernel then the distributors don't have to include it by default in their own. Naturally, of course, they can if they wish so it is likely a matter of asking, taking the time to test with them and matters of such course. DSL From owner-linux-xfs@oss.sgi.com Mon Aug 20 08:42:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KFgZa23118 for linux-xfs-outgoing; Mon, 20 Aug 2001 08:42:35 -0700 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 f7KFg9j23090 for ; Mon, 20 Aug 2001 08:42:09 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GIDIA900.B6M for ; Mon, 20 Aug 2001 10:42:09 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001082010420700805 for ; Mon, 20 Aug 2001 10:42:07 -0500 Message-ID: <3B8130DC.B0DCAC6C@fnal.gov> Date: Mon, 20 Aug 2001 10:46:36 -0500 From: yocum@fnal.gov 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: xfs_create looping, missing dirs/files, corrupt inode tables, etc. Content-Type: multipart/mixed; boundary="------------BAC86A1E657052343D8CFAAC" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------BAC86A1E657052343D8CFAAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I've been having a problem that I thought might be related to Tridge's, but maybe not: When copying directories over NFS (v2) from OSF1 clients to a Linux server with XFS, files and directories will mysteriously "vanish" after the cp completes, however, enough of the file/dir remains (i.e., the name of the file in the inode table) that an ls of the dir will yield this: [root@sdssdp9 rawdata]# ls CANNOT_RM.51940/ ls: CANNOT_RM.51940/guider: No such file or directory As the name of the directory suggests, not enough information remains in the inode table to rm it, either. One clue that's in /var/log/messages is this: Aug 18 00:14:10 sdssdp9 kernel: xfs_create looping, dir ino 0xa25e000, ino 0x101000800, md(9,0) Aug 18 00:14:10 sdssdp9 kernel: Aug 18 00:14:10 sdssdp9 kernel: nfsd: non-standard errno: -990 I have also been able to reproduce this problem copying files over local NFSv2 (i.e., the NFS exported volume is mounted locally) so, this is not only an OSF1 -> Linux problem. At the threat of being beaten with a sharp pointy stick by mkp (since I know he *loves* IDE disks ;-), here's the hw and sw configuration of these machines: Intel STL2 mobo 2 866MHz P-III 512MB RAM Netgear GA620 Gig-e NIC 2 3ware 7810 8 port RAID controller cards (configured as RAID5) 1 3ware 6200 2 port RAID controller card (configured as RAID1 for system disk) 16 Maxtor 81.9GB disks (for data) SGI modified Red Hat 7.1 distribution linux-2.4.8-xfs from CVS (Thursday, Aug 16) I've configured each 3ware 7810 card as RAID5, then I'm using sw RAID0 to stripe across the devices yielding a 1.12TB filesystem. I'd try the same tests to a system that is not using IDE disks, but we don't have any of those. (Sorry, Martin) I've performed an xfs_repair on the device and everything was fixed up, files were saved off into lost+found, inodes cleared, etc. and I've attached the output if anyone is interested. Thanks, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. --------------BAC86A1E657052343D8CFAAC Content-Type: text/plain; charset=us-ascii; name="xfs_repair-sdssdp9.out" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_repair-sdssdp9.out" # xfs_repair /dev/md0 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 imap claims a free inode 16779264 is in use, correcting imap and clearing inode - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 imap claims a free inode 134219776 is in use, correcting imap and clearing inodecleared inode 134219776 - agno = 9 imap claims a free inode 150996992 is in use, correcting imap and clearing inodecleared inode 150996992 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - agno = 64 - agno = 65 - agno = 66 - agno = 67 - agno = 68 - agno = 69 - agno = 70 - agno = 71 - agno = 72 - agno = 73 - agno = 74 - agno = 75 - agno = 76 - agno = 77 - agno = 78 - agno = 79 - agno = 80 - agno = 81 - agno = 82 - agno = 83 - agno = 84 - agno = 85 - agno = 86 - agno = 87 - agno = 88 - agno = 89 - agno = 90 - agno = 91 - agno = 92 - agno = 93 - agno = 94 - agno = 95 - agno = 96 - agno = 97 - agno = 98 - agno = 99 - agno = 100 - agno = 101 - agno = 102 - agno = 103 - agno = 104 - agno = 105 - agno = 106 - agno = 107 - agno = 108 - agno = 109 - agno = 110 - agno = 111 - agno = 112 - agno = 113 - agno = 114 - agno = 115 - agno = 116 - agno = 117 - agno = 118 - agno = 119 - agno = 120 - agno = 121 - agno = 122 - agno = 123 - agno = 124 - agno = 125 - agno = 126 - agno = 127 - agno = 128 - agno = 129 - agno = 130 - agno = 131 - agno = 132 - agno = 133 - agno = 134 - agno = 135 - agno = 136 - agno = 137 - agno = 138 - agno = 139 - agno = 140 - agno = 141 - agno = 142 - agno = 143 - agno = 144 - agno = 145 - agno = 146 - agno = 147 - agno = 148 - agno = 149 - agno = 150 - agno = 151 - agno = 152 - agno = 153 - agno = 154 - agno = 155 - agno = 156 - agno = 157 - agno = 158 - agno = 159 - agno = 160 - agno = 161 - agno = 162 - agno = 163 - agno = 164 - agno = 165 - agno = 166 - agno = 167 - agno = 168 - agno = 169 - agno = 170 - agno = 171 - agno = 172 - agno = 173 - agno = 174 - agno = 175 - agno = 176 - agno = 177 - agno = 178 - agno = 179 - agno = 180 - agno = 181 - agno = 182 - agno = 183 - agno = 184 - agno = 185 - agno = 186 - agno = 187 - agno = 188 - agno = 189 - agno = 190 - agno = 191 - agno = 192 - agno = 193 - agno = 194 - agno = 195 - agno = 196 - agno = 197 - agno = 198 - agno = 199 - agno = 200 - agno = 201 - agno = 202 - agno = 203 - agno = 204 - agno = 205 - agno = 206 - agno = 207 - agno = 208 - agno = 209 - agno = 210 - agno = 211 - agno = 212 - agno = 213 - agno = 214 - agno = 215 - agno = 216 - agno = 217 - agno = 218 - agno = 219 - agno = 220 - agno = 221 - agno = 222 - agno = 223 - agno = 224 - agno = 225 - agno = 226 - agno = 227 - agno = 228 - agno = 229 - agno = 230 - agno = 231 - agno = 232 - agno = 233 - agno = 234 - agno = 235 - agno = 236 - agno = 237 - agno = 238 - agno = 239 - agno = 240 - agno = 241 - agno = 242 - agno = 243 - agno = 244 - agno = 245 - agno = 246 - agno = 247 - agno = 248 - agno = 249 - agno = 250 - agno = 251 - agno = 252 - agno = 253 - agno = 254 - agno = 255 - agno = 256 - agno = 257 - agno = 258 - agno = 259 - agno = 260 - agno = 261 - agno = 262 - agno = 263 corrected i8 count in directory 4412409875, was 3, now 2 - agno = 264 - agno = 265 - agno = 266 - agno = 267 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 entry "sdR-b2-00008656.fit.gz" in shortform directory 150996993 references free inode 150997027 junking entry "sdR-b2-00008656.fit.gz" in directory inode 150996993 entry "sdR-b1-00008656.fit.gz" in shortform directory 150996993 references free inode 150997028 junking entry "sdR-b1-00008656.fit.gz" in directory inode 150996993 - agno = 10 entry "52138" at block 0 offset 3920 in directory inode 170254336 references free inode 4311746560 clearing inode number in entry at offset 3920... - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - agno = 64 - agno = 65 - agno = 66 entry "guider" at block 0 offset 3968 in directory inode 1107298304 references free inode 4445964288 clearing inode number in entry at offset 3968... - agno = 67 - agno = 68 - agno = 69 - agno = 70 - agno = 71 - agno = 72 - agno = 73 - agno = 74 - agno = 75 - agno = 76 - agno = 77 - agno = 78 - agno = 79 - agno = 80 - agno = 81 - agno = 82 - agno = 83 - agno = 84 - agno = 85 - agno = 86 - agno = 87 - agno = 88 - agno = 89 - agno = 90 - agno = 91 - agno = 92 - agno = 93 - agno = 94 - agno = 95 - agno = 96 - agno = 97 - agno = 98 - agno = 99 - agno = 100 - agno = 101 - agno = 102 - agno = 103 - agno = 104 - agno = 105 - agno = 106 - agno = 107 - agno = 108 - agno = 109 - agno = 110 - agno = 111 - agno = 112 - agno = 113 - agno = 114 - agno = 115 - agno = 116 - agno = 117 - agno = 118 - agno = 119 - agno = 120 - agno = 121 - agno = 122 - agno = 123 - agno = 124 - agno = 125 - agno = 126 - agno = 127 - agno = 128 - agno = 129 - agno = 130 - agno = 131 - agno = 132 - agno = 133 - agno = 134 - agno = 135 - agno = 136 - agno = 137 - agno = 138 - agno = 139 - agno = 140 - agno = 141 - agno = 142 - agno = 143 - agno = 144 - agno = 145 - agno = 146 - agno = 147 - agno = 148 - agno = 149 - agno = 150 - agno = 151 - agno = 152 - agno = 153 - agno = 154 - agno = 155 - agno = 156 - agno = 157 - agno = 158 - agno = 159 - agno = 160 - agno = 161 - agno = 162 - agno = 163 - agno = 164 - agno = 165 - agno = 166 - agno = 167 - agno = 168 - agno = 169 - agno = 170 - agno = 171 - agno = 172 - agno = 173 - agno = 174 - agno = 175 - agno = 176 - agno = 177 - agno = 178 - agno = 179 - agno = 180 - agno = 181 - agno = 182 - agno = 183 - agno = 184 - agno = 185 - agno = 186 - agno = 187 - agno = 188 - agno = 189 - agno = 190 - agno = 191 - agno = 192 - agno = 193 - agno = 194 - agno = 195 - agno = 196 - agno = 197 - agno = 198 - agno = 199 - agno = 200 - agno = 201 - agno = 202 - agno = 203 - agno = 204 - agno = 205 - agno = 206 - agno = 207 - agno = 208 - agno = 209 - agno = 210 - agno = 211 - agno = 212 - agno = 213 - agno = 214 - agno = 215 - agno = 216 - agno = 217 - agno = 218 - agno = 219 - agno = 220 - agno = 221 - agno = 222 - agno = 223 - agno = 224 - agno = 225 - agno = 226 - agno = 227 - agno = 228 - agno = 229 - agno = 230 - agno = 231 - agno = 232 - agno = 233 - agno = 234 - agno = 235 - agno = 236 - agno = 237 - agno = 238 - agno = 239 - agno = 240 - agno = 241 - agno = 242 - agno = 243 - agno = 244 - agno = 245 - agno = 246 - agno = 247 - agno = 248 - agno = 249 - agno = 250 - agno = 251 - agno = 252 - agno = 253 - agno = 254 - agno = 255 - agno = 256 - agno = 257 - agno = 258 entry ".." at block 0 offset 32 in directory inode 4328523776 references free inode 4311746560 clearing inode number in entry at offset 32... no .. entry for directory 4328523776 - agno = 259 - agno = 260 - agno = 261 - agno = 262 - agno = 263 entry "guider" in shortform directory 4412409856 references free inode 4429187072 junking entry "guider" in directory inode 4412409856 corrected i8 count in directory 4412409856, was 1, now 0 corrected directory 4412409856 size, was 10, now 6 - agno = 264 - agno = 265 - agno = 266 entry ".." at block 0 offset 32 in directory inode 4462741504 references free inode 4445964288 clearing inode number in entry at offset 32... no .. entry for directory 4462741504 - agno = 267 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 170254336 rebuilding directory inode 1107298304 fixing i8count in inode 4479518720 fixing i8count in inode 4412409875 - traversal finished ... - traversing all unattached subtrees ... rebuilding directory inode 4328523776 rebuilding directory inode 4462741504 - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 4311746561, moving to lost+found disconnected inode 4311746562, moving to lost+found disconnected inode 4311746563, moving to lost+found disconnected inode 4311746564, moving to lost+found disconnected inode 4311746565, moving to lost+found disconnected inode 4311746566, moving to lost+found disconnected inode 4311746567, moving to lost+found disconnected inode 4311746568, moving to lost+found disconnected inode 4311746569, moving to lost+found disconnected inode 4311746570, moving to lost+found disconnected inode 4311746571, moving to lost+found disconnected inode 4311746572, moving to lost+found disconnected inode 4311746573, moving to lost+found disconnected inode 4311746574, moving to lost+found disconnected inode 4311746575, moving to lost+found disconnected inode 4311746576, moving to lost+found disconnected inode 4311746577, moving to lost+found disconnected inode 4311746578, moving to lost+found disconnected inode 4311746579, moving to lost+found disconnected inode 4311746580, moving to lost+found disconnected inode 4311746581, moving to lost+found disconnected inode 4311746582, moving to lost+found disconnected inode 4311746583, moving to lost+found disconnected inode 4311746584, moving to lost+found disconnected inode 4311746585, moving to lost+found disconnected inode 4311746586, moving to lost+found disconnected inode 4311746587, moving to lost+found disconnected inode 4311746588, moving to lost+found disconnected inode 4311746589, moving to lost+found disconnected inode 4311746590, moving to lost+found disconnected inode 4311746591, moving to lost+found disconnected inode 4311746592, moving to lost+found disconnected inode 4311746593, moving to lost+found disconnected inode 4311746594, moving to lost+found disconnected inode 4311746595, moving to lost+found disconnected inode 4311746596, moving to lost+found disconnected inode 4311746597, moving to lost+found disconnected inode 4311746598, moving to lost+found disconnected inode 4311746599, moving to lost+found disconnected inode 4311746600, moving to lost+found disconnected inode 4311746601, moving to lost+found disconnected inode 4311746602, moving to lost+found disconnected inode 4311746603, moving to lost+found disconnected inode 4311746604, moving to lost+found disconnected inode 4311746605, moving to lost+found disconnected inode 4311746606, moving to lost+found disconnected inode 4311746607, moving to lost+found disconnected inode 4311746608, moving to lost+found disconnected inode 4311746609, moving to lost+found disconnected inode 4311746610, moving to lost+found disconnected inode 4311746611, moving to lost+found disconnected inode 4311746612, moving to lost+found disconnected inode 4311746613, moving to lost+found disconnected inode 4311746614, moving to lost+found disconnected inode 4311746615, moving to lost+found disconnected inode 4311746616, moving to lost+found disconnected inode 4311746617, moving to lost+found disconnected inode 4311746618, moving to lost+found disconnected inode 4311746619, moving to lost+found disconnected inode 4311746620, moving to lost+found disconnected inode 4311746621, moving to lost+found disconnected inode 4311746622, moving to lost+found disconnected inode 4311746623, moving to lost+found disconnected inode 4312920064, moving to lost+found disconnected inode 4312920065, moving to lost+found disconnected inode 4312920066, moving to lost+found disconnected inode 4312920067, moving to lost+found disconnected inode 4312920068, moving to lost+found disconnected inode 4312920069, moving to lost+found disconnected inode 4312920070, moving to lost+found disconnected inode 4312920071, moving to lost+found disconnected inode 4312920072, moving to lost+found disconnected inode 4312920073, moving to lost+found disconnected inode 4312920074, moving to lost+found disconnected inode 4312920075, moving to lost+found disconnected inode 4312920076, moving to lost+found disconnected inode 4312920077, moving to lost+found disconnected inode 4312920078, moving to lost+found disconnected inode 4312920079, moving to lost+found disconnected inode 4312920080, moving to lost+found disconnected inode 4312920081, moving to lost+found disconnected inode 4312920082, moving to lost+found disconnected inode 4312920083, moving to lost+found disconnected inode 4312920084, moving to lost+found disconnected inode 4312920085, moving to lost+found disconnected inode 4312920086, moving to lost+found disconnected inode 4312920087, moving to lost+found disconnected inode 4312920088, moving to lost+found disconnected inode 4312920089, moving to lost+found disconnected inode 4312920090, moving to lost+found disconnected inode 4312920091, moving to lost+found disconnected inode 4312920092, moving to lost+found disconnected inode 4312920093, moving to lost+found disconnected inode 4312920094, moving to lost+found disconnected inode 4312920095, moving to lost+found disconnected inode 4312920096, moving to lost+found disconnected inode 4312920097, moving to lost+found disconnected inode 4312920098, moving to lost+found disconnected inode 4312920099, moving to lost+found disconnected inode 4312920100, moving to lost+found disconnected inode 4312920101, moving to lost+found disconnected inode 4312920102, moving to lost+found disconnected inode 4312920103, moving to lost+found disconnected inode 4312920104, moving to lost+found disconnected inode 4312920105, moving to lost+found disconnected inode 4312920106, moving to lost+found disconnected inode 4312920107, moving to lost+found disconnected inode 4312920108, moving to lost+found disconnected inode 4312920109, moving to lost+found disconnected inode 4312920110, moving to lost+found disconnected inode 4312920111, moving to lost+found disconnected inode 4312920112, moving to lost+found disconnected inode 4312920113, moving to lost+found disconnected inode 4312920114, moving to lost+found disconnected inode 4312920115, moving to lost+found disconnected inode 4312920116, moving to lost+found disconnected inode 4312920117, moving to lost+found disconnected inode 4312920118, moving to lost+found disconnected inode 4312920119, moving to lost+found disconnected inode 4312920120, moving to lost+found disconnected inode 4312920121, moving to lost+found disconnected inode 4312920122, moving to lost+found disconnected inode 4312920123, moving to lost+found disconnected inode 4312920124, moving to lost+found disconnected inode 4312920125, moving to lost+found disconnected inode 4312920126, moving to lost+found disconnected inode 4312920127, moving to lost+found disconnected inode 4314288128, moving to lost+found disconnected inode 4314288129, moving to lost+found disconnected inode 4314288130, moving to lost+found disconnected inode 4314288131, moving to lost+found disconnected inode 4314288132, moving to lost+found disconnected inode 4314288133, moving to lost+found disconnected inode 4314288134, moving to lost+found disconnected inode 4314288135, moving to lost+found disconnected inode 4314288136, moving to lost+found disconnected inode 4314288137, moving to lost+found disconnected inode 4314288138, moving to lost+found disconnected inode 4314288139, moving to lost+found disconnected inode 4314288140, moving to lost+found disconnected inode 4314288141, moving to lost+found disconnected inode 4314288142, moving to lost+found disconnected inode 4314288143, moving to lost+found disconnected inode 4314288144, moving to lost+found disconnected inode 4314288145, moving to lost+found disconnected inode 4314288146, moving to lost+found disconnected inode 4314288147, moving to lost+found disconnected inode 4314288148, moving to lost+found disconnected inode 4314288149, moving to lost+found disconnected inode 4314288150, moving to lost+found disconnected inode 4314288151, moving to lost+found disconnected inode 4314288152, moving to lost+found disconnected inode 4314288153, moving to lost+found disconnected inode 4314288154, moving to lost+found disconnected inode 4314288155, moving to lost+found disconnected inode 4314288156, moving to lost+found disconnected inode 4314288157, moving to lost+found disconnected inode 4314288158, moving to lost+found disconnected inode 4314288159, moving to lost+found disconnected inode 4314288160, moving to lost+found disconnected inode 4314288161, moving to lost+found disconnected inode 4314288162, moving to lost+found disconnected dir inode 4328523776, moving to lost+found disconnected inode 4429187073, moving to lost+found disconnected inode 4429187074, moving to lost+found disconnected inode 4445964289, moving to lost+found disconnected inode 4445964290, moving to lost+found disconnected inode 4445964291, moving to lost+found disconnected inode 4445964292, moving to lost+found disconnected inode 4445964293, moving to lost+found disconnected inode 4445964294, moving to lost+found disconnected inode 4445964295, moving to lost+found disconnected inode 4445964296, moving to lost+found disconnected inode 4445964297, moving to lost+found disconnected inode 4445964298, moving to lost+found disconnected inode 4445964299, moving to lost+found disconnected inode 4445964300, moving to lost+found disconnected inode 4445964301, moving to lost+found disconnected inode 4445964302, moving to lost+found disconnected inode 4445964303, moving to lost+found disconnected inode 4445964304, moving to lost+found disconnected inode 4445964305, moving to lost+found disconnected inode 4445964306, moving to lost+found disconnected inode 4445964307, moving to lost+found disconnected inode 4445964308, moving to lost+found disconnected inode 4445964309, moving to lost+found disconnected inode 4445964310, moving to lost+found disconnected inode 4445964311, moving to lost+found disconnected inode 4445964312, moving to lost+found disconnected inode 4445964313, moving to lost+found disconnected inode 4445964314, moving to lost+found disconnected inode 4445964315, moving to lost+found disconnected inode 4445964316, moving to lost+found disconnected inode 4445964317, moving to lost+found disconnected inode 4445964318, moving to lost+found disconnected inode 4445964319, moving to lost+found disconnected inode 4445964320, moving to lost+found disconnected inode 4445964321, moving to lost+found disconnected inode 4445964322, moving to lost+found disconnected inode 4445964323, moving to lost+found disconnected inode 4445964324, moving to lost+found disconnected dir inode 4462741504, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 170254336 nlinks from 246 to 245 resetting inode 1107298304 nlinks from 3 to 2 resetting inode 4328523776 nlinks from 3 to 2 resetting inode 4412409856 nlinks from 3 to 2 resetting inode 4462741504 nlinks from 3 to 2 done --------------BAC86A1E657052343D8CFAAC-- From owner-linux-xfs@oss.sgi.com Mon Aug 20 09:03:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KG3GN23928 for linux-xfs-outgoing; Mon, 20 Aug 2001 09:03:16 -0700 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 f7KG3Dj23906 for ; Mon, 20 Aug 2001 09:03:13 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7KG8G805173 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 20 Aug 2001 09:08:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA202325 for ; Mon, 20 Aug 2001 18:03:05 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2743107; Mon, 20 Aug 2001 11:01:48 -0500 (CDT) Received: from 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 LAA39175; Mon, 20 Aug 2001 11:01:30 -0500 (CDT) Message-ID: <3B813433.99FCCF2B@sgi.com> Date: Mon, 20 Aug 2001 11:00:51 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: yocum@fnal.gov CC: xfs-list Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: <3B8130DC.B0DCAC6C@fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi all, > > I've been having a problem that I thought might be related to Tridge's, but > maybe not: > > When copying directories over NFS (v2) from OSF1 clients to a Linux server > with XFS, files and directories will mysteriously "vanish" after the cp > completes, however, enough of the file/dir remains (i.e., the name of the > file in the inode table) that an ls of the dir will yield this: > > > [root@sdssdp9 rawdata]# ls CANNOT_RM.51940/ > ls: CANNOT_RM.51940/guider: No such file or directory Are you doing anything special to hit this? I move files around NFS all the time, I have not seen this. Anything else you can tell us to try to recreate it? Does this only happen on RAID? > Aug 18 00:14:10 sdssdp9 kernel: xfs_create looping, dir ino 0xa25e000, ino > 0x101000800, md(9,0) > Aug 18 00:14:10 sdssdp9 kernel: > Aug 18 00:14:10 sdssdp9 kernel: nfsd: non-standard errno: -990 The -990 is EFSCORRUPTED, generated directly after the "xfs_create looping" message, which comes out of a trap commented like this: /* * xfs_create_broken is a trap routine to isolate the cause of a infinite * loop condition reported in IRIX 6.4 by PV 522864. If no occurances * of this error recur (that is, the trap code isn't hit), this routine * should be removed in future releases. */ so I guess we won't remove it just yet... ;-) -Eric From owner-linux-xfs@oss.sgi.com Mon Aug 20 09:06:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KG6Wh24182 for linux-xfs-outgoing; Mon, 20 Aug 2001 09:06:32 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KG6Tj24162 for ; Mon, 20 Aug 2001 09:06:29 -0700 Received: from thebarn.com ([63.231.179.33]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7KG6RXi088276; Mon, 20 Aug 2001 11:06:27 -0500 (CDT) Message-ID: <3B813450.9090805@thebarn.com> Date: Mon, 20 Aug 2001 11:01:20 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: yocum@fnal.gov CC: xfs-list Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: <3B8130DC.B0DCAC6C@fnal.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk yocum@fnal.gov wrote: >Hi all, > >I've been having a problem that I thought might be related to Tridge's, but >maybe not: > >When copying directories over NFS (v2) from OSF1 clients to a Linux server >with XFS, files and directories will mysteriously "vanish" after the cp >completes, however, enough of the file/dir remains (i.e., the name of the >file in the inode table) that an ls of the dir will yield this: > > >[root@sdssdp9 rawdata]# ls CANNOT_RM.51940/ >ls: CANNOT_RM.51940/guider: No such file or directory > > >As the name of the directory suggests, not enough information remains in the >inode table to rm it, either. > >One clue that's in /var/log/messages is this: > > >Aug 18 00:14:10 sdssdp9 kernel: xfs_create looping, dir ino 0xa25e000, ino >0x101000800, md(9,0) >Aug 18 00:14:10 sdssdp9 kernel: >Aug 18 00:14:10 sdssdp9 kernel: nfsd: non-standard errno: -990 > Are you seeing any other error messages on the linux server? Error 990 is file system shutdown which is usally the result of a hardware error. > > > >I have also been able to reproduce this problem copying files over local >NFSv2 (i.e., the NFS exported volume is mounted locally) so, this is not >only an OSF1 -> Linux problem. > >At the threat of being beaten with a sharp pointy stick by mkp (since I know >he *loves* IDE disks ;-), here's the hw and sw configuration of these >machines: > >Intel STL2 mobo >2 866MHz P-III >512MB RAM >Netgear GA620 Gig-e NIC >2 3ware 7810 8 port RAID controller cards (configured as RAID5) >1 3ware 6200 2 port RAID controller card (configured as RAID1 for system >disk) >16 Maxtor 81.9GB disks (for data) > I remeber somebody mentioning the 3ware raid controllers are know to have problems... I think it was Martin Peterson. > > >SGI modified Red Hat 7.1 distribution >linux-2.4.8-xfs from CVS (Thursday, Aug 16) > >I've configured each 3ware 7810 card as RAID5, then I'm using sw RAID0 to >stripe across the devices yielding a 1.12TB filesystem. > >I'd try the same tests to a system that is not using IDE disks, but we don't >have any of those. (Sorry, Martin) > >I've performed an xfs_repair on the device and everything was fixed up, >files were saved off into lost+found, inodes cleared, etc. and I've attached >the output if anyone is interested. > >Thanks, >Dan > > From owner-linux-xfs@oss.sgi.com Mon Aug 20 09:52:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KGqWA25338 for linux-xfs-outgoing; Mon, 20 Aug 2001 09:52:32 -0700 Received: from mail.unixcircle.com (adsl-63-193-121-28.dsl.snfc21.pacbell.net [63.193.121.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KGqTj25319 for ; Mon, 20 Aug 2001 09:52:29 -0700 Received: from mail.unixcircle.com (mail.unixcircle.com [10.0.0.2]) by mail.unixcircle.com (8.12.0.Beta16/unixcircle) with ESMTP id f7KGqKvd011900 for ; Mon, 20 Aug 2001 09:52:21 -0700 (PDT) Date: Mon, 20 Aug 2001 09:52:20 -0700 (PDT) From: thang To: Subject: kernel BUG at page_alloc.c:81! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Greetings, kernel BUG at page_alloc.c:81! invalid operand: 0000 CPU: 0 EIP: 0010:[] EFLAGS: 00010282 eax: 0000001f ebx: 00000000 ecx: 00000000 edx: 00000002 esi: c1b97ee8 edi: 00000000 ebp: 00000000 esp: e8629d54 ds: 0018 es: 0018 ss: 0018 Process popper (pid: 1155, stackpage=e8629000) Stack: c02c4914 c02c4a08 00000051 c01387c3 c1b97ee8 00000000 c1b97ee8 c1b97ee8 c1b97ee8 c1b97f10 00000000 c5f4f5c0 c0126d3d 00000000 c1b97ee8 e8629db8 00000000 c01915f0 ea0f96a0 ea0f96a0 e8629db8 00000000 00000000 d2062184 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 8b 46 18 83 e0 20 74 16 6a 53 68 08 4a 2c c0 Got the above today. Machine was forced to reboot after weeks online hw info: kernel 2.4.8 SMP P3 733 x 2 1G RAM SCSI based From owner-linux-xfs@oss.sgi.com Mon Aug 20 10:08:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KH83V25789 for linux-xfs-outgoing; Mon, 20 Aug 2001 10:08:03 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KH80j25769 for ; Mon, 20 Aug 2001 10:08:01 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id TAA19722; Mon, 20 Aug 2001 19:07:55 +0200 (CEST) Message-Id: <4.3.2.7.2.20010820190651.03d91398@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Aug 2001 19:07:20 +0200 To: thang , From: Seth Mos Subject: Re: kernel BUG at page_alloc.c:81! 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 09:52 20-8-2001 -0700, thang wrote: >Greetings, Can you run this info through ksymoops for readability please? -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Aug 20 10:25:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KHPwe26106 for linux-xfs-outgoing; Mon, 20 Aug 2001 10:25:58 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KHPuj26087 for ; Mon, 20 Aug 2001 10:25:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA01300 for ; Mon, 20 Aug 2001 10:25:55 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2738142; Mon, 20 Aug 2001 12:24:39 -0500 (CDT) Received: from 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 MAA41968; Mon, 20 Aug 2001 12:24:38 -0500 (CDT) Message-ID: <3B8147AF.F61F7E00@sgi.com> Date: Mon, 20 Aug 2001 12:23:59 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: yocum@fnal.gov CC: xfs-list Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: <3B8130DC.B0DCAC6C@fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Oh, and as Steve says, "What compiler did you use?" -Eric From owner-linux-xfs@oss.sgi.com Mon Aug 20 10:48:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KHm6w26556 for linux-xfs-outgoing; Mon, 20 Aug 2001 10:48:06 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KHm3j26537 for ; Mon, 20 Aug 2001 10:48:03 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA05798 for ; Mon, 20 Aug 2001 10:47:46 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2726867; Mon, 20 Aug 2001 12:46:46 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA93628; Mon, 20 Aug 2001 12:46:46 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7KHlDI25967; Mon, 20 Aug 2001 12:47:14 -0500 Message-Id: <200108201747.f7KHlDI25967@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: thang cc: linux-xfs@oss.sgi.com Subject: Re: kernel BUG at page_alloc.c:81! In-Reply-To: Message from thang of "Mon, 20 Aug 2001 09:52:20 PDT." Date: Mon, 20 Aug 2001 12:47:13 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Greetings, > > > kernel BUG at page_alloc.c:81! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] > EFLAGS: 00010282 > eax: 0000001f ebx: 00000000 ecx: 00000000 edx: 00000002 > esi: c1b97ee8 edi: 00000000 ebp: 00000000 esp: e8629d54 > ds: 0018 es: 0018 ss: 0018 > Process popper (pid: 1155, stackpage=e8629000) > Stack: c02c4914 c02c4a08 00000051 c01387c3 c1b97ee8 00000000 c1b97ee8 > c1b97ee8 > c1b97ee8 c1b97f10 00000000 c5f4f5c0 c0126d3d 00000000 c1b97ee8 > e8629db8 > 00000000 c01915f0 ea0f96a0 ea0f96a0 e8629db8 00000000 00000000 > d2062184 > Call Trace: [] [] [] [] > [] [] [] > [] [] [] [] [] > [] [] > > Code: 0f 0b 83 c4 0c 8b 46 18 83 e0 20 74 16 6a 53 68 08 4a 2c c0 > > > Got the above today. Machine was forced to reboot after weeks online > hw info: > > kernel 2.4.8 SMP > P3 733 x 2 > 1G RAM > SCSI based As Seth said, this needs to be fed through ksymoops to be useful, but what it amounts to is freeing a locked page which should not happen. A decoded stack trace will help track it down. Steve From owner-linux-xfs@oss.sgi.com Mon Aug 20 11:57:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KIvZv28217 for linux-xfs-outgoing; Mon, 20 Aug 2001 11:57:35 -0700 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 f7KIvU928198 for ; Mon, 20 Aug 2001 11:57:30 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GIDRBT00.692 for ; Mon, 20 Aug 2001 13:57:29 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001082013572825319 ; Mon, 20 Aug 2001 13:57:28 -0500 Message-ID: <3B815EA6.E9A190C7@fnal.gov> Date: Mon, 20 Aug 2001 14:01:58 -0500 From: yocum@fnal.gov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: xfs-list Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: <3B8130DC.B0DCAC6C@fnal.gov> <3B813433.99FCCF2B@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: > > > Hi all, > > > > I've been having a problem that I thought might be related to Tridge's, but > > maybe not: > > > > When copying directories over NFS (v2) from OSF1 clients to a Linux server > > with XFS, files and directories will mysteriously "vanish" after the cp > > completes, however, enough of the file/dir remains (i.e., the name of the > > file in the inode table) that an ls of the dir will yield this: > > > > > > [root@sdssdp9 rawdata]# ls CANNOT_RM.51940/ > > ls: CANNOT_RM.51940/guider: No such file or directory > > Are you doing anything special to hit this? I move files around NFS all Nothing terribly special. But I did lie about the kernel/XFS version, accidentally: I upgraded to linux-2.4.8-xfs on Friday morning, the corruption was discovered Friday night, but the files were written back when the machine was running linux-2.4.7pre6-xfs. Which version of NFS are you using? v2? This might be the root of the problem. Some of our systems are forcing vers=2 for problems we had, oh, back around 2.0.36 with OSF1 not being able to autonegotiate correctly. I think that's all fixed now, so I'm having that mount option removed. I'll let you know if the problem goes away. > the time, I have not seen this. Anything else you can tell us to try to > recreate it? Does this only happen on RAID? I'd test on a non-RAID system if I had one (how often do you hear that? ;-). I suppose I could try it on my desktop. I'll let you know how that goes, too. We're moving *lots* of data around (a few hundred GB/week at least). I'm trying to get the data analysts to use rcp instead of NFS, but that'll take some time. > > > Aug 18 00:14:10 sdssdp9 kernel: xfs_create looping, dir ino 0xa25e000, ino > > 0x101000800, md(9,0) > > Aug 18 00:14:10 sdssdp9 kernel: > > Aug 18 00:14:10 sdssdp9 kernel: nfsd: non-standard errno: -990 > > The -990 is EFSCORRUPTED, generated directly after the "xfs_create > looping" message, which comes out of a trap commented like this: > > /* > * xfs_create_broken is a trap routine to isolate the cause of a > infinite > * loop condition reported in IRIX 6.4 by PV 522864. If no > occurances > * of this error recur (that is, the trap code isn't hit), this > routine > * should be removed in future releases. > */ > > so I guess we won't remove it just yet... ;-) Hm... no. Not quite yet. Cheers, Dan PS Tell Steve "Whatever gcc RH ships with 7.1 plus updates." I guess that's gcc-2.96-85. You want me to try 2.96.66, per the Makefile? -- 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 Aug 20 12:34:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KJYAx28993 for linux-xfs-outgoing; Mon, 20 Aug 2001 12:34:10 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KJY7928973 for ; Mon, 20 Aug 2001 12:34:07 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA16207; Mon, 20 Aug 2001 21:34:01 +0200 (CEST) Message-Id: <4.3.2.7.2.20010820212625.03d832d8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Aug 2001 21:32:04 +0200 To: yocum@fnal.gov, Eric Sandeen From: Seth Mos Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. Cc: xfs-list In-Reply-To: <3B815EA6.E9A190C7@fnal.gov> References: <3B8130DC.B0DCAC6C@fnal.gov> <3B813433.99FCCF2B@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:01 20-8-2001 -0500, yocum@fnal.gov wrote: >I'd test on a non-RAID system if I had one (how often do you hear that? >;-). I suppose I could try it on my desktop. I'll let you know how that >goes, too. We're moving *lots* of data around (a few hundred GB/week at >least). I'm trying to get the data analysts to use rcp instead of NFS, but >that'll take some time. Slightly OT. how about scp and then using publickey authentication. I just managed to set something like that up for the kt.zork.net mirror. You won't even need to enter passwords then although it is highly risky when you use this on laptops. 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 Aug 20 14:02:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KL22p30902 for linux-xfs-outgoing; Mon, 20 Aug 2001 14:02:02 -0700 Received: from ajpmail.ajpark.co.nz ([203.97.85.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KL1u930883 for ; Mon, 20 Aug 2001 14:01:56 -0700 Received: from mason.ajpark.int (not verified[192.168.1.202]) by ajpmail.ajpark.co.nz with MailMarshal (4,0,9,0) id ; Tue, 21 Aug 2001 08:57:50 +1200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: oops on reboot damaged filesystem Date: Tue, 21 Aug 2001 09:01:32 +1200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <09259B1E9A747045AEFC8FD791FDC2100ECDDF@mason.ajpark.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: oops on reboot damaged filesystem Thread-Index: AcEo9CrCn9Po9O8wQsK2JNUf8UNmkAAx0jdg From: "Godfrey Livingstone" To: "Seth Mos" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7KL1v930884 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ___________________________________________________________ This e-mail is intended for the addressee only and may contain privileged and/or confidential information ___________________________________________________________ Thanks using the installer worked all appears to be well. Yes the board is an Abit BP6 and I have the latest bios and I have patched the bios with the latest hpt366 rom. The hard drives are not on the hpt366 in any case. System is not overclocked. The computer was rock solid under 2.2.19 (patched) uptime of 4 months at one stage. How do you save an oops and kdb output, does issuing DEBUG=1 when in kdb save the output or is that unnecessary? Is the output from the kbd bt command needed? I have checked the FAQ and and searched Google and have not been able to find the answer to these questions sorry. Godfrey -----Original Message----- From: Seth Mos [mailto:knuffie@xs4all.nl] Sent: Monday, 20 August 2001 09:16 To: Godfrey Livingstone; linux-xfs@oss.sgi.com Subject: Re: oops on reboot damaged filesystem At 08:41 20-8-2001 +1200, Godfrey Livingstone wrote: >I have been trying to test out xfs for a while not but the system hard >locked up on a regular basis until 2.4.9 which seems reasonably stable. >I can get it to crash with a "make -j bzImage" but make -j 20 bzImage" >does not crash. > >As a side note can anyone issue "make -j bzImage" or "make -j modules" >and not crash their machine? I have not encounterd it and I can still play Quake3 as well. >smp dual celeron 433 with 512mb of ram Abit dual celeron motherboard? Do you have the latest bios? A lot of people have reported problems with that motherboard before. Even NT4 can have a hard time operating. (I have a friend with such a motherboard) >Anyway my problem is that when I shut down for a reboot I got an oops on >reboot. Tried the rescue disk and when the rescue disk looked for >installed partitions it found the damaged file system and crashed. > >How can I get the rescue disk to not look for partitions so that I can >effect a repair? AIEE!! Crap. Start the installer just like you would installing the OS. I think you could switch to the second console with ctrl+alt+F2 and then repair the FS but I am not quite sure if you can do it from within the installer. Another thing you could do is follow the link within the FAQ to the rescue boot disks section and download the XFS floppy boot disks. Maybe a last resort but that should always work. http://oss.sgi.com/projects/xfs/faq.html#xfsbootdisks >Godfrey Livingstone 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. _____________________________________________ A J Park Intellectual Property Lawyers and Consultants Patent and Trade Mark Attorneys New Zealand www.ajpark.com _____________________________________________ From owner-linux-xfs@oss.sgi.com Mon Aug 20 14:27:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KLRHP31568 for linux-xfs-outgoing; Mon, 20 Aug 2001 14:27:17 -0700 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 f7KLRF931549 for ; Mon, 20 Aug 2001 14:27:15 -0700 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 f7KLWJ800610 for ; Mon, 20 Aug 2001 14:32:19 -0700 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 QAA2751280; Mon, 20 Aug 2001 16:25:54 -0500 (CDT) Received: from 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 QAA23318; Mon, 20 Aug 2001 16:25:52 -0500 (CDT) Message-ID: <3B818039.C269C8A5@sgi.com> Date: Mon, 20 Aug 2001 16:25:13 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > What do you think about it? I think it's too bad, but I also think that with all those filesystems supported in the installer, it's probably not too much work for some semi-ambitious person to spin their own Mandrake installer with XFS support... (hint, hint!) -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 Aug 20 14:54:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KLsxB32148 for linux-xfs-outgoing; Mon, 20 Aug 2001 14:54:59 -0700 Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KLst932129 for ; Mon, 20 Aug 2001 14:54:56 -0700 Received: from club-internet.fr ([195.36.199.15]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA06711; Mon, 20 Aug 2001 23:54:48 +0200 (MET DST) Message-ID: <3B818A5D.F9F8EE0C@club-internet.fr> Date: Tue, 21 Aug 2001 00:08:29 +0200 From: jfm2@club-internet.fr X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.5-SGI_XFS_1.0.1_Indy i586) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Simon Matter , linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B818039.C269C8A5@sgi.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by front1.grolier.fr id XAA06711 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7KLsu932130 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen a écrit : > > Simon Matter wrote: > > > What do you think about it? > > I think it's too bad, but I also think that with all those filesystems > supported in the installer, it's probably not too much work for some > semi-ambitious person to spin their own Mandrake installer with XFS > support... (hint, hint!) > I have been thinking in it. The biggest problem is Grub since Grub cannot boot from an XFS partition and I really think Lilo is obsolete and should be dropped ASAP. Any news from the person who is trying to do an XFS back end for Grub? ---- Jean Francois Martinez The Independence project: because Linux should be for everyone http://independence.seul.org From owner-linux-xfs@oss.sgi.com Mon Aug 20 16:38:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KNcw502130 for linux-xfs-outgoing; Mon, 20 Aug 2001 16:38:58 -0700 Received: from rebel.net.au (IDENT:root@www.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KNct902111 for ; Mon, 20 Aug 2001 16:38:55 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id JAA00654; Tue, 21 Aug 2001 09:08:36 +0930 Message-ID: <3B81A0D5.EBA77465@rebel.net.au> Date: Tue, 21 Aug 2001 09:14:21 +0930 From: David Lloyd 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: jfm2@club-internet.fr CC: linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B818039.C269C8A5@sgi.com> <3B818A5D.F9F8EE0C@club-internet.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmmm... > The biggest problem is Grub since Grub cannot boot from an XFS partition > and I really think Lilo is obsolete and should be dropped ASAP. > Any news from the person who is trying to do an XFS back end for Grub? Last time I looked at Grub and the latest version(s) of Lilo, the only difference I could see was that Grub's configuration looked like NT Loader's. So, why is Grub superior? DSL From owner-linux-xfs@oss.sgi.com Mon Aug 20 21:32:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L4Wta07361 for linux-xfs-outgoing; Mon, 20 Aug 2001 21:32:55 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L4Wq907342 for ; Mon, 20 Aug 2001 21:32:52 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id VAA08259 for ; Mon, 20 Aug 2001 21:32:50 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA23955; Tue, 21 Aug 2001 14:31:27 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Godfrey Livingstone" cc: linux-xfs@oss.sgi.com Subject: Re: oops on reboot damaged filesystem In-reply-to: Your message of "Tue, 21 Aug 2001 09:01:32 +1200." <09259B1E9A747045AEFC8FD791FDC2100ECDDF@mason.ajpark.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Aug 2001 14:31:27 +1000 Message-ID: <28827.998368287@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 21 Aug 2001 09:01:32 +1200, "Godfrey Livingstone" wrote: >How do you save an oops and kdb output, does issuing DEBUG=1 when in kdb >save the output or is that unnecessary? "set LOGGING=1" in kdb to log the output to disk, via syslog. But that only works if the kernel can recover after the oops, if the machine dies then syslog never gets called. Your best option is to use a serial console, Documentation/serial-console.txt, and capture the serial output on the second machine. >Is the output from the kbd bt command needed? Depends on the type of error. For a deadlock, bt is useful. For a straight oops, it is rarely useful, unless the oops comes from code that is testing for deadlocks. From owner-linux-xfs@oss.sgi.com Mon Aug 20 22:10:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L5AUH08029 for linux-xfs-outgoing; Mon, 20 Aug 2001 22:10:30 -0700 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 f7L5AS908009 for ; Mon, 20 Aug 2001 22:10:28 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7L5FX821909 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 20 Aug 2001 22:15:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id HAA251213 for ; Tue, 21 Aug 2001 07:10:21 +0200 (CEST) mail_from (sandeen@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 AAA2753336 for ; Tue, 21 Aug 2001 00:09:04 -0500 (CDT) Received: from chuckle.americas.sgi.com (IDENT:root@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id AAA76638 for ; Tue, 21 Aug 2001 00:09:04 -0500 (CDT) Received: (from sandeen@localhost) by chuckle.americas.sgi.com (8.11.2/8.11.2) id f7L594V26723 for linux-xfs@oss.sgi.com; Tue, 21 Aug 2001 00:09:04 -0500 Date: Tue, 21 Aug 2001 00:09:04 -0500 From: Eric Sandeen Message-Id: <200108210509.f7L594V26723@chuckle.americas.sgi.com> Subject: TAKE - Merge irix6.5f:irix:101107a Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Aug 20 22:08:16 PDT 2001 Workarea: chuckle.americas.sgi.com:/export/xfs1/eric/linux-2.4-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101116a linux/fs/xfs/xfs_itable.c - 1.100 - Merge irix6.5f:irix:101107a Clear bp upon error so it's not reused. From owner-linux-xfs@oss.sgi.com Mon Aug 20 22:53:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L5rHE09427 for linux-xfs-outgoing; Mon, 20 Aug 2001 22:53:17 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L5rE909408 for ; Mon, 20 Aug 2001 22:53:14 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id HAA00059; Tue, 21 Aug 2001 07:53:08 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id HAA09289; Tue, 21 Aug 2001 07:53:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 0CFAE57306; Tue, 21 Aug 2001 07:52:49 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id B4DEA25835; Tue, 21 Aug 2001 07:52:48 +0200 (CEST) Message-ID: <3B81F730.867E5916@ch.sauter-bc.com> Date: Tue, 21 Aug 2001 07:52:48 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: David Lloyd Cc: jfm2@club-internet.fr, linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B818039.C269C8A5@sgi.com> <3B818A5D.F9F8EE0C@club-internet.fr> <3B81A0D5.EBA77465@rebel.net.au> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk David Lloyd schrieb: > > Hmmm... > > > The biggest problem is Grub since Grub cannot boot from an XFS partition > > and I really think Lilo is obsolete and should be dropped ASAP. > > Any news from the person who is trying to do an XFS back end for Grub? I don't think this is a problem. Lilo was always there in the Mandrake distribution and can be used to boot XFS. If you really need grub just put /boot on ext2. BTW does grub boot JFS? > > Last time I looked at Grub and the latest version(s) of Lilo, the only > difference I could see was that Grub's configuration looked like NT > Loader's. So, why is Grub superior? I'm not an expert on this but one significant difference is that grub does understand filesystems. This is very nice since you can boot every kernel without having to call lilo after changing anything. It's work a bit like the loaders of the *BSD's. -Simon From owner-linux-xfs@oss.sgi.com Mon Aug 20 22:58:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L5wHC09591 for linux-xfs-outgoing; Mon, 20 Aug 2001 22:58:17 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L5wE909572 for ; Mon, 20 Aug 2001 22:58:14 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id HAA00412; Tue, 21 Aug 2001 07:58:10 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id HAA09578; Tue, 21 Aug 2001 07:58:09 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 274BC57306; Tue, 21 Aug 2001 07:57:48 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 6E08325835; Tue, 21 Aug 2001 07:57:47 +0200 (CEST) Message-ID: <3B81F85B.75B2DB1A@ch.sauter-bc.com> Date: Tue, 21 Aug 2001 07:57:47 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Seth Mos Cc: yocum@fnal.gov, Eric Sandeen , xfs-list Subject: Re: xfs_create looping, missing dirs/files, corrupt inodetables, etc. References: <3B8130DC.B0DCAC6C@fnal.gov> <3B813433.99FCCF2B@sgi.com> <4.3.2.7.2.20010820212625.03d832d8@pop.xs4all.nl> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos schrieb: > > At 14:01 20-8-2001 -0500, yocum@fnal.gov wrote: > >I'd test on a non-RAID system if I had one (how often do you hear that? > >;-). I suppose I could try it on my desktop. I'll let you know how that > >goes, too. We're moving *lots* of data around (a few hundred GB/week at > >least). I'm trying to get the data analysts to use rcp instead of NFS, but > >that'll take some time. > > Slightly OT. > > how about scp and then using publickey authentication. I just managed to > set something like that up for the kt.zork.net mirror. More OT again :) Using ssh/scp with public key authentication is very nice but there is one problem: If you need good performance, rsh/rcp is much better than the secure versions. So ssh/scp is good on public/insecure networks while rsh/rcp is good in secure ineternal networks. -Simon > > You won't even need to enter passwords then although it is highly risky > when you use this on laptops. > > 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 Aug 20 23:05:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L654009818 for linux-xfs-outgoing; Mon, 20 Aug 2001 23:05:04 -0700 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L651909799 for ; Mon, 20 Aug 2001 23:05:01 -0700 Received: from club-internet.fr ([195.36.199.7]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA26423; Tue, 21 Aug 2001 08:04:19 +0200 (MET DST) Message-ID: <3B81FD1D.13318258@club-internet.fr> Date: Tue, 21 Aug 2001 08:18:05 +0200 From: jfm2@club-internet.fr X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.5-SGI_XFS_1.0.1_Indy i586) X-Accept-Language: en MIME-Version: 1.0 To: David Lloyd CC: linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B818039.C269C8A5@sgi.com> <3B818A5D.F9F8EE0C@club-internet.fr> <3B81A0D5.EBA77465@rebel.net.au> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by front7m.grolier.fr id IAA26423 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7L652909800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk David Lloyd a écrit : > > Hmmm... > > > The biggest problem is Grub since Grub cannot boot from an XFS partition > > and I really think Lilo is obsolete and should be dropped ASAP. > > Any news from the person who is trying to do an XFS back end for Grub? > > Last time I looked at Grub and the latest version(s) of Lilo, the only > difference I could see was that Grub's configuration looked like NT > Loader's. So, why is Grub superior? > > DSL I don't know NT loader, but Grub understands filesystems. That means if you override your kernel or initrd you don'ty need to do anything special. You can hunt for a kernel who is not in the list. Grub alos allows to VIEW what will be your boot options, edit them with a reasonably user friendly interface, if it will fall back if it doesn't find a kernel or even the second part of GRUB. And Grub really supports international keyboards (LILO's support is a joke). After using Grub LILO feels like driving a Model T Ford. -- Jean Francois Martinez The Independence project: because Linux should be for everyone http://independence.seul.org From owner-linux-xfs@oss.sgi.com Mon Aug 20 23:45:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L6j8510577 for linux-xfs-outgoing; Mon, 20 Aug 2001 23:45:08 -0700 Received: from cmmaustralia.com (IDENT:qmailr@[203.34.190.215]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L6j4910558 for ; Mon, 20 Aug 2001 23:45:04 -0700 Received: (qmail 14367 invoked by uid 506); 21 Aug 2001 06:44:10 -0000 Received: from list@fornax.net by cmma.cmmaustralia.com with qmail-scanner-0.94 (. Clean. Processed in 0.023256 secs); 21/08/2001 16:14:10 Received: from adl-office.airnet.com.au (HELO fornax.net) (203.34.190.136) by cmma.airnet.com.au with SMTP; 21 Aug 2001 06:44:10 -0000 Message-ID: <3B82036D.1030706@fornax.net> Date: Tue, 21 Aug 2001 16:15:01 +0930 From: Andrew Hill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Disappearing files in the / directory Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've been running XFS on /home on my desktop machine (RedHat 7.1, with a 2.4.6 kernel) for a while now, and have been very impressed! I have just set up a similar system, but used the modified installer disk to set it up with XFS on all partitions. This seems to have worked very well. However, when I create files or directories directly under the / directory, when I reboot the server, they disappear! Does anyone know what is happening? Cheers, -- Andrew Hill "Being attractive was never part of my game plan." - 2001-03-28 From owner-linux-xfs@oss.sgi.com Mon Aug 20 23:45:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L6jUU10700 for linux-xfs-outgoing; Mon, 20 Aug 2001 23:45:30 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L6jR910669 for ; Mon, 20 Aug 2001 23:45:27 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id IAA23875; Tue, 21 Aug 2001 08:44:12 +0200 (CEST) Message-Id: <4.3.2.7.2.20010821084026.0348dfe8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Aug 2001 08:43:34 +0200 To: "Godfrey Livingstone" , From: Seth Mos Subject: RE: oops on reboot damaged filesystem In-Reply-To: <09259B1E9A747045AEFC8FD791FDC2100ECDDF@mason.ajpark.int> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:01 21-8-2001 +1200, Godfrey Livingstone wrote: >Thanks using the installer worked all appears to be well. Great, so that works as well. >Yes the board is an Abit BP6 and I have the latest bios and I have >patched the bios with the latest hpt366 rom. That should help. >The hard drives are not on the hpt366 in any case. System is not >overclocked. > >The computer was rock solid under 2.2.19 (patched) uptime of 4 months >at one stage. 2.4 pushes hardware a bit harder. I noticed bad ram faster on a 2.4 kernel. When I upgraded my home machine from 2.2 to 2.4 I noticed more crashes which were eradicated after replacing a dimm. What compiler did you use? And what distribution are you on. 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 Aug 20 23:47:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L6lpX10860 for linux-xfs-outgoing; Mon, 20 Aug 2001 23:47:51 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L6ln910841 for ; Mon, 20 Aug 2001 23:47:49 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA02499 for ; Mon, 20 Aug 2001 23:47:31 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24861; Tue, 21 Aug 2001 16:46:31 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA06871; Tue, 21 Aug 2001 16:46:30 +1000 (AEST) Date: Tue, 21 Aug 2001 16:46:30 +1000 From: Nathan Scott To: Andrew Tridgell Cc: linux-xfs@oss.sgi.com Subject: Re: minor logdev bugs Message-ID: <20010821164630.I309870@wobbly.melbourne.sgi.com> References: <20010814225736.EBCC34539@lists.samba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010814225736.EBCC34539@lists.samba.org>; from tridge@valinux.com on Tue, Aug 14, 2001 at 03:57:36PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Andrew, These external log issues are now fixed in the CVS code. thanks. On Tue, Aug 14, 2001 at 03:57:36PM -0700, Andrew Tridgell wrote: > XFS doesn't open the logdev during use, which has two unfortunate > consequences. > > The first is if you mount a XFS filesystem while the logdev device is > not loaded (say for example if the logdev is on a device implemented > in a kernel module). You get an oops from within linvfs_read_super() > when it calls into the pagebug to ask for pages on a device that > doesn't exist. > > The second is that the usage count of the logdev module remains at > zero while the logdev is being used, which means it can be > removed. Then you get an almost certain lockup when XFS next tries to > use the log. It also means that someone else can come along and use > the devive without any usage count tests kicking in. > > You can reproduce the effect by using a logdev on a ramdisk. > > Cheers, Tridge > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 20 23:57:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L6vpo11176 for linux-xfs-outgoing; Mon, 20 Aug 2001 23:57:51 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L6vm911157 for ; Mon, 20 Aug 2001 23:57:48 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id IAA28933; Tue, 21 Aug 2001 08:57:35 +0200 (CEST) Message-Id: <4.3.2.7.2.20010821085540.03e728d8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Aug 2001 08:56:59 +0200 To: Andrew Hill , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Disappearing files in the / directory In-Reply-To: <3B82036D.1030706@fornax.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:15 21-8-2001 +0930, Andrew Hill wrote: >Hi, > >I've been running XFS on /home on my desktop machine (RedHat 7.1, with a >2.4.6 kernel) for a while now, and have been very impressed! > >I have just set up a similar system, but used the modified installer disk >to set it up with XFS on all partitions. This seems to have worked very >well. However, when I create files or directories directly under the / >directory, when I reboot the server, they disappear! What kernel are you running on this machine? what hardware are you on? What compiler did you use (if you compiled your own. >Does anyone know what is happening? We will need some more details. 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 Aug 21 00:02:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L72tr11405 for linux-xfs-outgoing; Tue, 21 Aug 2001 00:02:55 -0700 Received: from cmmaustralia.com (IDENT:qmailr@[203.34.190.215]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L72q911385 for ; Tue, 21 Aug 2001 00:02:52 -0700 Received: (qmail 14583 invoked by uid 506); 21 Aug 2001 07:01:58 -0000 Received: from list@fornax.net by cmma.cmmaustralia.com with qmail-scanner-0.94 (. Clean. Processed in 0.023408 secs); 21/08/2001 16:31:58 Received: from adl-office.airnet.com.au (HELO fornax.net) (203.34.190.136) by cmma.airnet.com.au with SMTP; 21 Aug 2001 07:01:58 -0000 Message-ID: <3B820799.70808@fornax.net> Date: Tue, 21 Aug 2001 16:32:49 +0930 From: Andrew Hill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: Disappearing files in the / directory References: <4.3.2.7.2.20010821085540.03e728d8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > What kernel are you running on this machine? what hardware are you on? > What compiler did you use (if you compiled your own. Sorry - same kernel as my other machine - 2.4.6. Compiled my own using the RH 7.1 defaults (gcc-2.96-81). It's running on an Intel Coppermine Celeron 866, 128MB RAM, IBM Deskstar 46GB drive, VIA Chipset motherboard.... Cheers, -- Andrew Hill "Being attractive was never part of my game plan." - 2001-03-28 From owner-linux-xfs@oss.sgi.com Tue Aug 21 00:16:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7L7GaX11791 for linux-xfs-outgoing; Tue, 21 Aug 2001 00:16:36 -0700 Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L7GW911765 for ; Tue, 21 Aug 2001 00:16:32 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id JAA16933; Tue, 21 Aug 2001 09:16:20 +0200 (CEST) Message-Id: <4.3.2.7.2.20010821091214.03e70438@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Aug 2001 09:15:45 +0200 To: Andrew Hill From: Seth Mos Subject: Re: Disappearing files in the / directory Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B820799.70808@fornax.net> References: <4.3.2.7.2.20010821085540.03e728d8@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:32 21-8-2001 +0930, Andrew Hill wrote: >Seth Mos wrote: > >>What kernel are you running on this machine? what hardware are you on? >>What compiler did you use (if you compiled your own. > >Sorry - same kernel as my other machine - 2.4.6. Compiled my own using the >RH 7.1 defaults (gcc-2.96-81). Compile it with egcs 1.1.2 please. This one is also known as kgcc on redhat 7.x systems and can be found in the compat-egcs package. >It's running on an Intel Coppermine Celeron 866, 128MB RAM, IBM Deskstar >46GB drive, VIA Chipset motherboard.... Make sure you have the latest bios for your motherboard to make sure you don't encounter corruption with DMA enabled. You might also find it a good idea to build a newer kernel which will have more VIA fixes without doubt. 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 Aug 21 04:07:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LB7LR17167 for linux-xfs-outgoing; Tue, 21 Aug 2001 04:07:21 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LB7H917148 for ; Tue, 21 Aug 2001 04:07:17 -0700 Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) 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 EAA04937 for ; Tue, 21 Aug 2001 04:07:16 -0700 (PDT) mail_from (keith_m@sweeney.demon.co.uk) Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 15Z9IS-000Ol9-0U for linux-xfs@oss.sgi.com; Tue, 21 Aug 2001 12:02:13 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 7D06F27EF for ; Tue, 21 Aug 2001 08:17:05 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id EC245125E6; Tue, 21 Aug 2001 08:17:04 +0100 (BST) Date: Tue, 21 Aug 2001 08:17:04 +0100 (BST) From: Keith Matthews Subject: Re[2]: Mandrake Linux 8.1 beta without XFS To: linux-xfs In-Reply-To: <3B81F730.867E5916@ch.sauter-bc.com> References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B818039.C269C8A5@sgi.com> <3B818A5D.F9F8EE0C@club-internet.fr> <3B81A0D5.EBA77465@rebel.net.au>, <3B81F730.867E5916@ch.sauter-bc.com> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010821071704.EC245125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f7LB7H917149 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In response to the 3 people who asked about grub and XFS On Tue, 21 Aug 2001 07:52:48 +0200 Simon Matter > wrote: > I don't think this is a problem. Lilo was always there in the Mandrake > distribution and can be used to boot XFS. If you really need grub just > put /boot on ext2. BTW does grub boot JFS? Yes, a patch was published early July. I have not tried it myself However I have seen no report about problems or success with it on either the JFS list or the grub list. > > > > Last time I looked at Grub and the latest version(s) of Lilo, the only > > difference I could see was that Grub's configuration looked like NT > > Loader's. So, why is Grub superior? > I'm not an expert on this but one significant difference is that grub > does understand filesystems. This is very nice since you can boot every And this is where grub has problems, it has to understand the XFS directory structure and be able to walk it. I'm sure Steve and co will agree that it's not simple. progress has been made but I'm not able to put full-time effort on it and XFS requires grub to use technigues it has not done so before. I have not heard from Erich who was also trying. BTW, does anyone use a root partition and a separate boot one. -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Tue Aug 21 04:21:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LBLPQ17658 for linux-xfs-outgoing; Tue, 21 Aug 2001 04:21:25 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LBLK917639 for ; Tue, 21 Aug 2001 04:21:20 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id NAA16822; Tue, 21 Aug 2001 13:21:14 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id NAA05351; Tue, 21 Aug 2001 13:21:14 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id D277457306; Tue, 21 Aug 2001 13:20:28 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id D7B5A25835; Tue, 21 Aug 2001 13:20:24 +0200 (CEST) Message-ID: <3B8243F8.759C0C47@ch.sauter-bc.com> Date: Tue, 21 Aug 2001 13:20:24 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Keith Matthews Cc: linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B818039.C269C8A5@sgi.com> <3B818A5D.F9F8EE0C@club-internet.fr> <3B81A0D5.EBA77465@rebel.net.au>, <3B81F730.867E5916@ch.sauter-bc.com> <20010821071704.EC245125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Matthews schrieb: > > In response to the 3 people who asked about grub and XFS > > On Tue, 21 Aug 2001 07:52:48 +0200 Simon Matter > wrote: > > > I don't think this is a problem. Lilo was always there in the Mandrake > > distribution and can be used to boot XFS. If you really need grub just > > put /boot on ext2. BTW does grub boot JFS? > > Yes, a patch was published early July. I have not tried it myself > However I have seen no report about problems or success with it on > either the JFS list or the grub list. > > > > > > > Last time I looked at Grub and the latest version(s) of Lilo, the only > > > difference I could see was that Grub's configuration looked like NT > > > Loader's. So, why is Grub superior? > > > I'm not an expert on this but one significant difference is that grub > > does understand filesystems. This is very nice since you can boot every > > And this is where grub has problems, it has to understand the XFS > directory structure and be able to walk it. I'm sure Steve and co will > agree that it's not simple. progress has been made but I'm not able to > put full-time effort on it and XFS requires grub to use technigues it > has not done so before. > > I have not heard from Erich who was also trying. > > BTW, does anyone use a root partition and a separate boot one. You mean /boot on a different partition than /? I do it on every system to avoid all those problems with BIOS's limitations (1024cyl) and if necessary put a different filesystem on /boot. I also disable all kind of LBA mappings, be it on SCSI or IDE. This way it's possible to move disks from one box to the other, from one scsi controller to the other, without any problem. -Simon > > -- > Keith Matthews Spam trap - my real account at this > node is keith_m > Frequentous Consultants - Linux Services, > Oracle development & database administration From owner-linux-xfs@oss.sgi.com Tue Aug 21 04:46:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LBk9U18384 for linux-xfs-outgoing; Tue, 21 Aug 2001 04:46:09 -0700 Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LBk7918365 for ; Tue, 21 Aug 2001 04:46:07 -0700 Received: by giants.mandrakesoft.com (Postfix, from userid 500) id 748EBC090; Tue, 21 Aug 2001 13:46:13 +0200 (CEST) To: Eric Sandeen Cc: Simon Matter , linux-xfs Subject: Re: Mandrake Linux 8.1 beta without XFS References: <3B80B26E.1451FA7@ch.sauter-bc.com> <3B818039.C269C8A5@sgi.com> From: Chmouel Boudjnah Date: 21 Aug 2001 13:46:13 +0200 In-Reply-To: <3B818039.C269C8A5@sgi.com> (Eric Sandeen's message of "Mon, 20 Aug 2001 16:25:13 -0500") Message-ID: Lines: 9 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.104 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen writes: > I think it's too bad, but I also think that with all those filesystems > supported in the installer, it's probably not too much work for some > semi-ambitious person to spin their own Mandrake installer with XFS > support... (hint, hint!) the code is already there the only thing is too have a kernel-XFS in the installer. From owner-linux-xfs@oss.sgi.com Tue Aug 21 06:59:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LDx1P21647 for linux-xfs-outgoing; Tue, 21 Aug 2001 06:59:01 -0700 Received: from umcdev1.sharemedia.com ([151.200.228.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LDwx921628 for ; Tue, 21 Aug 2001 06:58:59 -0700 Received: from sharemedia.com (das [127.0.0.1]) by umcdev1.sharemedia.com (8.9.3/8.9.3) with ESMTP id JAA03212 for ; Tue, 21 Aug 2001 09:58:54 -0400 Message-ID: <3B82691E.C42507BA@sharemedia.com> Date: Tue, 21 Aug 2001 09:58:54 -0400 From: Dave Strout X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 1.0.1, DAC 960, & SGI 1200 References: <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> <200106180555.FAA00389@groucho.maths.monash.edu.au> <20010618091334.A2209@key.dkp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I looked back through the mailing list & didn't see this, but I may have missed it -- has anybody gotten 1.01 to work on an SGI 1200 with a DAC960 RAID card? We've tried a couple of times and get a firmly locked box during the postinstall...... thanks, dave. From owner-linux-xfs@oss.sgi.com Tue Aug 21 07:44:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LEiRZ23013 for linux-xfs-outgoing; Tue, 21 Aug 2001 07:44:27 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LEiO922991 for ; Tue, 21 Aug 2001 07:44:24 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id EC930C001C8 for ; Tue, 21 Aug 2001 22:44:24 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 85777C001C7 for ; Tue, 21 Aug 2001 22:44:23 +0800 (PHT) Date: Tue, 21 Aug 2001 22:44:23 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. In-Reply-To: <3B815EA6.E9A190C7@fnal.gov> 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 Mon, 20 Aug 2001 at 14:01, yocum@fnal.gov wrote: > Nothing terribly special. But I did lie about the kernel/XFS version, > accidentally: I upgraded to linux-2.4.8-xfs on Friday morning, the > corruption was discovered Friday night, but the files were written > back when the machine was running linux-2.4.7pre6-xfs. Dan, I'm just wondering, have you given 2.4.9 a shot, yet? I upgraded to 2.4.9 and noticed that hard lockups of the system when drives in my 3ware RAID5 fail (or get removed) went away. It _might_ have something to do with my VIA chipset (on the mobo), but I'm not quite sure. I have APIC and NMI for uniprocessors enabled, so that might have something to do with life (and hence makes this non-XFS specific). I had nfs-kernel-server running and disk activity when I pulled that drive out and ... it just went chugging along. Whee! :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Tue Aug 21 08:58:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LFwEM24379 for linux-xfs-outgoing; Tue, 21 Aug 2001 08:58:14 -0700 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 f7LFwA924360 for ; Tue, 21 Aug 2001 08:58:10 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GIFDOX00.6F7 for ; Tue, 21 Aug 2001 10:58:09 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001082110580810940 for ; Tue, 21 Aug 2001 10:58:08 -0500 Message-ID: <3B828623.4CE14DF9@fnal.gov> Date: Tue, 21 Aug 2001 11:02:43 -0500 From: yocum@fnal.gov 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: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: <3B8130DC.B0DCAC6C@fnal.gov> <3B813433.99FCCF2B@sgi.com> <4.3.2.7.2.20010820212625.03d832d8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > At 14:01 20-8-2001 -0500, yocum@fnal.gov wrote: > >I'd test on a non-RAID system if I had one (how often do you hear that? > >;-). I suppose I could try it on my desktop. I'll let you know how that > >goes, too. We're moving *lots* of data around (a few hundred GB/week at > >least). I'm trying to get the data analysts to use rcp instead of NFS, but > >that'll take some time. > > Slightly OT. > > how about scp and then using publickey authentication. I just managed to > set something like that up for the kt.zork.net mirror. > > You won't even need to enter passwords then although it is highly risky > when you use this on laptops. scp is OK for small amounts of data, but not so good for hundreds of GB, since it will encrypt the data before transferring it, which takes a bit more CPU time. Yes, I know you can recompile ssh to encrypt passwords and keys and send data in the clear, but I just haven't gotten around to it. Besides, a) rcp is in all the scripts the developers use to move stuff around, and b) the entire Lab will be kerberized by Dec 31, so we'll be using kerberized rcp (no .rhosts or host.equiv files laying around) and no passwords, either. Back on topic: at least one data analyst moved about 40GB of data around last night via NFS from OSF1 to Linux using NFVv3 and there were no inode corruptions. The kernel being used *is* 2.4.8-xfs which was compiled with gcc-2.96-85 (because I didn't get around to recompiling with kgcc yet, mkp). 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 Tue Aug 21 10:05:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LH51o25492 for linux-xfs-outgoing; Tue, 21 Aug 2001 10:05:01 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LH4v925473 for ; Tue, 21 Aug 2001 10:04:57 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id TAA02022; Tue, 21 Aug 2001 19:04:56 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA15234; Tue, 21 Aug 2001 19:04:55 +0200 (CEST) Date: Tue, 21 Aug 2001 19:04:55 +0200 (CEST) From: Seth Mos To: yocum@fnal.gov cc: xfs-list Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. In-Reply-To: <3B828623.4CE14DF9@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 21 Aug 2001 yocum@fnal.gov wrote: > Seth Mos wrote: > > > > At 14:01 20-8-2001 -0500, yocum@fnal.gov wrote: > > >I'd test on a non-RAID system if I had one (how often do you hear that? > > >;-). I suppose I could try it on my desktop. I'll let you know how that > > >goes, too. We're moving *lots* of data around (a few hundred GB/week at > > >least). I'm trying to get the data analysts to use rcp instead of NFS, but > > >that'll take some time. > > > > Slightly OT. > > > > how about scp and then using publickey authentication. I just managed to > > set something like that up for the kt.zork.net mirror. > > > > You won't even need to enter passwords then although it is highly risky > > when you use this on laptops. > > scp is OK for small amounts of data, but not so good for hundreds of GB, > since it will encrypt the data before transferring it, which takes a bit > more CPU time. I know. > Yes, I know you can recompile ssh to encrypt passwords and keys and send > data in the clear, but I just haven't gotten around to it. Besides, a) rcp > is in all the scripts the developers use to move stuff around, and b) the > entire Lab will be kerberized by Dec 31, so we'll be using kerberized rcp > (no .rhosts or host.equiv files laying around) and no passwords, either. Sounds tempting and worth looking into. > Back on topic: at least one data analyst moved about 40GB of data around > last night via NFS from OSF1 to Linux using NFVv3 and there were no inode > corruptions. The kernel being used *is* 2.4.8-xfs which was compiled with > gcc-2.96-85 (because I didn't get around to recompiling with kgcc yet, > mkp). If you see it again please recompile it if you can. Or find out what's going wrong with gcc 2.96. Cheers From owner-linux-xfs@oss.sgi.com Tue Aug 21 11:04:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LI45T26699 for linux-xfs-outgoing; Tue, 21 Aug 2001 11:04:05 -0700 Received: from exchange1.cinetic.de (exchange1.cinetic.de [195.226.107.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LI42926680 for ; Tue, 21 Aug 2001 11:04:03 -0700 Received: from webde-ag.de (10.1.2.5 [10.1.2.5]) by exchange1.cinetic.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Q9NC6F2G; Tue, 21 Aug 2001 20:04:01 +0200 Message-ID: <3B82A2DE.C4C6E0EE@webde-ag.de> Date: Tue, 21 Aug 2001 20:05:18 +0200 From: Sven X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.4.9-xfs-svh i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: make a huge anount of files Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi folks, we tried to make a lot of files on our xfs-filesystem for some performance tests. We've used a self written programm, which builds us 10.000 files of 4kb size in a directory, 401 times. We tested this programm with ext2, reiserfs and jfs and there are no problems. At the time we tried this test on the xfs, our system stopped at 79.000 files.(stopped mean that it does nothing, but wasn't crashed). we tried it 4 times, and always the same result, no exactly 79.000, but around this number. If we changed the programm to make 8k file, ist runs through, without any problems. Has anyone an idea what the problem could be? Regards Sven Herzing From owner-linux-xfs@oss.sgi.com Tue Aug 21 11:10:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LIA1N26912 for linux-xfs-outgoing; Tue, 21 Aug 2001 11:10:01 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LI9w926880 for ; Tue, 21 Aug 2001 11:09:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA00403 for ; Tue, 21 Aug 2001 11:09:57 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2746267; Tue, 21 Aug 2001 13:08:41 -0500 (CDT) Received: from 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 NAA96792; Tue, 21 Aug 2001 13:08:40 -0500 (CDT) Message-ID: <3B82A378.EA0A760D@sgi.com> Date: Tue, 21 Aug 2001 13:07:52 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Sven CC: linux-xfs@oss.sgi.com Subject: Re: make a huge anount of files References: <3B82A2DE.C4C6E0EE@webde-ag.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sven wrote: > > Hi folks, > we tried to make a lot of files on our xfs-filesystem for some > performance tests. We've used a self written programm, which builds us > 10.000 files of 4kb size in a directory, 401 times. We tested this > programm with ext2, reiserfs and jfs and there are no problems. At the > time we tried this test on the xfs, our system stopped at 79.000 > files.(stopped mean that it does nothing, but wasn't crashed). we tried > it 4 times, and always the same result, no exactly 79.000, but around > this number. If we changed the programm to make 8k file, ist runs > through, without any problems. > Has anyone an idea what the problem could be? Are you out of space? ;-) Can you send the test program, and we can try to replicate it here? Also any extra info on how you have your test partitions set up, kernel version, compiler version, etc. 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 Tue Aug 21 13:07:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LK7Qg29262 for linux-xfs-outgoing; Tue, 21 Aug 2001 13:07:26 -0700 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 f7LK7O929243 for ; Tue, 21 Aug 2001 13:07:24 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7LKCV832674 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 21 Aug 2001 13:12:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA308309 for ; Tue, 21 Aug 2001 22:07:16 +0200 (CEST) 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 PAA2773561 for ; Tue, 21 Aug 2001 15:05:59 -0500 (CDT) 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 PAA89653 for ; Tue, 21 Aug 2001 15:05:58 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7LK59a07303; Tue, 21 Aug 2001 15:05:10 -0500 Message-Id: <200108212005.f7LK59a07303@stout.americas.sgi.com> Date: Tue, 21 Aug 2001 15:05:10 -0500 From: sandeen@sgi.com Subject: TAKE - Fix blkno format size in xfs_ioerror_alert message Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If we happen to get called into xfs_ioerror_alert with a 64-bit block number, the Linux kernel vsprintf routines don't like a format that's smaller than the argument. In fact, it dislikes it so much that you'll get an oops. Change 0x%x to 0x%llx for a 64 bit number. Date: Tue Aug 21 13:02:30 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101175a linux/fs/xfs/xfs_rw.c - 1.344 - Fix blkno format size in xfs_ioerror_alert message From owner-linux-xfs@oss.sgi.com Tue Aug 21 16:23:53 2001 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LNNrp00755 for linux-xfs-outgoing@oss.sgi.com; Tue, 21 Aug 2001 16:23:53 -0700 Date: Tue, 21 Aug 2001 16:23:53 -0700 From: root To: linux-xfs-outgoing@oss.sgi.com Subject: [drake@jobpilot.it: "used obsolete MD ioctl"] Message-ID: <20010821162353.A750@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i ----- Forwarded message from Simone Drake Danini ----- X-Authentication-Warning: obi-wan.jobpilot.it: Host [10.39.100.40] claimed to be Drake From: "Simone \"Drake\" Danini" To: Subject: "used obsolete MD ioctl" Date: Thu, 16 Aug 2001 12:36:15 +0200 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-junkfilter: 20010528 X-Spammer: bodychk: market on the Internet Hi, i've just compiled kernel 2.4.5 with xfs patches and i try to run RAID1 on 2 scsi disks (adaptec controller) ... The RAID driver is "compiled" into the kernel (not as a module) with xfs ... Well mounting disks without xfs everything works fine ... if i try to setup the md device the system says while booting (swapper 1)Used obsolete MD ioctl. Update your software ... it doesn't seem to be a kernel problem because the adaptec controller and the md devices are recognized ok (filesystem types in the partition table are set to fd) ... the system stops while trying to mount disks (i guess) and i don't know where to check ... Can someone please help me ???? Thanks a lot in advance and Ciao Drake -------- * Simone Danini * IT Manager * jobpilot Italia srl * mailto:drake@jobpilot.it * www.jobpilot.it * www.jobpilot.com * Corso di Porta Romana, 68 * I-20122 Milano * Italia * tel: + 39.02.584.574-23 * fax: + 39.02.584.574-37 * mobile: +39.348.4904057 * Europe's career market on the Internet * Amsterdam * Bangkok * Barcelona * Brussels * Budapest * Copenhagen * Frankfurt * Gothenburg * Kuala Lumpur * London * Milan * Oslo * Paris * Prague * Singapore * Vienna * Warsaw * Zurich * ----- End forwarded message ----- From owner-linux-xfs@oss.sgi.com Tue Aug 21 16:24:08 2001 Received: (from root@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7LNO8n00789 for linux-xfs-outgoing@oss.sgi.com; Tue, 21 Aug 2001 16:24:08 -0700 Date: Tue, 21 Aug 2001 16:24:08 -0700 From: root To: linux-xfs-outgoing@oss.sgi.com Subject: [drake@jobpilot.it: raid1 on 2.4.5 with xfs 1.0.1 problem] Message-ID: <20010821162408.B750@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i ----- Forwarded message from Simone Drake Danini ----- X-Authentication-Warning: obi-wan.jobpilot.it: Host [10.39.100.40] claimed to be Drake From: "Simone \"Drake\" Danini" To: Subject: raid1 on 2.4.5 with xfs 1.0.1 problem Date: Thu, 16 Aug 2001 18:34:05 +0200 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-junkfilter: 20010528 X-Spammer: bodychk: market on the Internet Hi again, still trying to get raid1 working on my machine ... 2 scsi disks (3 partitons each disk) raid1 driver compiled statically with xfs support and support for SGI partitions latest xfs progs ecc. from the sgi site not root /dev/md0 have to be mounted under /lusr when i try to mount it it says wrong fs type, bad option, bad superblock on /dev/md0, or too many mounted file systems if i try mkraid --upgrade /dev/md0 it says that is up-to-date if i run xfs_reapir it says that everything is ok if it try xfs-logprint -t -i -b -e /dev/md0 it says data device: 0x900 log device: 0x900 daddr: 5839680 lenght: 64000 log tail: 2 head: 2 state: in /var/log/messages i find from the kernel a lot of XFS: size check 2 failed 09:00 rw=0, want=5839620, limit=5839552 attempt to access beyond the end of device but why ???? what can i do ???? thanks a lot in advance and Ciao Drake -------- * Simone Danini * IT Manager * jobpilot Italia srl * mailto:drake@jobpilot.it * www.jobpilot.it * www.jobpilot.com * Corso di Porta Romana, 68 * I-20122 Milano * Italia * tel: + 39.02.584.574-23 * fax: + 39.02.584.574-37 * mobile: +39.348.4904057 * Europe's career market on the Internet * Amsterdam * Bangkok * Barcelona * Brussels * Budapest * Copenhagen * Frankfurt * Gothenburg * Kuala Lumpur * London * Milan * Oslo * Paris * Prague * Singapore * Vienna * Warsaw * Zurich * ----- End forwarded message ----- From owner-linux-xfs@oss.sgi.com Tue Aug 21 19:30:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7M2USo05124 for linux-xfs-outgoing; Tue, 21 Aug 2001 19:30:28 -0700 Received: from cmmaustralia.com (IDENT:qmailr@[203.34.190.215]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M2UO905105 for ; Tue, 21 Aug 2001 19:30:25 -0700 Received: (qmail 31527 invoked by uid 506); 22 Aug 2001 02:29:29 -0000 Received: from list@fornax.net by cmma.cmmaustralia.com with qmail-scanner-0.94 (. Clean. Processed in 0.02333 secs); 22/08/2001 11:59:29 Received: from adl-office.airnet.com.au (HELO fornax.net) (203.34.190.136) by cmma.airnet.com.au with SMTP; 22 Aug 2001 02:29:29 -0000 Message-ID: <3B83193D.5050306@fornax.net> Date: Wed, 22 Aug 2001 12:00:21 +0930 From: Andrew Hill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: Disappearing files in the / directory References: <4.3.2.7.2.20010821085540.03e728d8@pop.xs4all.nl> <4.3.2.7.2.20010821091214.03e70438@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > Compile it with egcs 1.1.2 please. This one is also known as kgcc on > redhat 7.x systems and can be found in the compat-egcs package. Done. > You might also find it a > good idea to build a newer kernel which will have more VIA fixes without > doubt. No worries, I have updated to the 2.4.9 kernel. It's all good now! Interesting that is hasn't caused any issues on my other machine. Oh well. Thanks for your help! Cheers, -- Andrew Hill "Being attractive was never part of my game plan." - 2001-03-28 From owner-linux-xfs@oss.sgi.com Tue Aug 21 20:57:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7M3vEV19199 for linux-xfs-outgoing; Tue, 21 Aug 2001 20:57:14 -0700 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 f7M3vC919180 for ; Tue, 21 Aug 2001 20:57:12 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7M42K827255 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 21 Aug 2001 21:02:20 -0700 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 FAA318978 for ; Wed, 22 Aug 2001 05:57:04 +0200 (CEST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA16713; Wed, 22 Aug 2001 13:57:01 +1000 Date: Wed, 22 Aug 2001 13:57:01 +1000 From: Keith Owens Message-Id: <200108220357.NAA16713@sherman.melbourne.sgi.com> Subject: TAKE - Correct buggy 2.4.9 min/max definitions Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The new min/max definitions in 2.4.9 do not correctly handle pointer types. XFS does min(char *) in qsort.c and generates incorrect code because of the kernel bug. This is a temporary patch, until Linus corrects kernel.h. Date: Tue Aug 21 20:55:13 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101223a linux/include/linux/kernel.h - 1.21 From owner-linux-xfs@oss.sgi.com Tue Aug 21 22:38:09 2001 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M5c8920968; Tue, 21 Aug 2001 22:38:08 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id HAA23888; Wed, 22 Aug 2001 07:38:06 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id HAA13013; Wed, 22 Aug 2001 07:38:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id EC45657306; Wed, 22 Aug 2001 07:37:45 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id DF72325835; Wed, 22 Aug 2001 07:37:45 +0200 (CEST) Sender: simix@mobile.sauter-bc.com Message-ID: <3B834529.65F6451B@ch.sauter-bc.com> Date: Wed, 22 Aug 2001 07:37:45 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: root Cc: linux-xfs-outgoing@oss.sgi.com Subject: Re: [drake@jobpilot.it: "used obsolete MD ioctl"] References: <20010821162353.A750@oss.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii root schrieb: > > ----- Forwarded message from Simone Drake Danini ----- > > X-Authentication-Warning: obi-wan.jobpilot.it: Host [10.39.100.40] claimed to be Drake > From: "Simone \"Drake\" Danini" > To: > Subject: "used obsolete MD ioctl" > Date: Thu, 16 Aug 2001 12:36:15 +0200 > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Importance: Normal > X-junkfilter: 20010528 > X-Spammer: bodychk: market on the Internet > ?????? > Hi, > i've just compiled kernel 2.4.5 with xfs patches and i try to run RAID1 on > 2 scsi disks (adaptec controller) ... The RAID driver is "compiled" into the > kernel (not as a module) with xfs ... > Well mounting disks without xfs everything works fine ... > if i try to setup the md device the system says while booting > > (swapper 1)Used obsolete MD ioctl. > Update your software ... I don't know exactly what it means but you get this error when using softraid for swap. I do it since ever and it has never made me problems. > > it doesn't seem to be a kernel problem because the adaptec controller and > the md devices are recognized ok (filesystem types in the partition table > are set to fd) ... the system stops while trying to mount disks (i guess) > and i don't know where to check ... > > Can someone please help me ???? > > Thanks a lot in advance and Ciao > > Drake > > -------- > * Simone Danini * IT Manager * jobpilot Italia srl > * mailto:drake@jobpilot.it * www.jobpilot.it * www.jobpilot.com > * Corso di Porta Romana, 68 * I-20122 Milano * Italia > * tel: + 39.02.584.574-23 * fax: + 39.02.584.574-37 > * mobile: +39.348.4904057 > > * Europe's career market on the Internet > * Amsterdam * Bangkok * Barcelona * Brussels * Budapest * Copenhagen > * Frankfurt * Gothenburg * Kuala Lumpur * London * Milan * Oslo > * Paris * Prague * Singapore * Vienna * Warsaw * Zurich * > > ----- End forwarded message ----- -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Wed Aug 22 03:19:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7MAJ4S25642 for linux-xfs-outgoing; Wed, 22 Aug 2001 03:19:04 -0700 Received: from smarthost1.mail.easynet.fr (smarthost1.mail.easynet.fr [212.180.1.68]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7MAIw925622 for ; Wed, 22 Aug 2001 03:18:59 -0700 Received: from mailhub3.mail.easynet.fr (slb-1-sippriv.mail.easynet.fr [10.0.1.57]) by smarthost1.mail.easynet.fr (Postfix) with ESMTP id 05F16BAFC for ; Wed, 22 Aug 2001 12:18:57 +0200 (CEST) Received: (qmail 10086 invoked by uid 0); 22 Aug 2001 10:19:03 -0000 Received: (qmail 60733 invoked from network); 20 Aug 2001 16:06:40 -0000 Received: from unknown (HELO mx1.mail.easynet.fr) ([10.0.1.58]) (envelope-sender ) by mailhub1.mail.easynet.fr (qmail-ldap-1.03) with SMTP for ; 20 Aug 2001 16:06:40 -0000 Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by mx1.mail.easynet.fr (Postfix) with ESMTP id 1CD74B6A7 for ; Mon, 20 Aug 2001 18:06:40 +0200 (CEST) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KG6YV24218; Mon, 20 Aug 2001 09:06:34 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Mon, 20 Aug 2001 09:06:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7KG6Wh24182 for linux-xfs-outgoing; Mon, 20 Aug 2001 09:06:32 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KG6Tj24162 for ; Mon, 20 Aug 2001 09:06:29 -0700 Received: from thebarn.com ([63.231.179.33]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7KG6RXi088276; Mon, 20 Aug 2001 11:06:27 -0500 (CDT) Message-ID: <3B813450.9090805@thebarn.com> Date: Mon, 20 Aug 2001 11:01:20 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: yocum@fnal.gov Cc: xfs-list Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: <3B8130DC.B0DCAC6C@fnal.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk yocum@fnal.gov wrote: >Hi all, > >I've been having a problem that I thought might be related to Tridge's, but >maybe not: > >When copying directories over NFS (v2) from OSF1 clients to a Linux server >with XFS, files and directories will mysteriously "vanish" after the cp >completes, however, enough of the file/dir remains (i.e., the name of the >file in the inode table) that an ls of the dir will yield this: > > >[root@sdssdp9 rawdata]# ls CANNOT_RM.51940/ >ls: CANNOT_RM.51940/guider: No such file or directory > > >As the name of the directory suggests, not enough information remains in the >inode table to rm it, either. > >One clue that's in /var/log/messages is this: > > >Aug 18 00:14:10 sdssdp9 kernel: xfs_create looping, dir ino 0xa25e000, ino >0x101000800, md(9,0) >Aug 18 00:14:10 sdssdp9 kernel: >Aug 18 00:14:10 sdssdp9 kernel: nfsd: non-standard errno: -990 > Are you seeing any other error messages on the linux server? Error 990 is file system shutdown which is usally the result of a hardware error. > > > >I have also been able to reproduce this problem copying files over local >NFSv2 (i.e., the NFS exported volume is mounted locally) so, this is not >only an OSF1 -> Linux problem. > >At the threat of being beaten with a sharp pointy stick by mkp (since I know >he *loves* IDE disks ;-), here's the hw and sw configuration of these >machines: > >Intel STL2 mobo >2 866MHz P-III >512MB RAM >Netgear GA620 Gig-e NIC >2 3ware 7810 8 port RAID controller cards (configured as RAID5) >1 3ware 6200 2 port RAID controller card (configured as RAID1 for system >disk) >16 Maxtor 81.9GB disks (for data) > I remeber somebody mentioning the 3ware raid controllers are know to have problems... I think it was Martin Peterson. > > >SGI modified Red Hat 7.1 distribution >linux-2.4.8-xfs from CVS (Thursday, Aug 16) > >I've configured each 3ware 7810 card as RAID5, then I'm using sw RAID0 to >stripe across the devices yielding a 1.12TB filesystem. > >I'd try the same tests to a system that is not using IDE disks, but we don't >have any of those. (Sorry, Martin) > >I've performed an xfs_repair on the device and everything was fixed up, >files were saved off into lost+found, inodes cleared, etc. and I've attached >the output if anyone is interested. > >Thanks, >Dan > > From owner-linux-xfs@oss.sgi.com Wed Aug 22 09:33:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7MGXA200322 for linux-xfs-outgoing; Wed, 22 Aug 2001 09:33:10 -0700 Received: from mens.hq.novamens.com ([168.226.30.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7MGX5900301 for ; Wed, 22 Aug 2001 09:33:05 -0700 Received: from there (lone.hq.novamens.com [192.168.1.3]) by mens.hq.novamens.com (8.11.2/8.8.7) with SMTP id f7MGWvB30079 for ; Wed, 22 Aug 2001 13:32:57 -0300 Message-Id: <200108221632.f7MGWvB30079@mens.hq.novamens.com> Content-Type: text/plain; charset="iso-8859-1" From: Juan Jose Comellas To: Linux XFS Subject: Fwd: Re: Small fix needed to compile NTFS in Linux 2.4.9 Date: Wed, 22 Aug 2001 13:32:57 -0300 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In case anyone needs to compile the current kernel in CVS (2.4.9) including the NTFS filesystem you'll have to make the following change to the file linux/fs/ntfs/unistr.c. ---------- Forwarded Message ---------- Subject: Re: Small fix needed to compile NTFS in Linux 2.4.9 Date: Sun, 19 Aug 2001 02:11:48 +0100 From: Anton Altaparmakov To: Juan Jose Comellas Cc: NTFS Maintainer Yes, known problem. This happened because someone changed all min/max macros to be global macros throughout the kernel but while doing this forgot to add this include to ntfs/unistr.c... Thanks, Anton At 18:31 18/08/2001, Juan Jose Comellas wrote: >I had to make a small fix to the file fs/ntfs/unistr.c to get it to compile >under the standard Linux kernel 2.4.9. I compiled NTFS as a module. Here is >the diff in case you haven't corrected it yet: > >--- unistr.c.orig Wed Aug 15 05:22:17 2001 >+++ unistr.c Sat Aug 18 14:26:34 2001 >@@ -21,6 +21,7 @@ > * Foundation,Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 > USA */ > >+#include > #include > #include > > >The problem was that the macro min() was not defined (linux/kernel.h header >not included), so there was an error in line 99. > >-- >Juan Jose Comellas >(jcomellas@novamens.com) -- "Nothing succeeds like success." - Alexandre Dumas -- 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/ ------------------------------------------------------- -- Juan Jose Comellas (juanjo@comellas.org) From owner-linux-xfs@oss.sgi.com Thu Aug 23 00:32:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7N7WU517409 for linux-xfs-outgoing; Thu, 23 Aug 2001 00:32:30 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7N7WLd17390 for ; Thu, 23 Aug 2001 00:32:22 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id AF9CCC00FC7; Thu, 23 Aug 2001 15:32:18 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 275D8C00AC1; Thu, 23 Aug 2001 15:32:17 +0800 (PHT) Date: Thu, 23 Aug 2001 15:32:17 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Martin Apel Cc: Linux XFS Mailing List Subject: XFS and inodes (was: Recommendation on stable Reiserfs+NFS setup) In-Reply-To: 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 Martin, (cc XFS Mailing List) On Thu, 23 Aug 2001 at 09:11, Martin Apel wrote: > There's one drawback using XFS instead of ReiserFS. You have to fix > the number of available i-nodes at FS-creation time. A few times in > the past I had too few i-nodes on a filesystem which was otherwise > still not full, so I had to copy all data somewhere else, reformat, > and copy back. This is something I would like to avoid. This is interesting. I have not handled filesystems as large as yours, but have always been under the impression that XFS on Linux preallocates inodes based on need (on-demand). Perhaps one limiting factor, though, could be the maximum percentage of the space to be allocated for inodes defined when the filesystem is made. I'm sending a copy of this reply to the XFS mailing list, though, so that the experts there can help us both clarify this issue on maximum inodes. > Apart from that we have a few volumes with very many small files which > have to be exported via NFS. ReiserFS is probably a better choice for > these filesystems. But I anyway I will have a closer look at XFS. Wrong. ReiserFS is _better_ for those many small files. On the other hand XFS is great as the file size increases, and you will see this trend even on the benchmarks done by the ReiserFS team. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 23 00:49:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7N7n8A17780 for linux-xfs-outgoing; Thu, 23 Aug 2001 00:49:08 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7N7n4d17758 for ; Thu, 23 Aug 2001 00:49:04 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id JAA13846; Thu, 23 Aug 2001 09:48:42 +0200 (CEST) Message-Id: <4.3.2.7.2.20010823094610.0341edb0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Aug 2001 09:48:06 +0200 To: Federico Sevilla III , Martin Apel From: Seth Mos Subject: Re: XFS and inodes (was: Recommendation on stable Reiserfs+NFS setup) Cc: Linux XFS Mailing List 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 15:32 23-8-2001 +0800, Federico Sevilla III wrote: >Martin, >(cc XFS Mailing List) > >On Thu, 23 Aug 2001 at 09:11, Martin Apel wrote: > > There's one drawback using XFS instead of ReiserFS. You have to fix > > the number of available i-nodes at FS-creation time. A few times in > > the past I had too few i-nodes on a filesystem which was otherwise > > still not full, so I had to copy all data somewhere else, reformat, > > and copy back. This is something I would like to avoid. > >This is interesting. I have not handled filesystems as large as yours, but >have always been under the impression that XFS on Linux preallocates >inodes based on need (on-demand). Perhaps one limiting factor, though, >could be the maximum percentage of the space to be allocated for inodes >defined when the filesystem is made. On a XFS filesystem you can only allocate 50% of the space as inodes by default. If you have a large filessytem it will take you a longer time to reach it. See the mkfs.xfs manpage for creating a higher maximum inodes limit. Cheers >I'm sending a copy of this reply to the XFS mailing list, though, so that >the experts there can help us both clarify this issue on maximum inodes. > > > Apart from that we have a few volumes with very many small files which > > have to be exported via NFS. ReiserFS is probably a better choice for > > these filesystems. But I anyway I will have a closer look at XFS. > >Wrong. ReiserFS is _better_ for those many small files. On the other hand >XFS is great as the file size increases, and you will see this trend even >on the benchmarks done by the ReiserFS team. > > --> Jijo > >-- >Federico Sevilla III :: jijo@leathercollection.ph >Network Administrator :: The Leather Collection, Inc. >GnuPG Key: -- 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 Aug 23 01:08:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7N889o18372 for linux-xfs-outgoing; Thu, 23 Aug 2001 01:08:09 -0700 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 f7N887d18353 for ; Thu, 23 Aug 2001 01:08:07 -0700 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 f7N8ELa10921 for ; Thu, 23 Aug 2001 01:14:22 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA08978; Thu, 23 Aug 2001 18:06:43 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA40179; Thu, 23 Aug 2001 18:06:43 +1000 (AEST) Date: Thu, 23 Aug 2001 18:06:42 +1000 From: Nathan Scott To: Federico Sevilla III Cc: Martin Apel , Linux XFS Mailing List Subject: Re: XFS and inodes (was: Recommendation on stable Reiserfs+NFS setup) Message-ID: <20010823180642.C323882@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jijo@leathercollection.ph on Thu, Aug 23, 2001 at 03:32:17PM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 23, 2001 at 03:32:17PM +0800, Federico Sevilla III wrote: > Martin, > (cc XFS Mailing List) > > On Thu, 23 Aug 2001 at 09:11, Martin Apel wrote: > > There's one drawback using XFS instead of ReiserFS. You have to fix > > the number of available i-nodes at FS-creation time. A few times in No, I'm pretty sure you can increase this value while the filesystem is mounted - see the -m option to xfs_growfs. > > the past I had too few i-nodes on a filesystem which was otherwise > > still not full, so I had to copy all data somewhere else, reformat, > > and copy back. This is something I would like to avoid. I guess its too late now, but you almost certainly didn't need to do that. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 23 04:44:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NBiCC23042 for linux-xfs-outgoing; Thu, 23 Aug 2001 04:44:12 -0700 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 f7NBi9d23023 for ; Thu, 23 Aug 2001 04:44:09 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7NBnL827382 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 23 Aug 2001 04:49:22 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id NAA400794 for ; Thu, 23 Aug 2001 13:44:01 +0200 (CEST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA81366 for linux-xfs@oss.sgi.com; Thu, 23 Aug 2001 21:42:42 +1000 (EST) Date: Thu, 23 Aug 2001 21:42:42 +1000 (EST) From: Nathan Scott Message-Id: <200108231142.VAA81366@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota tidyup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some minor tidyups to make the quota VFS change more palatable (our quota VFS change allows any filesystem to manage quota on their own - currently only XFS has such a need). cheers. Date: Thu Aug 23 04:23:54 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101363a linux/include/linux/fs.h - 1.111 linux/fs/dquot.c - 1.30 linux/fs/xfs/linux/xfs_super.c - 1.134 - rework the quotactl entry point into a specific filesystem - use a vector in the quota_mount_options structure rather than the super_operations one. linux/fs/xfs/linux/xfs_linux.h - 1.52 - don't need to make up a bogus errno for EWRONGFS - this is never passed back to userspace and is in fact never even looked at in the kernel. so just equate it to EINVAL and be done with it. linux/include/linux/xqm.h - 1.6 - update the comments for XFS quotactl ops - and only define them if we haven't got them from elsewhere already... ideally, we want these to be coming from quota.h someday soon. From owner-linux-xfs@oss.sgi.com Thu Aug 23 04:59:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NBxQf23428 for linux-xfs-outgoing; Thu, 23 Aug 2001 04:59:26 -0700 Received: from mx.linux.net.cn ([210.52.24.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NBxLd23409 for ; Thu, 23 Aug 2001 04:59:24 -0700 Received: from dfbbb.cn.mvd (unknown [211.99.247.66]) by mx.linux.net.cn (Postfix) with ESMTP id 66C3CD1E for ; Thu, 23 Aug 2001 20:00:10 +0800 (CST) Received: (from dfbb@localhost) by dfbbb.cn.mvd (8.11.2/8.11.2) id f7NC0A709698 for linux-xfs@oss.sgi.com; Thu, 23 Aug 2001 20:00:10 +0800 Date: Thu, 23 Aug 2001 20:00:10 +0800 From: Allen Qun To: linux-xfs@oss.sgi.com Subject: About XFS-1.0.1 Kickstart Message-ID: <20010823200010.A9661@dfbbb.cn.mvd> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi: I try to use XFS - 1.0.1 to kickstart install on some Server, Which contain an DAC960 raid controller, Which device place on /dev/rd/c0d0 , And I want special the part --type xfs --ondisk rd/c0d0 or part --type xfs --ondisk c0d0 both of them can't work, It seems installer can't process such parameter. Is there any way to deal with such situation? BTW: I try to use anaconda to upgrade the installer, But it seems the default install of anaconda can't work ( I use the package with XFS-1.0.1) Is there any special way or any guide to teach me? Allen From owner-linux-xfs@oss.sgi.com Thu Aug 23 05:40:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NCeMv24912 for linux-xfs-outgoing; Thu, 23 Aug 2001 05:40:22 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NCeHd24891 for ; Thu, 23 Aug 2001 05:40:17 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id OAA09580 for ; Thu, 23 Aug 2001 14:40:15 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA22077 for linux-xfs@oss.sgi.com; Thu, 23 Aug 2001 14:40:15 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id BCAE357306 for ; Thu, 23 Aug 2001 14:39:20 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 67D6F25835 for ; Thu, 23 Aug 2001 14:39:20 +0200 (CEST) Message-ID: <3B84F978.A447BCA@ch.sauter-bc.com> Date: Thu, 23 Aug 2001 14:39:20 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: xfsrestore dumps core Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I was just trying to xfsdump and -restore some files on my test system and I get a core dump while restoring. The system is PII/400, 256MB, IDE disk, DLT1 tape drive /DELL PowerVault 110T). RH XFS 1.0.1 release, newest command rpms, including xfsdump-1.1.3-0. BTW /dev/tape is a link to /dev/st0 I did the dump with: xfsdump -f /dev/tape -l 0 -s home -o -L session1 -M medium1 / No problems so far, then is tried restore with: [root@looser /root]# xfsrestore -f /dev/tape xfsrestore xfsrestore: version 3.0 - Running single-threaded xfsrestore: searching media for dump xfsrestore: preparing drive xfsrestore: examining media file 0 =========================== dump selection dialog ============================ the following dump has been found on drive 0 hostname: looser.cad.sba mount point: / volume: /dev/hda8 session time: Thu Aug 23 13:33:34 2001 level: 0 session label: "session1" media label: "medium1" file system id: 5ca101b0-8da5-11d5-9fc7-0060974fc952 session id: e1a56db0-c31e-45f2-91c1-313c6fe29fb7 media id: 1f9cfa70-b0bf-48e5-ae30-db7c8f4a9609 restore this dump? 1: skip 2: restore (default) -> 2 this dump selected for restoral --------------------------------- end dialog --------------------------------- xfsrestore: using online session inventory xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: directory post-processing xfsrestore: restoring non-directory files xfsrestore: examining media file 1 xfsrestore: seeking past media file directory dump xfsrestore: drive_scsitape.c:1492: do_next_mark: Assertion `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( contextp->dc_recsz )' failed. Aborted (core dumped) I saw some discussion about this some weeks ago on this list but I was wondering it's not yet fixed or I'm doing something completly wrong ? How are others doing dumps AND restore via DLT drives? -Simon -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Thu Aug 23 07:00:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NE08226834 for linux-xfs-outgoing; Thu, 23 Aug 2001 07:00:08 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NE04d26815 for ; Thu, 23 Aug 2001 07:00:05 -0700 Received: (qmail 78183 invoked from network); 23 Aug 2001 14:00:04 -0000 Received: from mplsdslgw15poolc32.mpls.uswest.net (HELO sgi.com) (63.229.198.32) by mplspop2.mpls.uswest.net with SMTP; 23 Aug 2001 14:00:04 -0000 Date: Thu, 23 Aug 2001 08:56:08 -0500 Message-ID: <3B850B78.A02AEEF6@sgi.com> From: "Eric Sandeen" To: "Allen Qun" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: About XFS-1.0.1 Kickstart References: <20010823200010.A9661@dfbbb.cn.mvd> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Allen Qun wrote: > > Hi: > > I try to use XFS - 1.0.1 to kickstart install on some Server, > Which contain an DAC960 raid controller, Which device place > on /dev/rd/c0d0 , And I want special the > > part --type xfs --ondisk rd/c0d0 > > or > > part --type xfs --ondisk c0d0 > > both of them can't work, It seems installer can't process such > parameter. Is there any way to deal with such situation? People have reported problems with raid & kickstart & xfs... I'm not certain what the problem is at this point. If you got any error messages, could you send them to me? > BTW: > > I try to use anaconda to upgrade the installer, But it seems > the default install of anaconda can't work ( I use the package > with XFS-1.0.1) Is there any special way or any guide to teach > me? I'm sorry, I'm not sure what you're asking... -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 Aug 23 07:25:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NEPMh27480 for linux-xfs-outgoing; Thu, 23 Aug 2001 07:25:22 -0700 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 f7NEPId27456 for ; Thu, 23 Aug 2001 07:25:18 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7NEUT809179 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 23 Aug 2001 07:30:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA392257 for ; Thu, 23 Aug 2001 16:25:09 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2561222; Thu, 23 Aug 2001 09:23:50 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA58606; Thu, 23 Aug 2001 09:23:50 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7NENiT32623; Thu, 23 Aug 2001 09:23:44 -0500 Message-Id: <200108231423.f7NENiT32623@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Federico Sevilla III cc: Martin Apel , Linux XFS Mailing List Subject: Re: XFS and inodes (was: Recommendation on stable Reiserfs+NFS setup) In-Reply-To: Message from Federico Sevilla III of "Thu, 23 Aug 2001 15:32:17 +0800." Date: Thu, 23 Aug 2001 09:23:44 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Martin, > (cc XFS Mailing List) > > On Thu, 23 Aug 2001 at 09:11, Martin Apel wrote: > > There's one drawback using XFS instead of ReiserFS. You have to fix > > the number of available i-nodes at FS-creation time. A few times in > > the past I had too few i-nodes on a filesystem which was otherwise > > still not full, so I had to copy all data somewhere else, reformat, > > and copy back. This is something I would like to avoid. > > This is interesting. I have not handled filesystems as large as yours, but > have always been under the impression that XFS on Linux preallocates > inodes based on need (on-demand). Perhaps one limiting factor, though, > could be the maximum percentage of the space to be allocated for inodes > defined when the filesystem is made. > > I'm sending a copy of this reply to the XFS mailing list, though, so that > the experts there can help us both clarify this issue on maximum inodes. XFS defaults to allowing 25% of the filesystem space to being available for inodes, this is a mkfs option. What this means is that once you have consumed this amount of space for inodes you will be allowed to create no more. The other reason for failing to create inodes is a full filesystem. With the default inode size this translates to 1 million inodes per Gbyte being allowed in the filesystem. If your average file size is very small then you could run out, allowing a bigger percentage at mkfs time would make this less of an issue. Also Nathan was correct, you can change this dynamically with xfs_growfs: -m Specify a new value for the maximum percentage of space in the filesystem that can be allocated as inodes. In mkfs_xfs this is specified with -i maxpct=nn. Steve > > > Apart from that we have a few volumes with very many small files which > > have to be exported via NFS. ReiserFS is probably a better choice for > > these filesystems. But I anyway I will have a closer look at XFS. > > Wrong. ReiserFS is _better_ for those many small files. On the other hand > XFS is great as the file size increases, and you will see this trend even > on the benchmarks done by the ReiserFS team. > > --> Jijo > > -- > Federico Sevilla III :: jijo@leathercollection.ph > Network Administrator :: The Leather Collection, Inc. > GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 23 07:45:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NEjCA27908 for linux-xfs-outgoing; Thu, 23 Aug 2001 07:45:12 -0700 Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NEj9d27889 for ; Thu, 23 Aug 2001 07:45:09 -0700 Received: from mmstreaming.dk (cpe.atm2-0-107249.arcnxx9.customer.tele.dk [62.242.148.83]) by pasmtp.tele.dk (Postfix) with ESMTP id BF749B532 for ; Thu, 23 Aug 2001 16:45:07 +0200 (CEST) Received: by mmstreaming.dk (Postfix, from userid 501) id E4491ADB9; Thu, 23 Aug 2001 16:45:06 +0200 (CEST) Date: Thu, 23 Aug 2001 16:45:06 +0200 From: Thomas Kirk To: linux-xfs@oss.sgi.com Subject: productionserver Message-ID: <20010823164506.A9758@mmstreaming.dk> 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 Hey there listmembers Im looking into building a streaming media storage server in a production enviroment. The server has to be available 24/7 preferable ;-). We are using debian as our prefered OS and as such im gonna us this to build the storage server. The diskarray are gonna be shared via CIFS and optional NFS and now the question is what fs would i choose for this system. Ive been lurkeing around on the listarchives for a while and reading almost all the mails regarding XFS. The question is : Is XFS in its current state ready for production enviroments and yes i read the FAQ but it would be nice with some real world experince from other "sysadmins". I would be very gratefull for any help this list could come up with. Thanks in advance -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas@arkena.com Http://www.arkena.com "And the next time you consider complaining that running Lucid Emacs 19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to get the background colors right, you'll know who to thank." (By Matt Welsh) From owner-linux-xfs@oss.sgi.com Thu Aug 23 07:51:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NEpZA28130 for linux-xfs-outgoing; Thu, 23 Aug 2001 07:51:35 -0700 Received: from monmouth.edu (8e.dmz.monmouth.edu [206.30.71.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NEpTd28104 for ; Thu, 23 Aug 2001 07:51:29 -0700 Received: by monmouth.edu; id KAA14200; Thu, 23 Aug 2001 10:52:18 -0400 (EDT) Received: from sunset.monmouth.edu(192.100.64.190) by webshield.monmouth.edu via csmap (V4.1) id srcAAA6oaqUB; Thu, 23 Aug 01 10:52:16 -0400 Received: from framus (framus.hhadmin.monmouth.edu [10.1.12.162]) by sunset.monmouth.edu (8.9.3/8.9.3) with ESMTP id KAA02515 for ; Thu, 23 Aug 2001 10:51:16 -0400 (EDT) From: "Robert Carsey" To: Subject: FW: [ linuxquota-Bugs-449992 ] repquota reporting Date: Thu, 23 Aug 2001 10:51:19 -0400 Message-ID: <000201c12be3$11f1bbb0$9865fea9@framus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I had initially posted this to sourceforge. repquota command only returns those UIDs which are in /etc/passwd. Feature or bug? My server ONLY runs as an nfs server, which means 99% of my UIDs are foreign to the system and are unresolvable. Of course, when putting a quota on a UID, it does work fine -- its just not listed in repquota. The quota maintainers replied: This is a feature as on XFS quota utilities have no possibility to get list of users with quotas and so utilities just take users from passwd. Is this true? Can we do something about this? I don't remember running into this on SGI machines... --Rob ------------------------------------------------------------ Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: repquota reporting Initial Comment: repquota command only returns those UIDs which are in /etc/passwd. Feature or bug? My server ONLY runs as an nfs server, which means 99% of my UIDs are foreign to the system and are unresolvable. [root@netapp2 /sbin]# repquota -F xfs -vau *** Report for user quotas on device /dev/data_group/lvol1 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ------------------------------------------------------- --------------- root -- 460 0 0 51 0 0 *** Status for user quotas on device /dev/data_group/lvol1 Accounting: ON; Enforcement: ON Inode: #26944 (203 blocks, 193 extents) --- put UID #17428 in /etc/passwd ---- [root@netapp2 quota-tools]# repquota -F xfs -a *** Report for user quotas on device /dev/data_group/lvol1 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ------------------------------------------------------- --------------- root -- 460 0 0 51 0 0 testuser +- 109996 100000 110000 6days 6 0 0 ---------------------------------------------------------------------- >Comment By: Jan Kara (jkar8572) Date: 2001-08-23 07:29 Message: Logged In: YES user_id=83314 This is a feature as on XFS quota utilities have no possibility to get list of users with quotas and so utilities just take users from passwd. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=118136&aid=449992&group _id=18136 From owner-linux-xfs@oss.sgi.com Thu Aug 23 07:55:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NEtXC28308 for linux-xfs-outgoing; Thu, 23 Aug 2001 07:55:33 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NEtQd28287 for ; Thu, 23 Aug 2001 07:55:26 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA02983 for ; Thu, 23 Aug 2001 07:55:26 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2791314; Thu, 23 Aug 2001 09:54:10 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA11436; Thu, 23 Aug 2001 09:54:09 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7NEs3h32731; Thu, 23 Aug 2001 09:54:03 -0500 Message-Id: <200108231454.f7NEs3h32731@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Robert Carsey" cc: Linux-xfs@oss.sgi.com Subject: Re: FW: [ linuxquota-Bugs-449992 ] repquota reporting In-Reply-To: Message from "Robert Carsey" of "Thu, 23 Aug 2001 10:51:19 EDT." <000201c12be3$11f1bbb0$9865fea9@framus> Date: Thu, 23 Aug 2001 09:54:02 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I had initially posted this to sourceforge. repquota command only > returns those UIDs which are in /etc/passwd. Feature or bug? My server > ONLY runs > as an nfs server, which means 99% of my UIDs are foreign to the system > and are unresolvable. Of course, when putting a quota on a UID, it does > work fine -- its just not listed in repquota. > > The quota maintainers replied: > This is a feature as on XFS quota utilities have no > possibility to get list of users with quotas and so > utilities just take users from passwd. > > > Is this true? Can we do something about this? I don't remember running > into this on SGI machines... It does not sound right, but all our quota expertise is in Australia and should be safely tucked up in bed now, so you will have to wait a few hours for an answer! Steve > > --Rob > > ------------------------------------------------------------ > Category: None > Group: None > >Status: Closed > >Resolution: Wont Fix > Priority: 5 > Submitted By: Nobody/Anonymous (nobody) > Assigned to: Nobody/Anonymous (nobody) > Summary: repquota reporting > > Initial Comment: > repquota command only returns those UIDs which are > in /etc/passwd. Feature or bug? My server ONLY runs > as an nfs server, which means 99% of my UIDs are > foreign to the system and are unresolvable. > > [root@netapp2 /sbin]# repquota -F xfs -vau > *** Report for user quotas on > device /dev/data_group/lvol1 > Block grace time: 7days; Inode grace time: 7days > Block limits > File limits > User used soft hard grace used > soft hard grace > ------------------------------------------------------- > --------------- > root -- 460 0 0 > 51 0 0 > > *** Status for user quotas on > device /dev/data_group/lvol1 > Accounting: ON; Enforcement: ON > Inode: #26944 (203 blocks, 193 extents) > > --- put UID #17428 in /etc/passwd ---- > [root@netapp2 quota-tools]# repquota -F xfs -a > *** Report for user quotas on > device /dev/data_group/lvol1 > Block grace time: 7days; Inode grace time: 7days > Block limits > File limits > User used soft hard grace used > soft hard grace > ------------------------------------------------------- > --------------- > root -- 460 0 0 > 51 0 0 > testuser +- 109996 100000 110000 6days > 6 0 0 > > > ---------------------------------------------------------------------- > > >Comment By: Jan Kara (jkar8572) > Date: 2001-08-23 07:29 > > Message: > Logged In: YES > user_id=83314 > > This is a feature as on XFS quota utilities have no > possibility to get list of users with quotas and so > utilities just take users from passwd. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=118136&aid=449992&group > _id=18136 From owner-linux-xfs@oss.sgi.com Thu Aug 23 07:57:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NEvxp28483 for linux-xfs-outgoing; Thu, 23 Aug 2001 07:57:59 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NEvud28464 for ; Thu, 23 Aug 2001 07:57:56 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f7NEvCg02994; Thu, 23 Aug 2001 10:57:26 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 23 Aug 2001 10:57:12 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Thomas Kirk cc: Subject: Re: productionserver In-Reply-To: <20010823164506.A9758@mmstreaming.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 23 Aug 2001 at 4:45pm, Thomas Kirk wrote > question is : Is XFS in its current state ready for production > enviroments and yes i read the FAQ but it would be nice with some real > world experince from other "sysadmins". I would be very gratefull for > any help this list could come up with. One data point: I've been using XFS in production since mid-March on a 560GB hardware RAID NFS served to about 20 moderately active clients. Until 2 weeks ago, I was running a pre-release kernel pulled out of CVS in March, now I'm running Release 1.0.1 (the 2.4.5 kernel). I've *never* had an XFS related issue (knock wood), and it saved my butt when the SCSI controller the system disk was on decided it didn't like parity anymore. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Aug 23 08:11:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NFBWk28869 for linux-xfs-outgoing; Thu, 23 Aug 2001 08:11:32 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NFBSd28850 for ; Thu, 23 Aug 2001 08:11:28 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id RAA27420; Thu, 23 Aug 2001 17:11:26 +0200 (CEST) Message-Id: <4.3.2.7.2.20010823170101.033dd450@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Aug 2001 17:10:50 +0200 To: Thomas Kirk From: Seth Mos Subject: Re: productionserver Cc: Linux XFS Mailing List In-Reply-To: <20010823164506.A9758@mmstreaming.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:45 23-8-2001 +0200, you wrote: >Hey there listmembers > >Im looking into building a streaming media storage server in a >production enviroment. The server has to be available 24/7 preferable >;-). We are using debian as our prefered OS and as such im gonna us >this to build the storage server. The diskarray are gonna be shared >via CIFS and optional NFS and now the question is what fs would i >choose for this system. Ive been lurkeing around on the listarchives >for a while and reading almost all the mails regarding XFS. The >question is : Is XFS in its current state ready for production >enviroments and yes i read the FAQ but it would be nice with some real >world experince from other "sysadmins". I would be very gratefull for >any help this list could come up with. XFS is nice for larger file sizes and also seems to do reasonably well when using large databases. I am currently testing Progress 9 Databases (6GB of them) on a Dell Optiplex machine which now already is outperforming our production server which has twice the processor power and a scsi Raid array. Server: Workstation: Dual PII 400 PIII 450 512MB ram 256MB ram 50GB raid5 7200RPM scsi 40GB 7200RPM IDE NCR MP-RAS SVR4 Veritas FS RedHat 7.1 with XFS A new real server machine will be forthcoming soon which will make a decent server vs server comparison. Between a NCR Unix variant with Veritas FS and a RedHat 7.1 look-a-like with XFS. My manager is impressed :-) 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 Aug 23 08:19:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NFJDn29222 for linux-xfs-outgoing; Thu, 23 Aug 2001 08:19:13 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NFJ8d29202 for ; Thu, 23 Aug 2001 08:19:08 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 837CAC001D0 for ; Thu, 23 Aug 2001 23:19:13 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 1F401C00FAE for ; Thu, 23 Aug 2001 23:19:12 +0800 (PHT) Date: Thu, 23 Aug 2001 23:19:12 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: productionserver In-Reply-To: <20010823164506.A9758@mmstreaming.dk> 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 Thu, 23 Aug 2001 at 16:45, Thomas Kirk wrote: > Im looking into building a streaming media storage server in a > production enviroment. The server has to be available 24/7 preferable > ;-). Just so you know, I haven't set up a streaming media storage server, although my data server has been running for quite awhile now 24x7 with the only gotcha being an issue with (it seems) VIA and the Linux kernels before 2.4.9 and system lockups when a drive in my RAID5 system on a 3ware controller conked out. > We are using debian as our prefered OS and as such im gonna us this to > build the storage server. I also use Debian GNU/Linux and I believe so do a number of XFS developers. I'm very happy with it (Debian) and just so you know the cmd tree of XFS contains build scripts for the various packages so you can have the latest XFS programs in properly Debianized packages. You can also get these via the unstable tree, of course. Also you may want to note that to get the 2.4 kernels working properly on Debian you'll need at least Woody, I think. Or maybe the packages by bunk (?) that are in his personal apt source. I'm fairly sync'd with sid (unstable) and despite the conservative label, this system is running 24x7 under decent load with no problems at all. :) > The diskarray are gonna be shared via CIFS and optional NFS and now > the question is what fs would i choose for this system. Assuming you don't intend to run FreeBSD or some other flavor of UNIX (it seems Linux is now considered a UNIX despite the fact it mushroomed out from nowhere and is a complete code rewrite), and assuming you don't want to wait forever for an fsck to finish then I'd say go XFS. Why? Because ReiserFS, while also a good journalling filesystem for Linux, is not ready for primetime when it comes to inode-dependent subsystems like NFS. Benchmarks also show that XFS is superior to ReiserFS for large files (XFS starts "winning" when files hit 10000 bytes in size as per the Namesys mongo.pl benchmarks) that don't get deleted en masse on a regular basis. :) Samba 2.2.1a and XFS perform great as a team. I haven't fully explored ACLs yet, and ran into some issues that are more Samba-related than XFS-related, but otherwise, I'm happy. With the new kernel oplocks in Samba, you can share the same files with NFS and shouldn't run into any locking issues, although I haven't stress tested a system with both being accessed with idential loads concurrently. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 23 08:47:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NFlYs29915 for linux-xfs-outgoing; Thu, 23 Aug 2001 08:47:34 -0700 Received: from mhub-c2.tc.umn.edu (mhub-c2.tc.umn.edu [160.94.128.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NFlPd29889 for ; Thu, 23 Aug 2001 08:47:26 -0700 Received: from garnet.tc.umn.edu by mhub-c2.tc.umn.edu with ESMTP; Thu, 23 Aug 2001 10:44:09 -0500 Date: Thu, 23 Aug 2001 10:47:24 -0500 (CDT) From: Grant Erickson X-Sender: erick205@garnet.tc.umn.edu To: linux-kernel@vger.kernel.org, linuxppc-embedded@lists.linuxppc.org cc: linux-xfs@oss.sgi.com Subject: Root Aliases & Lock-ups on Mount w/ Initrd (was Re: initrd: couldn'tumount) Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been following the thread between Andreas Haumer, Daniel Wagner, and Alan Cox about not being able to unmount an initrd volume for the past week or so as I've recently run into two, somewhat related problems, which I am unable to explain. 1) The 'chroot' command fails with a message on the console about busy inodes and d_count=9: cardmgr[13]: executing: './ide start hda' cardmgr[13]: exiting hda: hda1 hda2 Start mounting filesystem: ide0(3,1) Starting XFS recovery on filesystem: ide0(3,1) (dev: 3/1) Ending XFS recovery on filesystem: ide0(3,1) (dev: 3/1) VFS: busy inodes on changed media. VFS: Mounted root (xfs filesystem). change_root: old root has d_count=9 Freeing unused kernel memory: 60k init 4k openfirmware ... Later, when I try to force unmount the initrd and call 'blockdev --flushbufs /dev/ram0' in rc.sysinit, it fails with a message about busy buffers: ... umount'ing initrd BLKFLSBUF: Device or resource busy INIT: Entering runlevel: 3 The system is coming up. ... When the system is finally "up" I end up with two /initrd mount points, one on top the other: # cat /proc/mounts /dev/root /initrd/initrd ext2 rw 0 0 /dev/root.old /initrd xfs rw,noatime 0 0 proc /initrd/proc proc rw 0 0 /dev/root / xfs rw,noatime 0 0 /proc /proc proc rw 0 0 none /dev/pts devpts rw 0 0 The mount /initrd is the same as / (ls -i bears this out) and /initrd/initrd is the initial RAM disk. When I get the d_count=9 message and run fuser, the only processes running are those I'd expect--kernel threads and linuxrc (which should be disassociated with any files): fuser -mv /initrd USER PID ACCESS COMMAND /initrd 0 1 .rc.. swapper 0 2 .rc.. keventd 0 3 .rc.. kswapd 0 4 .rc.. kreclaimd 0 5 .rc.. bdflush 0 6 .rc.. kupdate 0 7 .rc.. pagebuf_daemon 0 8 fr.e. linuxrc 0 24 fr.e. sh 0 kernel mount /proc This behavior happens regardless of whether or not the file system on the SANDisk is xfs or ext2. I suspect there must be something wrong in either the way I've written linuxrc or there's something awry in fs/super.c or fs/block_dev.c. Has anyone else tried this configuration successfully? Any insight? 2) The second issue I notice is that when the root file system is XFS, 1 time out of 20, the sytem freezes shortly after mounting: ... Ending XFS recovery on filesystem: ide0(3,1) (dev: 3/1) [ Hang ] It hangs regardless of whether or not it does recovery. When I run ext2 as the root file system, 9 times out of 10, the system freezes shortly after mounting. Problem here might well be pivot_root rather than mount. Anyone seen similar such hangs? The goal: - Launch an initrd to allow switching the root file system over to an XFS volume on the SanDisk device The setup: - TI PCI 1420 CardBus controller - SanDisk SDCFB-128, ATA DISK drive - Monta Vista Linux 2.4.2-mvista_010329 * XFS 1.0.1 patches (yes, I realize that these should have been applied to 2.4.5; however, save a few files, they merged well onto 2.4.2) - PowerPC 405GP Revision E - pcmcia-cs 3.1.27 The linuxrc: PATH=/bin:/usr/bin:/sbin:/usr/sbin mount -t proc /proc /proc if [ -f /etc/pcmcia.conf ] ; then . /etc/pcmcia.conf fi PC=/lib/modules/default/pcmcia insmod $PC/pcmcia_core.o $CORE_OPTS insmod $PC/$PCIC.o $PCIC_OPTS insmod $PC/ds.o cardmgr $V -q -o -s /var/run/stab -p /tmp/cardmgr.pid umount /proc mount -t xfs -o noatime dev/hda1 mnt cd mnt pivot_root . initrd exec chroot . sh -c 'bin/mount -t proc proc proc; echo "0x03010000" > \ proc/sys/kernel/real-root-dev' < dev/console > dev/console 2>&1 Any nudges in the right direction to a root cause would be greatly appreciated. Regards, Grant -- Grant Erickson University of Minnesota Alumni o mail:erick205@umn.edu 1996 BSEE o http://www.umn.edu/~erick205 1998 MSEE From owner-linux-xfs@oss.sgi.com Thu Aug 23 08:48:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NFmoO30041 for linux-xfs-outgoing; Thu, 23 Aug 2001 08:48:50 -0700 Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NFmld30022 for ; Thu, 23 Aug 2001 08:48:48 -0700 Received: from mmstreaming.dk (cpe.atm2-0-107249.arcnxx9.customer.tele.dk [62.242.148.83]) by pasmtp.tele.dk (Postfix) with ESMTP id 6A259B572; Thu, 23 Aug 2001 17:48:45 +0200 (CEST) Received: by mmstreaming.dk (Postfix, from userid 501) id 25745ADB9; Thu, 23 Aug 2001 17:48:41 +0200 (CEST) Date: Thu, 23 Aug 2001 17:48:41 +0200 From: Thomas Kirk To: Seth Mos Cc: Linux XFS Mailing List Subject: Re: productionserver Message-ID: <20010823174840.C9758@mmstreaming.dk> References: <20010823164506.A9758@mmstreaming.dk> <4.3.2.7.2.20010823170101.033dd450@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010823170101.033dd450@pop.xs4all.nl>; from knuffie@xs4all.nl on Thu, Aug 23, 2001 at 05:10:50PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 23, 2001 at 05:10:50PM +0200, Seth Mos wrote: > XFS is nice for larger file sizes and also seems to do reasonably well when > using large databases. Our HW diskarray are gonna be aprox 500gb and we will run raid5 on top of that.Any considerations i should do if deploying XFS for the server? BTW i seem to get 2 copies of all the mails from this list? -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas@arkena.com Http://www.arkena.com "World domination. Fast" (By Linus Torvalds) From owner-linux-xfs@oss.sgi.com Thu Aug 23 09:01:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NG13030549 for linux-xfs-outgoing; Thu, 23 Aug 2001 09:01:03 -0700 Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NG0wd30520 for ; Thu, 23 Aug 2001 09:00:58 -0700 Received: from mmstreaming.dk (cpe.atm2-0-107249.arcnxx9.customer.tele.dk [62.242.148.83]) by pasmtp.tele.dk (Postfix) with ESMTP id 49E3AB4E1; Thu, 23 Aug 2001 18:00:56 +0200 (CEST) Received: by mmstreaming.dk (Postfix, from userid 501) id B33CCADB9; Thu, 23 Aug 2001 18:00:52 +0200 (CEST) Date: Thu, 23 Aug 2001 18:00:52 +0200 From: Thomas Kirk To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: productionserver Message-ID: <20010823180052.D9758@mmstreaming.dk> References: <20010823164506.A9758@mmstreaming.dk> 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 Thu, Aug 23, 2001 at 11:19:12PM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Aug 23, 2001 at 11:19:12PM +0800, Federico Sevilla III wrote: > Just so you know, I haven't set up a streaming media storage server, > although my data server has been running for quite awhile now 24x7 with > the only gotcha being an issue with (it seems) VIA and the Linux kernels > before 2.4.9 and system lockups when a drive in my RAID5 system on a 3ware > controller conked out. So you are running kernel version 2.4.9 on a debian (Sid) box? > > I also use Debian GNU/Linux and I believe so do a number of XFS > developers. I'm very happy with it (Debian) and just so you know the cmd > tree of XFS contains build scripts for the various packages so you can > have the latest XFS programs in properly Debianized packages. You can also > get these via the unstable tree, of course. That sounds very nice indeed ;-) > > Also you may want to note that to get the 2.4 kernels working properly on > Debian you'll need at least Woody, I think. Or maybe the packages by bunk That was what i was planning to use. Woody seems to be pretty stable these days and ive read that it has gone into freeze, which IMHO makes it a good choice for productionenviroments that needs to be stable but still fairly new regarding features. > Assuming you don't intend to run FreeBSD or some other flavor of UNIX (it We are not. Currently we have a NetBSD box as our gateway but thats it. > ReiserFS, while also a good journalling filesystem for Linux, is not ready > for primetime when it comes to inode-dependent subsystems like NFS. I find it strange that ReiserFS has made it into the 2.4.x kernel not being overall ready while XFS did not? Are there any history reason or are they just a coincident? > Benchmarks also show that XFS is superior to ReiserFS for large files (XFS > starts "winning" when files hit 10000 bytes in size as per the Namesys > mongo.pl benchmarks) that don't get deleted en masse on a regular basis. Which is exactly those filesizes or even bigger we are heading for. Are there any online performances test on read/write/delete for XFS? CPU use etc. > Samba 2.2.1a and XFS perform great as a team. I haven't fully explored Samba 2.2.1 on debian (Woody)? Or did you compile it yourself? > locking issues, although I haven't stress tested a system with both being Do you have any stats for read/write for those systems? -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas@arkena.com Http://www.arkena.com >Ever heard of .cshrc? That's a city in Bosnia. Right? (Discussion in comp.os.linux.misc on the intuitiveness of commands.) From owner-linux-xfs@oss.sgi.com Thu Aug 23 09:13:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NGDhH30827 for linux-xfs-outgoing; Thu, 23 Aug 2001 09:13:43 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NGDcd30807 for ; Thu, 23 Aug 2001 09:13:38 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3B30FC00FBD for ; Fri, 24 Aug 2001 00:13:43 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id C89E8C00FAE for ; Fri, 24 Aug 2001 00:13:41 +0800 (PHT) Date: Fri, 24 Aug 2001 00:13:41 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: productionserver In-Reply-To: <20010823180052.D9758@mmstreaming.dk> 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 Thu, 23 Aug 2001 at 18:00, Thomas Kirk wrote: > So you are running kernel version 2.4.9 on a debian (Sid) box? Yup yup yup! Latest CVS copy, and it's doing very very well. :) > That was what i was planning to use. Woody seems to be pretty stable > these days and ive read that it has gone into freeze, which IMHO makes > it a good choice for productionenviroments that needs to be stable but > still fairly new regarding features. I agree. Sid might be a little bit on the adventurous side for a production server (don't look at me, I'm a crazy nut indeed). > I find it strange that ReiserFS has made it into the 2.4.x kernel not > being overall ready while XFS did not? Are there any history reason or > are they just a coincident? I wasn't aware of the XFS project until Release 1.0 was announced, and this was already using a 2.4 kernel. I was using ReiserFS with the 2.2 kernels, though, and the team of Hans was really pushing forward to get ReiserFS into the 2.4 kernel. It got there 2.4.1, with the experimental flag. Perhaps the XFS team will know more about why XFS didn't make it to 2.4. Maybe didn't make it to the freeze? > Which is exactly those filesizes or even bigger we are heading for. > Are there any online performances test on read/write/delete for XFS? > CPU use etc. You can check out the tests done by the ReiserFS team. They're normally in but now I'm noticing erratic behavior with their server. Very untimely: I'm preparing for a talk on filesystems. Hahaha! :) > Samba 2.2.1 on debian (Woody)? Or did you compile it yourself? Samba 2.2.1a is on Sid but I compiled it myself to enable ACLs that use the XFS libraries. :) > Do you have any stats for read/write for those systems? Not on mine I don't, and because of certain Windows limits you can't max out Samba unless you do concurrent operations from multiple clients. I can get wire speed using Samba, FTP or NFS with a Linux client, though. Perhaps I could max my system out by enabling my second network port and trying ifenslave? :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 23 09:40:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NGeUx31205 for linux-xfs-outgoing; Thu, 23 Aug 2001 09:40:30 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NGePd31186 for ; Thu, 23 Aug 2001 09:40:25 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 6DEBAC001D0 for ; Fri, 24 Aug 2001 00:40:29 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0838DC00FAE for ; Fri, 24 Aug 2001 00:40:28 +0800 (PHT) Date: Fri, 24 Aug 2001 00:40:28 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: productionserver In-Reply-To: <20010823174840.C9758@mmstreaming.dk> 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 Thu, 23 Aug 2001 at 17:48, Thomas Kirk wrote: > Our HW diskarray are gonna be aprox 500gb and we will run raid5 on top > of that.Any considerations i should do if deploying XFS for the > server? If your system will be very busy you may benefit from some optimization flags that Steve Lord recommended awhile back. For mkfs.xfs you may want to set "-l size=32768b" which means that the logfile will be 32768 blocks big, which AFAIK is the maximum for the internal log. Alternatively mkfs.xfs will figure out an "optimal" default based on the size of the filesystem to be. For mounting check out the FAQ entry "What mountoptions does XFS have?". :) > BTW i seem to get 2 copies of all the mails from this list? The list doesn't adjust the reply-to, so by default replies go to the sender only. So most list members reply to all instead of just replying to the list. I prefer just sending to the list so I manually change "To" to just point to the list address. Why the list server isn't configured to make reply-to the list address is beyond me, but that's none of my business so I go one with mine. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 23 09:44:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NGiRk31346 for linux-xfs-outgoing; Thu, 23 Aug 2001 09:44:27 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NGiOd31327 for ; Thu, 23 Aug 2001 09:44:24 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 4BC78C00FBD for ; Fri, 24 Aug 2001 00:44:29 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id D5574C00FAE for ; Fri, 24 Aug 2001 00:44:27 +0800 (PHT) Date: Fri, 24 Aug 2001 00:44:27 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Slides for a talk I will be making 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 everyone, I will be making a short (30 minutes inclusive of Q&A) talk to the local Linux community during the 10th anniversary celebrations on Saturday. My talk is entitled "An Introduction to Advanced Filesystems for Linux", but is more focused on ReiserFS and XFS, with a little bit on ext3 and even less on JFS as I have no experience with these two (none yet, with XFS doing great I am having difficulty finding the motivation to try them out). I have put an exported (from StarImpress) copy of my simple slides up in . It's working except for one table that's broken for some reason. I'm putting this up so that those of you interested may look at it. Hopefully I do not have any grave mistakes. Feedback would be great. I do not know if Brian Smith is still part of the list. If you (Brian) are, I'd like to thank you very much. Your presentation on a similar topic was very very helpful to me in preparing mine. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 23 10:10:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NHAxt31848 for linux-xfs-outgoing; Thu, 23 Aug 2001 10:10:59 -0700 Received: from citadel.oehansen.pp.se (gw.hby.thalamus.se [212.31.160.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NHAsd31827 for ; Thu, 23 Aug 2001 10:10:55 -0700 Received: from there (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f7NJ70l01399 for ; Thu, 23 Aug 2001 21:07:01 +0200 Message-Id: <200108231907.f7NJ70l01399@citadel.oehansen.pp.se> Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se Organization: Private To: linux-xfs@oss.sgi.com Subject: 911 - Rescue! Date: Thu, 23 Aug 2001 21:07:00 +0200 X-Mailer: KMail [version 1.3.1] X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1; Thu, 23 Aug 2001 10:30:11 -0700 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 f7NHZO830590 for ; Thu, 23 Aug 2001 10:35:24 -0700 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 MAA2794729; Thu, 23 Aug 2001 12:28:49 -0500 (CDT) Received: from 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 MAA46927; Thu, 23 Aug 2001 12:28:48 -0500 (CDT) Message-ID: <3B853D25.C02E5B22@sgi.com> Date: Thu, 23 Aug 2001 12:28:05 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: oe.hansen@gamma.telenordia.se CC: linux-xfs@oss.sgi.com Subject: Re: 911 - Rescue! References: <200108231907.f7NJ70l01399@citadel.oehansen.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Orn E. Hansen" wrote: > Now, here is when I really needed to be able to call 911 ... so I went onto > oss.sgi.com and found release 1.0.1... unfortunately I don't have CD burner > so I looked for boot disk and driver disk... and I found it, so I thought my > days were now made easy. In with the boot disk, 'linux dd' added a driver > disk... in with the drivers... CTRL-ALT-F1 to get a console, ALT-F2 for a new > console, and modprobe xfs ... oobs, no go. So, I looked over the list of > drivers ... but there was no xfs driver there. With all of the other things that need to be on the boot & driver disks, there wasn't room for the xfs modules - it's in the second stage image. One thing you might be able to do is set up a network install, either locally, or pointing out to the web? I think there is a full install tree on ftp.thebarn.com. It might also be possible to add filesystem drivers to a new driver disk, but I'm not certain - the driver disk only handles certain types of drivers, and filesystems may not be an option... There are also some people who have created root/boot XFS disks, I believe - check either the News link or the mailing list archives. Good luck! -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 Aug 23 10:35:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NHZHd00623 for linux-xfs-outgoing; Thu, 23 Aug 2001 10:35:17 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NHZDd00604 for ; Thu, 23 Aug 2001 10:35:13 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id TAA07398; Thu, 23 Aug 2001 19:35:11 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id TAA13772; Thu, 23 Aug 2001 19:35:11 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 28DBE57306; Thu, 23 Aug 2001 19:34:25 +0200 (CEST) Received: from ch.sauter-bc.com (ppp01.cad.sba [10.1.249.1]) by mobile.sauter-bc.com (Postfix) with ESMTP id B873525835; Thu, 23 Aug 2001 19:34:23 +0200 (CEST) Message-ID: <3B853EDA.B240CAB8@ch.sauter-bc.com> Date: Thu, 23 Aug 2001 19:35:22 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: oe.hansen@gamma.telenordia.se Cc: linux-xfs@oss.sgi.com Subject: Re: 911 - Rescue! References: <200108231907.f7NJ70l01399@citadel.oehansen.pp.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f7NHZEd00605 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Orn E. Hansen" schrieb: > I was in neat position the other day, that I noticed a upgrade for my MB > and installed it. The consequences was, that Windows 2K crashed ... and > destroyed the main drive partition, which it resided on. This called for > reinstallation of Windows, a new boot sector and all the usual stuff. > Annoying, but it wasn't a problem until I needed to boot my Linux system, > with the root an XFS file system. > > Now, here is when I really needed to be able to call 911 ... so I went onto > oss.sgi.com and found release 1.0.1... unfortunately I don't have CD burner > so I looked for boot disk and driver disk... and I found it, so I thought my > days were now made easy. In with the boot disk, 'linux dd' added a driver > disk... in with the drivers... CTRL-ALT-F1 to get a console, ALT-F2 for a new > console, and modprobe xfs ... oobs, no go. So, I looked over the list of > drivers ... but there was no xfs driver there. I didn't try this but usually you can use the bootdisks as rescue disks using 'linux rescue' at the boot prompt. You don't need a xfs kernel module since xfs is included in the kernel. > > > The above happens a lot, people's drives get crashed and a new setup is > needed, etc. And 911 rescues is needed... and the availability of CD roms > (like here) isn't that great... isn't it possible to fit xfs driver on the > driver disk? Why don't you create a bootdisk for your system? It's easy, you just have to over format the disks. I have built RPMS for that reason. Find them at http://home.datacomm.ch/simix/XFS/ . You can find instructions to use it in the archives of this list. -Simon > > > Orn From owner-linux-xfs@oss.sgi.com Thu Aug 23 11:49:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NInLj01862 for linux-xfs-outgoing; Thu, 23 Aug 2001 11:49:21 -0700 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NInHd01843 for ; Thu, 23 Aug 2001 11:49:17 -0700 Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85]) by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f7NInFMD008515 for ; Thu, 23 Aug 2001 11:49:15 -0700 Date: Thu, 23 Aug 2001 11:49:15 -0700 (PDT) From: Walter Marchuk To: linux-xfs@oss.sgi.com Subject: XFS/DISK crashing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am running Linux 2.4.5 with xfs 1.0.1, the disk with XFS is a 150GB Raid. For some reason the raid keeps crashing while I am trying to copy files, it always crashes after a certain period of time of copying files to the raid. Please help. Here is the error message: Aug 22 09:46:06 marconi kernel: SCSI disk error : host 0 channel 0 id 2 lun 0 return code = 8000002 Aug 22 09:46:06 marconi kernel: Info fld=0x0, Current sd08:21: sns = f0 b Aug 22 09:46:06 marconi kernel: ASC=47 ASCQ= 0 Aug 22 09:46:06 marconi kernel: Raw sense data:0xf0 0x00 0x0b 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x47 0x00 0x00 0x00 0x00 0x00 Aug 22 09:46:06 marconi kernel: I/O error: dev 08:21, sector 123453963 Aug 22 09:46:06 marconi kernel: SCSI disk error : host 0 channel 0 id 2 lun 0 return code = 8000002 Aug 22 09:46:06 marconi kernel: Info fld=0x0, Current sd08:21: sns = f0 b Aug 22 09:46:06 marconi kernel: ASC=47 ASCQ= 0 Aug 22 09:46:06 marconi kernel: Raw sense data:0xf0 0x00 0x0b 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x47 0x00 0x00 0x00 0x00 0x00 Aug 22 09:46:06 marconi kernel: I/O error: dev 08:21, sector 123453970 Aug 22 09:46:06 marconi kernel: xfs_force_shutdown(sd(8,33),0x2) called from line 942 of file xfs_log.c. Return address = 0xc01cf5d4 Aug 22 09:46:06 marconi kernel: I/O Error Detected. Shutting down filesystem: sd(8,33) Aug 22 09:46:06 marconi kernel: Please umount the filesystem, and rectify the problem(s) Thank You. ***************************** Walter Marchuk Senior Computer Specialist University of Washington Electrical Engineering Room: 307g 206-221-5421 marchuk@ee.washington.edu ***************************** From owner-linux-xfs@oss.sgi.com Thu Aug 23 12:01:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NJ1Eb02164 for linux-xfs-outgoing; Thu, 23 Aug 2001 12:01:14 -0700 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 f7NJ1Bd02144 for ; Thu, 23 Aug 2001 12:01:11 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7NJ6O805587 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 23 Aug 2001 12:06:24 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA431795 for ; Thu, 23 Aug 2001 21:01:03 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2795148; Thu, 23 Aug 2001 13:59:37 -0500 (CDT) Received: from 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 NAA19382; Thu, 23 Aug 2001 13:59:37 -0500 (CDT) Message-ID: <3B85526D.D14F1C9E@sgi.com> Date: Thu, 23 Aug 2001 13:58:53 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Walter Marchuk CC: linux-xfs@oss.sgi.com Subject: Re: XFS/DISK crashing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Walter Marchuk wrote: > For some reason the raid keeps crashing while I am trying to copy files, > it always crashes after a certain period of time of copying files to the > raid. Hi Walter - > Aug 22 09:46:06 marconi kernel: SCSI disk error : host 0 channel 0 id 2 > lun 0 return code = 8000002 Looks to me like a hardware problem...? > Aug 22 09:46:06 marconi kernel: xfs_force_shutdown(sd(8,33),0x2) called > from line 942 of file xfs_log.c. Return address = 0xc01cf5d4 > Aug 22 09:46:06 marconi kernel: I/O Error Detected. Shutting down > filesystem: sd(8,33) > Aug 22 09:46:06 marconi kernel: Please umount the filesystem, and rectify > the problem(s) So the XFS filesystem shuts down before things get too bad. I'd look for what is causing the RAID errors, XFS is just responding to problems that it inherited from the RAID, I believe. -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 Aug 23 12:07:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NJ7gP02364 for linux-xfs-outgoing; Thu, 23 Aug 2001 12:07:42 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NJ7cd02345 for ; Thu, 23 Aug 2001 12:07:39 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f7NJ76s03419; Thu, 23 Aug 2001 15:07:10 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 23 Aug 2001 15:07:06 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Walter Marchuk cc: Subject: Re: XFS/DISK crashing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 23 Aug 2001 at 11:49am, Walter Marchuk wrote > I am running Linux 2.4.5 with xfs 1.0.1, the disk with XFS is a 150GB > Raid. A hardware RAID? What type of controller? What type of SCSI controller? > Aug 22 09:46:06 marconi kernel: SCSI disk error : host 0 channel 0 id 2 > lun 0 return code = 8000002 > Aug 22 09:46:06 marconi kernel: Info fld=0x0, Current sd08:21: sns = f0 b > Aug 22 09:46:06 marconi kernel: ASC=47 ASCQ= 0 > Aug 22 09:46:06 marconi kernel: Raw sense data:0xf0 0x00 0x0b 0x00 0x00 > 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x47 0x00 0x00 0x00 0x00 0x00 > Aug 22 09:46:06 marconi kernel: I/O error: dev 08:21, sector 123453963 These look like generic SCSI errors. How sure are you of the hardware -- the RAID itself, the SCSI controller, etc? Have you done the usual -- checked cables, termination, termination (yes, again ;), that you used the proper color goat... > Aug 22 09:46:06 marconi kernel: xfs_force_shutdown(sd(8,33),0x2) called > from line 942 of file xfs_log.c. Return address = 0xc01cf5d4 > Aug 22 09:46:06 marconi kernel: I/O Error Detected. Shutting down > filesystem: sd(8,33) > Aug 22 09:46:06 marconi kernel: Please umount the filesystem, and rectify > the problem(s) This is XFS' standard response when it detects disk errors, in order to prevent (further) corruption. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Aug 23 12:25:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NJP8Y02820 for linux-xfs-outgoing; Thu, 23 Aug 2001 12:25:08 -0700 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NJP5d02801 for ; Thu, 23 Aug 2001 12:25:05 -0700 Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85]) by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f7NJP4MD018764; Thu, 23 Aug 2001 12:25:04 -0700 Date: Thu, 23 Aug 2001 12:25:04 -0700 (PDT) From: Walter Marchuk To: Joshua Baker-LePain cc: linux-xfs@oss.sgi.com Subject: Re: XFS/DISK crashing 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 SCSI storage controller: Adaptec 7892P (rev 02) I never had these crashing problems with ext2. My question was if this error is xfs related. Walter. On Thu, 23 Aug 2001, Joshua Baker-LePain wrote: > On Thu, 23 Aug 2001 at 11:49am, Walter Marchuk wrote > > > I am running Linux 2.4.5 with xfs 1.0.1, the disk with XFS is a 150GB > > Raid. > > A hardware RAID? What type of controller? What type of SCSI controller? > > > Aug 22 09:46:06 marconi kernel: SCSI disk error : host 0 channel 0 id 2 > > lun 0 return code = 8000002 > > Aug 22 09:46:06 marconi kernel: Info fld=0x0, Current sd08:21: sns = f0 b > > Aug 22 09:46:06 marconi kernel: ASC=47 ASCQ= 0 > > Aug 22 09:46:06 marconi kernel: Raw sense data:0xf0 0x00 0x0b 0x00 0x00 > > 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x47 0x00 0x00 0x00 0x00 0x00 > > Aug 22 09:46:06 marconi kernel: I/O error: dev 08:21, sector 123453963 > > These look like generic SCSI errors. How sure are you of the hardware -- > the RAID itself, the SCSI controller, etc? Have you done the usual -- > checked cables, termination, termination (yes, again ;), that you used the > proper color goat... > > > Aug 22 09:46:06 marconi kernel: xfs_force_shutdown(sd(8,33),0x2) called > > from line 942 of file xfs_log.c. Return address = 0xc01cf5d4 > > Aug 22 09:46:06 marconi kernel: I/O Error Detected. Shutting down > > filesystem: sd(8,33) > > Aug 22 09:46:06 marconi kernel: Please umount the filesystem, and rectify > > the problem(s) > > This is XFS' standard response when it detects disk errors, in order to > prevent (further) corruption. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University > From owner-linux-xfs@oss.sgi.com Thu Aug 23 12:53:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NJrGa03445 for linux-xfs-outgoing; Thu, 23 Aug 2001 12:53:16 -0700 Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NJrCd03426 for ; Thu, 23 Aug 2001 12:53:12 -0700 Received: from dhcp6 (static031-81-151-24.nm01-c3.cpe.charter-ne.com [24.151.81.31] (may be forged)) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id MAA20286; Thu, 23 Aug 2001 12:52:54 -0700 (PDT) Message-ID: <007b01c12c0c$fdd97080$0600a8c0@dhcp6> Reply-To: "Sean P. Elble" From: "Sean P. Elble" To: "Thomas Kirk" Cc: References: <20010823164506.A9758@mmstreaming.dk> Subject: Re: productionserver Date: Thu, 23 Aug 2001 15:51:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I certainly think so; XFS runs on my Compaq/Red Hat 6.1 server with a 30 GB, 7200 RPM IDE drive. The server is a file/web/streaming media server; it runs just fine. Fast as hell with Samba, and the ACL support is great. I use a CVS version from a while back, and that is stable as hell. Never crashed, as a matter of fact, no problems whatsoever. -------------------------------------------- Sean P. Elble Editor, Writer, Co-Webmaster MaximumLinux.org http://www.maximumlinux.org/ elbles@maximumlinux.org -------------------------------------------- ----- Original Message ----- From: "Thomas Kirk" To: Sent: Thursday, August 23, 2001 10:45 AM Subject: productionserver > Hey there listmembers > > Im looking into building a streaming media storage server in a > production enviroment. The server has to be available 24/7 preferable > ;-). We are using debian as our prefered OS and as such im gonna us > this to build the storage server. The diskarray are gonna be shared > via CIFS and optional NFS and now the question is what fs would i > choose for this system. Ive been lurkeing around on the listarchives > for a while and reading almost all the mails regarding XFS. The > question is : Is XFS in its current state ready for production > enviroments and yes i read the FAQ but it would be nice with some real > world experince from other "sysadmins". I would be very gratefull for > any help this list could come up with. > > Thanks in advance > > -- > Venlig hilsen/Kind regards > Thomas Kirk > ARKENA > thomas@arkena.com > Http://www.arkena.com > > > "And the next time you consider complaining that running Lucid Emacs > 19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to > get the background colors right, you'll know who to thank." > (By Matt Welsh) From owner-linux-xfs@oss.sgi.com Thu Aug 23 13:15:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NKFYl04082 for linux-xfs-outgoing; Thu, 23 Aug 2001 13:15:34 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NKFUd04063 for ; Thu, 23 Aug 2001 13:15:30 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA17147; Thu, 23 Aug 2001 22:15:21 +0200 (CEST) Message-Id: <4.3.2.7.2.20010823221355.0328f4a8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Aug 2001 22:14:43 +0200 To: Eric Sandeen , oe.hansen@gamma.telenordia.se From: Seth Mos Subject: Re: 911 - Rescue! Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B853D25.C02E5B22@sgi.com> References: <200108231907.f7NJ70l01399@citadel.oehansen.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:28 23-8-2001 -0500, Eric Sandeen wrote: >"Orn E. Hansen" wrote: > > > Now, here is when I really needed to be able to call 911 ... so I > went onto > > oss.sgi.com and found release 1.0.1... unfortunately I don't have CD burner > > so I looked for boot disk and driver disk... and I found it, so I > thought my > > days were now made easy. In with the boot disk, 'linux dd' added a driver > > disk... in with the drivers... CTRL-ALT-F1 to get a console, ALT-F2 for > a new > > console, and modprobe xfs ... oobs, no go. So, I looked over the list of > > drivers ... but there was no xfs driver there. > >With all of the other things that need to be on the boot & driver disks, >there wasn't room for the xfs modules - it's in the second stage image. >One thing you might be able to do is set up a network install, either >locally, or pointing out to the web? I think there is a full install >tree on ftp.thebarn.com. > >It might also be possible to add filesystem drivers to a new driver >disk, but I'm not certain - the driver disk only handles certain types >of drivers, and filesystems may not be an option... > >There are also some people who have created root/boot XFS disks, I >believe - check either the News link or the mailing list archives. It's in the faq. Cheers ps Reading with a cracked LCD display sucks. -- 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 Aug 23 13:31:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NKVVq04521 for linux-xfs-outgoing; Thu, 23 Aug 2001 13:31:31 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NKVSd04502 for ; Thu, 23 Aug 2001 13:31:28 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA29362; Thu, 23 Aug 2001 22:31:25 +0200 (CEST) Message-Id: <4.3.2.7.2.20010823222414.03e237e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Aug 2001 22:30:46 +0200 To: Thomas Kirk From: Seth Mos Subject: Re: productionserver Cc: Linux XFS Mailing List In-Reply-To: <20010823174840.C9758@mmstreaming.dk> References: <4.3.2.7.2.20010823170101.033dd450@pop.xs4all.nl> <20010823164506.A9758@mmstreaming.dk> <4.3.2.7.2.20010823170101.033dd450@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 17:48 23-8-2001 +0200, Thomas Kirk wrote: >On Thu, Aug 23, 2001 at 05:10:50PM +0200, Seth Mos wrote: > > > XFS is nice for larger file sizes and also seems to do reasonably well > when > > using large databases. > >Our HW diskarray are gonna be aprox 500gb and we will run raid5 on top >of that.Any considerations i should do if deploying XFS for the server? Not really though, just use it. Make sure to compile with kgcc on redhat 7.1 or at least gcc-2.95.4 under debian and search out a gcc 2.91.66 if you can. That would be the first thing we ask when you have problems. Don't use raid 5 if database performance is worth something to you. >BTW i seem to get 2 copies of all the mails from this list? Because I use reply to all. Not everyone is on the list. You can post to the list without subscribing. 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 Aug 23 13:32:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NKWfs04685 for linux-xfs-outgoing; Thu, 23 Aug 2001 13:32:41 -0700 Received: from mail.spylog.com (mail.spylog.com [194.67.35.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NKWad04665 for ; Thu, 23 Aug 2001 13:32:36 -0700 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id AA93B2C1DE for ; Fri, 24 Aug 2001 00:32:30 +0400 (MSD) Received: by an.local (Postfix, from userid 1000) id 4BBC7142B8; Fri, 24 Aug 2001 00:32:30 +0400 (MSD) Date: Fri, 24 Aug 2001 00:32:30 +0400 From: Andrey Nekrasov To: linux-xfs@oss.sgi.com Subject: Re: XFS/DISK crashing Message-ID: <20010824003230.B16812@spylog.ru> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i Organization: SpyLOG ltd. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Walter Marchuk, Once you wrote about "Re: XFS/DISK crashing": > SCSI storage controller: Adaptec 7892P (rev 02) > > I never had these crashing problems with ext2. > > My question was if this error is xfs related. No XFS specific prooblem. Restart computer and enter to SCSI BIOS (CTRL+A (?)) on Adaptec SCSI Controller. Make "Verify" on scsi device. Verify process found error on your disk. Make "remap bad block" (your lost 512byte on each 1 sector). Or if your have backup, change disk. > On Thu, 23 Aug 2001, Joshua Baker-LePain wrote: > > > On Thu, 23 Aug 2001 at 11:49am, Walter Marchuk wrote > > > > > I am running Linux 2.4.5 with xfs 1.0.1, the disk with XFS is a 150GB > > > Raid. > > > > A hardware RAID? What type of controller? What type of SCSI controller? > > > > > Aug 22 09:46:06 marconi kernel: SCSI disk error : host 0 channel 0 id 2 > > > lun 0 return code = 8000002 > > > Aug 22 09:46:06 marconi kernel: Info fld=0x0, Current sd08:21: sns = f0 b > > > Aug 22 09:46:06 marconi kernel: ASC=47 ASCQ= 0 > > > Aug 22 09:46:06 marconi kernel: Raw sense data:0xf0 0x00 0x0b 0x00 0x00 > > > 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x47 0x00 0x00 0x00 0x00 0x00 > > > Aug 22 09:46:06 marconi kernel: I/O error: dev 08:21, sector > 123453963 > > > > These look like generic SCSI errors. How sure are you of the hardware -- > > the RAID itself, the SCSI controller, etc? Have you done the usual -- > > checked cables, termination, termination (yes, again ;), that you used the > > proper color goat... > > > > > Aug 22 09:46:06 marconi kernel: xfs_force_shutdown(sd(8,33),0x2) called > > > from line 942 of file xfs_log.c. Return address = 0xc01cf5d4 > > > Aug 22 09:46:06 marconi kernel: I/O Error Detected. Shutting down > > > filesystem: sd(8,33) > > > Aug 22 09:46:06 marconi kernel: Please umount the filesystem, and rectify > > > the problem(s) > > > > This is XFS' standard response when it detects disk errors, in order to > > prevent (further) corruption. > > > > -- > > Joshua Baker-LePain > > Department of Biomedical Engineering > > Duke University > > > -- bye. Andrey Nekrasov, SpyLOG. From owner-linux-xfs@oss.sgi.com Thu Aug 23 13:45:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NKjZT05225 for linux-xfs-outgoing; Thu, 23 Aug 2001 13:45:35 -0700 Received: from codon.com (stampingcentral.com [64.78.130.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NKjXd05206 for ; Thu, 23 Aug 2001 13:45:33 -0700 Received: (qmail 31052 invoked by uid 516); 23 Aug 2001 20:58:16 -0000 Received: from nw@codon.com by helix with qmail-scanner-0.96 (. Clean. Processed in 0.052317 secs); 23 Aug 2001 20:58:16 -0000 Received: from weasel.local.iboats.com (HELO weasel) (64.78.130.80) by codon.com with SMTP; 23 Aug 2001 20:58:16 -0000 Message-ID: <001901c12c13$e29682c0$50824e40@iboats.com> From: "Steve Wolfe" To: "Linux XFS Mailing List" References: <4.3.2.7.2.20010823170101.033dd450@pop.xs4all.nl> <20010823164506.A9758@mmstreaming.dk> <4.3.2.7.2.20010823170101.033dd450@pop.xs4all.nl> <4.3.2.7.2.20010823222414.03e237e0@pop.xs4all.nl> Subject: Re: productionserver Date: Thu, 23 Aug 2001 14:40:22 -0600 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 > Don't use raid 5 if database performance is worth something to you. We use PostgreSQL on a hardware RAID controller, RAID 5. Our system has never had a stability problem in the 1+ year that it's been running, so I turned off fsync(). Between the 64 megs of cache on the controller and a gig of disk cache on the machine, the lights on the drives blink *occasionally*. I don't consider RAID 5 to be a problem at all, at least not in this situation. Our $12,000 machine will beat the $25,000 Alpha that a Compaq rep loaned to us. : ) steve From owner-linux-xfs@oss.sgi.com Thu Aug 23 14:28:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NLSTw06168 for linux-xfs-outgoing; Thu, 23 Aug 2001 14:28:29 -0700 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 f7NLSQd06149 for ; Thu, 23 Aug 2001 14:28:26 -0700 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.5) with ESMTP id f7NLSOC17779 for ; Thu, 23 Aug 2001 17:28:24 -0400 (EDT) Date: Thu, 23 Aug 2001 17:25:36 -0400 (EDT) From: To: Linux XFS Mailing List Subject: xfs version In-Reply-To: <4.3.2.7.2.20010823222414.03e237e0@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 Out of curiousity what is the latest "released" kernel from sgi (or has xfs been incorporated into the official trees now) I'm running the one off of the last update cd (xfs1.0.1 and 2.4.3) but I noticed there are some patches lying around (inaccessible) for 2.4.5.. is 2.4.5 considered the latest stable release? (I ask because i'd like a newer kernel due to some bugs w/ the ethernet card).. are the updates mirrored anywhere as I can't seem to ftp to oss.sgi.com.. -thanks -avi From owner-linux-xfs@oss.sgi.com Thu Aug 23 14:34:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NLYYD06421 for linux-xfs-outgoing; Thu, 23 Aug 2001 14:34:34 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NLYVd06383 for ; Thu, 23 Aug 2001 14:34:31 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA04066 for ; Thu, 23 Aug 2001 14:32:41 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2799661; Thu, 23 Aug 2001 16:31:59 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA01080; Thu, 23 Aug 2001 16:31:59 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7NLVn201248; Thu, 23 Aug 2001 16:31:49 -0500 Message-Id: <200108232131.f7NLVn201248@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: avijit@cs.cornell.edu cc: Linux XFS Mailing List Subject: Re: xfs version In-Reply-To: Message from of "Thu, 23 Aug 2001 17:25:36 EDT." Date: Thu, 23 Aug 2001 16:31:49 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Out of curiousity what is the latest "released" kernel from sgi > (or has xfs been incorporated into the official trees now) I'm running the > one off of the last update cd (xfs1.0.1 and 2.4.3) but I noticed there are > some patches lying around (inaccessible) for 2.4.5.. is 2.4.5 considered > the latest stable release? (I ask because i'd like a newer kernel due to > some bugs w/ the ethernet card).. are the updates mirrored anywhere as I > can't seem to ftp to oss.sgi.com.. > > -thanks > -avi > ncftp ...s/xfs/download/patches > ls MD5SUMS patch-2.4.9-xfs-2001-08-19.bz2 patch-2.4.6-xfs-2001-07-05.bz2 patch-2.4.9-xfs-cvs-2001-08-19.bz2 patch-2.4.7-xfs-2001-07-27.bz2 README patch-2.4.8-xfs-2001-08-15.bz2 ncftp ...s/xfs/download/patches > pwd ftp://oss.sgi.com/projects/xfs/download/patches/ There is a 2.4.9 patch in there, try using 216.32.174.27 as the ip address for the ftp site, it is working for me now. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 23 14:34:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NLYbv06471 for linux-xfs-outgoing; Thu, 23 Aug 2001 14:34:37 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NLYVd06382 for ; Thu, 23 Aug 2001 14:34:31 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07659 for ; Thu, 23 Aug 2001 14:32:41 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2798879; Thu, 23 Aug 2001 16:32:32 -0500 (CDT) Received: from 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 QAA80913; Thu, 23 Aug 2001 16:32:32 -0500 (CDT) Message-ID: <3B857642.983B4F30@sgi.com> Date: Thu, 23 Aug 2001 16:31:46 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: avijit@cs.cornell.edu CC: Linux XFS Mailing List Subject: Re: xfs version References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Avi - The latest "official" version of XFS is 1.0.1, and it's available for either "vanilla" 2.4.5 kernels, or Red Hat's version of 2.4.3, released as an update for Red Hat Linux 7.1. The XFS code is the same in both kernels. How are the patches inaccessible? What's happening with oss.sgi.com? The download pages on oss.sgi.com/projects/xfs/download should list some mirrors for you. -Eric avijit@cs.cornell.edu wrote: > > Out of curiousity what is the latest "released" kernel from sgi > (or has xfs been incorporated into the official trees now) I'm running the > one off of the last update cd (xfs1.0.1 and 2.4.3) but I noticed there are > some patches lying around (inaccessible) for 2.4.5.. is 2.4.5 considered > the latest stable release? (I ask because i'd like a newer kernel due to > some bugs w/ the ethernet card).. are the updates mirrored anywhere as I > can't seem to ftp to oss.sgi.com.. > > -thanks > -avi -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Aug 23 14:35:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NLZub06644 for linux-xfs-outgoing; Thu, 23 Aug 2001 14:35:56 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NLZrd06625 for ; Thu, 23 Aug 2001 14:35:53 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f7NLZMA04064; Thu, 23 Aug 2001 17:35:22 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 23 Aug 2001 17:35:22 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: cc: Linux XFS Mailing List Subject: Re: xfs version In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 23 Aug 2001 at 5:25pm, avijit@CS.Cornell.EDU wrote > Out of curiousity what is the latest "released" kernel from sgi > (or has xfs been incorporated into the official trees now) I'm running the > one off of the last update cd (xfs1.0.1 and 2.4.3) but I noticed there are The 1.0.1 release consisted of two kernels. The 2.4.3 based one is RedHat's 2.4.3-12 kernel (the current one for RedHat 7.1) patched with XFS and tested by SGI. The 2.4.5 based on is a "vanilla" (a.k.a. Linus) kernel patched with XFS and tested by SGI. Those should both be available via oss.sgi.com (go to the XFS homepage and find the download section. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Aug 23 14:40:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NLeAV06810 for linux-xfs-outgoing; Thu, 23 Aug 2001 14:40:10 -0700 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 f7NLe8d06791 for ; Thu, 23 Aug 2001 14:40:08 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7NLjM819707 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 23 Aug 2001 14:45:22 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA431192 for ; Thu, 23 Aug 2001 23:40:01 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2797840; Thu, 23 Aug 2001 16:38:43 -0500 (CDT) Received: from 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 QAA27090; Thu, 23 Aug 2001 16:38:43 -0500 (CDT) Message-ID: <3B8577B6.64B17AAF@sgi.com> Date: Thu, 23 Aug 2001 16:37:58 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: avijit@cs.cornell.edu, Linux XFS Mailing List Subject: Re: xfs version References: <3B857642.983B4F30@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: > > Hi Avi - > > The latest "official" version of XFS is 1.0.1, and it's available for > either "vanilla" 2.4.5 kernels, or Red Hat's version of 2.4.3, released > as an update for Red Hat Linux 7.1. The XFS code is the same in both > kernels. Oh, and as Steve pointed out, there are also development snapshot patches available for later kernels. -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 Aug 23 14:57:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NLvvE07230 for linux-xfs-outgoing; Thu, 23 Aug 2001 14:57:57 -0700 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 f7NLvtd07211 for ; Thu, 23 Aug 2001 14:57:55 -0700 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.5) with ESMTP id f7NLviC22376; Thu, 23 Aug 2001 17:57:44 -0400 (EDT) Date: Thu, 23 Aug 2001 17:54:56 -0400 (EDT) From: To: Steve Lord cc: Linux XFS Mailing List Subject: Re: xfs version In-Reply-To: <200108232131.f7NLVn201248@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 > > > There is a 2.4.9 patch in there, try using 216.32.174.27 as the ip > address for the ftp site, it is working for me now. Okay cool i was getting a refused connection from oss.sgi.com which is now resolving to the above .. i'm not sure what was going on.. thanks much all for the xfs/kernel version info.. ! -avi From owner-linux-xfs@oss.sgi.com Thu Aug 23 15:01:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NM18Z07479 for linux-xfs-outgoing; Thu, 23 Aug 2001 15:01:08 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NM13d07458 for ; Thu, 23 Aug 2001 15:01:03 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA08104; Fri, 24 Aug 2001 00:01:02 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA23012; Fri, 24 Aug 2001 00:01:01 +0200 (CEST) Date: Fri, 24 Aug 2001 00:01:01 +0200 (CEST) From: Seth Mos To: Steve Wolfe cc: Linux XFS Mailing List Subject: Re: productionserver In-Reply-To: <001901c12c13$e29682c0$50824e40@iboats.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 23 Aug 2001, Steve Wolfe wrote: > > Don't use raid 5 if database performance is worth something to you. > > We use PostgreSQL on a hardware RAID controller, RAID 5. Our system has > never had a stability problem in the 1+ year that it's been running, so I > turned off fsync(). Between the 64 megs of cache on the controller and a > gig of disk cache on the machine, the lights on the drives blink > *occasionally*. I don't consider RAID 5 to be a problem at all, at least > not in this situation. Our $12,000 machine will beat the $25,000 Alpha > that a Compaq rep loaned to us. : ) Hmm yes, however our disk lights are lit a lot. A saw my co worker test run a testconversion from guilders to euro in our logistics package which kept the disk lit for over 40 minutes on the testbox. Now this onvolves actually ploughing trough the complete 6GB+ of the databases and changing fields and values. We are talking milions of records that needed to be changed. Afterall this was just a desktop machine but still this is going faster then the now in production machine. The testmachine does not have any raid5 overhead and the production machine does, which is probably the direct reason for the poor performance. If you contact people about Progress/DB2/Oracleand similar beasts you will get similar advice from their tech guru's. We are rather diskbound with our server rather then processor. The new machine will feature a dual 1Ghz PIII with at least 1GB of ram and the raid will be a raid 10 totaling 6 disks with 2 raid0 sets which are mirrored. The disks will be 73GB 10K RPM disks and each set of 3 will be on it's own channel on the raid controller. In case you want to order one, it's a Dell PE 2500 with rackmount kit an 6 73GB disks, UPS, and 3 year support. This brings the price in the Netherlands to about 18.000 Euro (divide by 1.1 for US $). Now this is fairly specific ofcourse but we are in the clothing retail bussines wiht 200+ stores throughout the country and we have a lot of unique items with specific prices for specific stores. etc. etc. You get the idea, there will be about 50 people using this server interactively and a lot of data is inserted automatically. The sales information from all the cash registers, which then triggers the ordering part which automatically creates list for what will need to be resent to ther store, which triggers the finance part which is keeping the scores, which triggers the inventory data so the stores can be checked on an anual basis or whe know what is in it when it is stolen/burned down/damaged/fraud. And you can't find that in the shops. It's a lot of hard work that has been done over the years (7) and we like to please the users with a fast way to bring them through their way. But don't worry. I'll post benchmarks and some other data on my personal websit when we get the machine. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Aug 23 15:05:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NM5BY07657 for linux-xfs-outgoing; Thu, 23 Aug 2001 15:05:11 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NM59d07638 for ; Thu, 23 Aug 2001 15:05:09 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA08745; Fri, 24 Aug 2001 00:05:07 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA23284; Fri, 24 Aug 2001 00:05:07 +0200 (CEST) Date: Fri, 24 Aug 2001 00:05:07 +0200 (CEST) From: Seth Mos To: avijit@CS.Cornell.EDU cc: Linux XFS Mailing List Subject: Re: xfs version In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 23 Aug 2001 avijit@CS.Cornell.EDU wrote: > > Out of curiousity what is the latest "released" kernel from sgi > (or has xfs been incorporated into the official trees now) I'm running the > one off of the last update cd (xfs1.0.1 and 2.4.3) but I noticed there are > some patches lying around (inaccessible) for 2.4.5.. is 2.4.5 considered Yes, use the CVS tree in case of emergency. > the latest stable release? (I ask because i'd like a newer kernel due to > some bugs w/ the ethernet card).. are the updates mirrored anywhere as I > can't seem to ftp to oss.sgi.com.. sunsite.auc.dk IIRC From owner-linux-xfs@oss.sgi.com Thu Aug 23 15:41:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NMfdj02698 for linux-xfs-outgoing; Thu, 23 Aug 2001 15:41:39 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NMfWd02675 for ; Thu, 23 Aug 2001 15:41:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA08385 for ; Thu, 23 Aug 2001 15:41:32 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA12570; Fri, 24 Aug 2001 08:40:12 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA25859; Fri, 24 Aug 2001 08:40:09 +1000 (AEST) Date: Fri, 24 Aug 2001 08:40:08 +1000 From: Nathan Scott To: Robert Carsey Cc: Linux-xfs@oss.sgi.com, Jan Kara Subject: Re: FW: [ linuxquota-Bugs-449992 ] repquota reporting Message-ID: <20010824084008.A324986@wobbly.melbourne.sgi.com> References: <000201c12be3$11f1bbb0$9865fea9@framus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000201c12be3$11f1bbb0$9865fea9@framus>; from rcarsey@monmouth.edu on Thu, Aug 23, 2001 at 10:51:19AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 23, 2001 at 10:51:19AM -0400, Robert Carsey wrote: > I had initially posted this to sourceforge. repquota command only > returns those UIDs which are in /etc/passwd. Feature or bug? My server > ONLY runs > as an nfs server, which means 99% of my UIDs are foreign to the system > and are unresolvable. Of course, when putting a quota on a UID, it does > work fine -- its just not listed in repquota. > > The quota maintainers replied: > This is a feature as on XFS quota utilities have no > possibility to get list of users with quotas and so > utilities just take users from passwd. > > > Is this true? Can we do something about this? I don't remember running > into this on SGI machines... > Yes, this is true. To be 100% accurate, one would say that "repquota [for XFS] returns only those UIDs returned from the getpwent(3) function" - since getpwent will also lookup passwd entries via NIS if configured, it is not quite true to say that it _only_ looks in /etc/passwd. All of the above is also true on IRIX. It seems the original author had considered this problem, and in IRIX left a place- holder quotactl command "Q_BULKQSTAT" which I imagine would, had it been implemented, have been able to walk through quota files on XFS without needing this getpwent crutch. Would be an interesting little project to implement this for XFS on Linux if you're interested... just a simple matter of programming. Another fix would be to use something like NIS to ensure the uid:name mapping is available to the server. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 23 15:52:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7NMqw803123 for linux-xfs-outgoing; Thu, 23 Aug 2001 15:52:58 -0700 Received: from codon.com (codon.com [64.78.130.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NMqsd03099 for ; Thu, 23 Aug 2001 15:52:55 -0700 Received: (qmail 694 invoked by uid 516); 23 Aug 2001 23:05:39 -0000 Received: from nw@codon.com by helix with qmail-scanner-0.96 (. Clean. Processed in 0.052769 secs); 23 Aug 2001 23:05:39 -0000 Received: from weasel.local.iboats.com (HELO weasel) (64.78.130.80) by codon.com with SMTP; 23 Aug 2001 23:05:39 -0000 Message-ID: <002f01c12c25$adceae20$50824e40@iboats.com> From: "Steve Wolfe" To: "Linux XFS Mailing List" References: Subject: Re: productionserver Date: Thu, 23 Aug 2001 16:48:01 -0600 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 > We are rather diskbound with our server rather then processor. > The new machine will feature a dual 1Ghz PIII with at least 1GB of ram and > the raid will be a raid 10 totaling 6 disks with 2 raid0 sets which are > mirrored. The disks will be 73GB 10K RPM disks and each set of 3 will be > on it's own channel on the raid controller. You might want to consider the dual Athlons. My gut feeling is that for database work, they will smoke P3's. In a dual P3, you're sharing a 133 MHz bus between both processors, giving each CPU an effective 66 MHz bus if they're both working at full tilt. With the Athlons, each CPU has an independant 266 MHz bus, and even sharing the bandwidth to the memory, they still have an effective 133 MHz each, due to the DDR RAM. So, for working with large tables, where you have to move very large amounts of data to/from RAM in a short amount of time, having twice the bandwidth will probably make a very large difference. > In case you want to order one, it's a Dell PE 2500 with rackmount kit an > 6 73GB disks, UPS, and 3 year support. This brings the price in the > Netherlands to about 18.000 Euro (divide by 1.1 for US $). I've used Dells before, and while they're decent machines, the machines that I build myself are less expensive, just as reliable, and faster. For less money than that, we put together a quad Xeon, with SCA backplanes, hardware RAID, the works, and that was over a year ago. Of course, I realize that being in Europe probably increases your cost, and decreases your selection. (Incidentally, I'm thinking of testing a dual Athlon to replace the quad Xeon. The MHz rating would be similar (2.4 GHz to 2.8 GHz), but under heavy load, each Xeon has the equivalent of a 25 MHz bus, so even when the machine is maxed out, the bus seems to be the largest bottleneck. I don't think I've ever seen the CPU's hit more than about 80% utilization, they're sitting around waiting for data. steve From owner-linux-xfs@oss.sgi.com Thu Aug 23 17:42:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7O0gFl05698 for linux-xfs-outgoing; Thu, 23 Aug 2001 17:42:15 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7O0gAd05675 for ; Thu, 23 Aug 2001 17:42:10 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 19:41:22 -0500 Message-ID: <85063BBE668FD411944400D0B744267A643746@AUSMAIL> From: "Gonyou, Austin" To: "'Steve Wolfe'" , Linux XFS Mailing List Subject: RE: productionserver Date: Thu, 23 Aug 2001 19:41:17 -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 You could also try dual P4's. The dual P4 Xeon has a non-shared bus. So, you get like 2.4 Gb/s bandwidth per proc, versus the total 2.4Gb for both on the P3. Just a though. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Steve Wolfe [mailto:nw@codon.com] > Sent: Thursday, August 23, 2001 5:48 PM > To: Linux XFS Mailing List > Subject: Re: productionserver > > > > We are rather diskbound with our server rather then processor. > > The new machine will feature a dual 1Ghz PIII with at least > 1GB of ram > and > > the raid will be a raid 10 totaling 6 disks with 2 raid0 > sets which are > > mirrored. The disks will be 73GB 10K RPM disks and each set > of 3 will be > > on it's own channel on the raid controller. > > You might want to consider the dual Athlons. My gut > feeling is that for > database work, they will smoke P3's. In a dual P3, you're > sharing a 133 > MHz bus between both processors, giving each CPU an effective > 66 MHz bus > if they're both working at full tilt. With the Athlons, each > CPU has an > independant 266 MHz bus, and even sharing the bandwidth to the memory, > they still have an effective 133 MHz each, due to the DDR > RAM. So, for > working with large tables, where you have to move very large > amounts of > data to/from RAM in a short amount of time, having twice the bandwidth > will probably make a very large difference. > > > In case you want to order one, it's a Dell PE 2500 with > rackmount kit an > > 6 73GB disks, UPS, and 3 year support. This brings the price in the > > Netherlands to about 18.000 Euro (divide by 1.1 for US $). > > I've used Dells before, and while they're decent machines, > the machines > that I build myself are less expensive, just as reliable, and > faster. For > less money than that, we put together a quad Xeon, with SCA > backplanes, > hardware RAID, the works, and that was over a year ago. Of course, I > realize that being in Europe probably increases your cost, > and decreases > your selection. > > (Incidentally, I'm thinking of testing a dual Athlon to > replace the quad > Xeon. The MHz rating would be similar (2.4 GHz to 2.8 GHz), but under > heavy load, each Xeon has the equivalent of a 25 MHz bus, so > even when the > machine is maxed out, the bus seems to be the largest > bottleneck. I don't > think I've ever seen the CPU's hit more than about 80% utilization, > they're sitting around waiting for data. > > steve > > From owner-linux-xfs@oss.sgi.com Thu Aug 23 18:53:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7O1rPZ07051 for linux-xfs-outgoing; Thu, 23 Aug 2001 18:53:25 -0700 Received: from mplspop5.mpls.uswest.net (mplspop5.mpls.uswest.net [204.147.80.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7O1rMd07032 for ; Thu, 23 Aug 2001 18:53:22 -0700 Received: (qmail 4782 invoked from network); 24 Aug 2001 01:53:20 -0000 Received: from mplsdslgw15poolc32.mpls.uswest.net (HELO sgi.com) (63.229.198.32) by mplspop5.mpls.uswest.net with SMTP; 24 Aug 2001 01:53:20 -0000 Date: Thu, 23 Aug 2001 20:49:36 -0500 Message-ID: <3B85B2B0.471695A4@sgi.com> From: "Eric Sandeen" Cc: "Linux XFS Mailing List" 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 Subject: Re: productionserver References: <002f01c12c25$adceae20$50824e40@iboats.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve managed to hit a spam filter somehow, so forwarding his message back out... --- begin Steve's message --- > Hmm yes, however our disk lights are lit a lot. A saw my co worker test > run a testconversion from guilders to euro in our logistics package > kept the disk lit for over 40 minutes on the testbox. > > Now this onvolves actually ploughing trough the complete 6GB+ of the > databases and changing fields and values. We are talking milions of > records that needed to be changed. Afterall this was just a desktop > machine but still this is going faster then the now in production machine. I forgot to mention - the slowdown when updating the entire database may not be indicative of real-world slowdowns, since you certainly can't cache the entire 6 GB. But in the real world, are you really doing things that affect that much data? If you're not, then the disk cache much more effectively makes up for the overhead of RAID 5. If you are doing things like that in production, never mind. : ) steve --- end Steve's message --- From owner-linux-xfs@oss.sgi.com Thu Aug 23 20:28:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7O3SQU09303 for linux-xfs-outgoing; Thu, 23 Aug 2001 20:28:26 -0700 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 f7O3SLd09284 for ; Thu, 23 Aug 2001 20:28:21 -0700 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 f7O3XZ804834 for ; Thu, 23 Aug 2001 20:33:35 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA14153; Fri, 24 Aug 2001 13:26:57 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA68226; Fri, 24 Aug 2001 13:26:55 +1000 (AEST) Date: Fri, 24 Aug 2001 13:26:55 +1000 From: Nathan Scott To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: Slides for a talk I will be making Message-ID: <20010824132655.A274867@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jijo@leathercollection.ph on Fri, Aug 24, 2001 at 12:44:27AM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Fri, Aug 24, 2001 at 12:44:27AM +0800, Federico Sevilla III wrote: > Hi everyone, > > I will be making a short (30 minutes inclusive of Q&A) talk to the local > Linux community during the 10th anniversary celebrations on Saturday. My > talk is entitled "An Introduction to Advanced Filesystems for Linux", but > is more focused on ReiserFS and XFS, with a little bit on ext3 and even > less on JFS as I have no experience with these two (none yet, with XFS > doing great I am having difficulty finding the motivation to try them > out). > > I have put an exported (from StarImpress) copy of my simple slides up in > . It's working > except for one table that's broken for some reason. > > I'm putting this up so that those of you interested may look at it. > Hopefully I do not have any grave mistakes. Feedback would be great. I do Cool. A few minor details... - XFS does put the superblock at offset zero (your notes say 512). As a reference - ext2 puts first SB at 1024K, reiserfs is at 64K, I think; - Not sure what "VFS" means for POSIX ACLs. XFS natively supports ACLs, for ext2/3 you need a patch and then they natively support ACLs ... there is no other way to get ACL support; - Group quotas are supported in XFS, since release 1.0 (not a work in progress as your notes suggest) - might want to mention that XFS logs quota changes, and is unique in that respect (this means quotacheck(8) is a no-op on XFS filesystems as quota information is always consistent); I think there's a few more presentations on oss.sgi.com too, which you could refer to if you like. Have fun. > not know if Brian Smith is still part of the list. If you (Brian) are, I'd > like to thank you very much. Your presentation on a similar topic was very > very helpful to me in preparing mine. > > --> Jijo > > -- > Federico Sevilla III :: jijo@leathercollection.ph > Network Administrator :: The Leather Collection, Inc. > GnuPG Key: > cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 23 20:36:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7O3abX00469 for linux-xfs-outgoing; Thu, 23 Aug 2001 20:36:37 -0700 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 f7O3aZd00450 for ; Thu, 23 Aug 2001 20:36:35 -0700 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 f7O3gpa21802 for ; Thu, 23 Aug 2001 20:42:52 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA14194; Fri, 24 Aug 2001 13:35:11 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA33429; Fri, 24 Aug 2001 13:35:10 +1000 (AEST) Date: Fri, 24 Aug 2001 13:35:10 +1000 From: Nathan Scott To: Nathan Scott Cc: Federico Sevilla III , Linux XFS Mailing List Subject: Re: Slides for a talk I will be making Message-ID: <20010824133510.B274867@wobbly.melbourne.sgi.com> References: <20010824132655.A274867@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: <20010824132655.A274867@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Fri, Aug 24, 2001 at 01:26:55PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk just correcting myself... On Fri, Aug 24, 2001 at 01:26:55PM +1000, Nathan Scott wrote: > hi, > > - XFS does put the superblock at offset zero (your notes say 512). > As a reference - ext2 puts first SB at 1024K, reiserfs is at 64K, thats 1024 bytes, not 1024 Kbytes for the first ext2 superblock. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 23 20:59:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7O3xqH01656 for linux-xfs-outgoing; Thu, 23 Aug 2001 20:59:52 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7O3xnd01633 for ; Thu, 23 Aug 2001 20:59:49 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA00231 for ; Thu, 23 Aug 2001 20:59:47 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA85500 for linux-xfs@oss.sgi.com; Fri, 24 Aug 2001 13:58:20 +1000 (EST) Date: Fri, 24 Aug 2001 13:58:20 +1000 (EST) From: Nathan Scott Message-Id: <200108240358.NAA85500@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk minor problem introduced recently which could cause build problems due to additional include of linux/quota.h. Date: Thu Aug 23 20:52:51 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101449a linux/fs/pagebuf/page_buf_io.c - 1.94 - fix up the pre-2.4.9 compatibility macro for the new, improved "min". Date: Thu Aug 23 20:56:54 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101450a linux/include/linux/xqm.h - 1.7 cmd/xfsprogs/include/xqm.h - 1.5 - #include'ing was not such a good idea - relationship between and causes a build problem. From owner-linux-xfs@oss.sgi.com Thu Aug 23 22:55:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7O5tGj03991 for linux-xfs-outgoing; Thu, 23 Aug 2001 22:55:16 -0700 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 f7O5tDd03972 for ; Thu, 23 Aug 2001 22:55:13 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7O60S809409 for ; Thu, 23 Aug 2001 23:00:28 -0700 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA68201 for linux-xfs@oss.sgi.com; Fri, 24 Aug 2001 15:53:50 +1000 (EST) Date: Fri, 24 Aug 2001 15:53:50 +1000 (EST) From: Timothy Shimmin Message-Id: <200108240553.PAA68201@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - libacl Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adds Andi Kleen's better acl text parsing error msgs. --Tim Date: Thu Aug 23 22:51:02 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101454a cmd/xfstests/051.out - 1.11 cmd/xfstests/051 - 1.10 - Test out the new acl text error msgs. cmd/acl/chacl/chacl.c - 1.7 - Add Andi's acl_error_string() code for getting better acl msgs from bad acl text specs. cmd/acl/libacl/acl.c - 1.15 - Merge my changes twice ! Bloody p_integrate should be called p_disintegrate as Ivan suggested. First merge I manually did and then forgot to integrate with -o so had to go thru ptools merge results. Arghhhh. This adds Andi Kleen's changes for acl_error_string msgs. A few mods by me to get the context of msgs to be more accurate. Also some other consistency cleanups done. cmd/acl/include/acl.h - 1.8 - Add acl_error_string() proto. From owner-linux-xfs@oss.sgi.com Thu Aug 23 23:53:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7O6rtv05211 for linux-xfs-outgoing; Thu, 23 Aug 2001 23:53:55 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7O6rpd05192 for ; Thu, 23 Aug 2001 23:53:51 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA00285 for ; Thu, 23 Aug 2001 23:52:01 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA20931; Fri, 24 Aug 2001 16:52:20 +1000 (EST) Date: Fri, 24 Aug 2001 16:52:20 +1000 From: Timothy Shimmin To: Simon Matter Cc: linux-xfs Subject: Re: xfsrestore dumps core Message-ID: <20010824165220.F90700@boing.melbourne.sgi.com> References: <3B84F978.A447BCA@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3B84F978.A447BCA@ch.sauter-bc.com>; from simon.matter@ch.sauter-bc.com on Thu, Aug 23, 2001 at 02:39:20PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Simon, On Thu, Aug 23, 2001 at 02:39:20PM +0200, Simon Matter wrote: > > I was just trying to xfsdump and -restore some files on my test system > and I get a core dump while restoring. > The system is PII/400, 256MB, IDE disk, DLT1 tape drive /DELL PowerVault > 110T). RH XFS 1.0.1 release, newest command rpms, including > xfsdump-1.1.3-0. > > BTW /dev/tape is a link to /dev/st0 > > I did the dump with: > xfsdump -f /dev/tape -l 0 -s home -o -L session1 -M medium1 / > > No problems so far, then is tried restore with: > [root@looser /root]# xfsrestore -f /dev/tape xfsrestore > xfsrestore: drive_scsitape.c:1492: do_next_mark: Assertion > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( > contextp->dc_recsz )' failed. > Aborted (core dumped) > Ok so this is the assertion bug (pv#831275 in SGI). > I saw some discussion about this some weeks ago on this list but I was > wondering it's not yet fixed or I'm doing something completly wrong ? I haven't looked into this one yet. Someone suggested a fix by not endian converting some value. However, I wasn't convinced this was the right thing to do and so didn't check it in. Ciao, Tim. From owner-linux-xfs@oss.sgi.com Fri Aug 24 02:10:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7O9ALG08541 for linux-xfs-outgoing; Fri, 24 Aug 2001 02:10:21 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7O9AGd08521 for ; Fri, 24 Aug 2001 02:10:16 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id LAA27537; Fri, 24 Aug 2001 11:10:15 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id LAA10011; Fri, 24 Aug 2001 11:10:14 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 2119E57306; Fri, 24 Aug 2001 11:09:41 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id CEA4E25835; Fri, 24 Aug 2001 11:09:40 +0200 (CEST) Message-ID: <3B8619D4.D8A2666B@ch.sauter-bc.com> Date: Fri, 24 Aug 2001 11:09:40 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Timothy Shimmin Cc: linux-xfs Subject: Re: xfsrestore dumps core References: <3B84F978.A447BCA@ch.sauter-bc.com> <20010824165220.F90700@boing.melbourne.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Timothy Shimmin schrieb: > > Hi Simon, > > On Thu, Aug 23, 2001 at 02:39:20PM +0200, Simon Matter wrote: > > > > I was just trying to xfsdump and -restore some files on my test system > > and I get a core dump while restoring. > > The system is PII/400, 256MB, IDE disk, DLT1 tape drive /DELL PowerVault > > 110T). RH XFS 1.0.1 release, newest command rpms, including > > xfsdump-1.1.3-0. > > > > BTW /dev/tape is a link to /dev/st0 > > > > I did the dump with: > > xfsdump -f /dev/tape -l 0 -s home -o -L session1 -M medium1 / > > > > No problems so far, then is tried restore with: > > [root@looser /root]# xfsrestore -f /dev/tape xfsrestore > > xfsrestore: drive_scsitape.c:1492: do_next_mark: Assertion > > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( > > contextp->dc_recsz )' failed. > > Aborted (core dumped) > > > Ok so this is the assertion bug (pv#831275 in SGI). I have made a few more tests. It's interesting that it's working sometimes. When I dump/restore some Mb's, it's okay. With some 100Mb it dumps core. If you're interested in the core, just let me know. it's ~2M bzipped. -Simon > > > I saw some discussion about this some weeks ago on this list but I was > > wondering it's not yet fixed or I'm doing something completly wrong ? > I haven't looked into this one yet. > > Someone suggested a fix by not endian converting some value. > However, I wasn't convinced this was the right thing to do > and so didn't check it in. > > Ciao, > Tim. From owner-linux-xfs@oss.sgi.com Fri Aug 24 03:02:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OA2GZ09606 for linux-xfs-outgoing; Fri, 24 Aug 2001 03:02:16 -0700 Received: from mail.artstor.de ([195.243.248.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OA2Dd09587 for ; Fri, 24 Aug 2001 03:02:13 -0700 Received: (qmail 10887 invoked from network); 24 Aug 2001 10:06:47 -0000 Received: from zerberus.artstor.de (HELO artstor.de) (195.243.248.115) by www.artstor.de with SMTP; 24 Aug 2001 10:06:47 -0000 Message-ID: <3B862623.9060707@artstor.de> Date: Fri, 24 Aug 2001 12:02:11 +0200 From: Jan Strohbehn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs Subject: Checking mounted fs References: <20010723095815.B402@chimesnet.com> <200107231404.f6NE4B010447@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi !! I have a SAN with two servers and one disk with an xfs. They are connected over heartbeat, so that the second server performs a failover, if the first fails. My question is, can I run a "xfs_check /dev/.. || xfs_repair /dev/.." before mounting the disk (during a takeover), or will I run into additional problems, if the xfs is (accidently) still mounted etc. ?? (It just happened, that the takeover failed because of a corrupted xfs.) Thanks, Jan From owner-linux-xfs@oss.sgi.com Fri Aug 24 03:47:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OAl5A10291 for linux-xfs-outgoing; Fri, 24 Aug 2001 03:47:05 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OAl2d10272 for ; Fri, 24 Aug 2001 03:47:02 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 9F835C00FBD for ; Fri, 24 Aug 2001 18:47:03 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3F39CC00FAE for ; Fri, 24 Aug 2001 18:47:02 +0800 (PHT) Date: Fri, 24 Aug 2001 18:47:02 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: Slides for a talk I will be making In-Reply-To: <00fa01c12c87$944e4890$0900a8c0@talby> 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, 24 Aug 2001 at 12:28, Hans Kratz wrote: > The Reiserfs slides state that link() on Reiserfs is not synchronous. > This is correct but is the same not true for XFS as well? This I do not know, either. Thank you for bringing this up. There is a clear FAQ entry about ReiserFS not treating link() as synchronous because of issues with QMail (and most other mail transfer agents, I think, but am not sure). I was under the impression that XFS treated the link() as a synchronous operation. Maybe the experts can shed some light on this? > Whatever is the case you should state if XFS link()/unlink() is > synchronous on the XFS slides for symmetry reasons. I agree. Thank you very much for the feedback. I will put information on this in my slides as soon as I get a response from the XFS development team. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Fri Aug 24 04:43:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OBhCJ11507 for linux-xfs-outgoing; Fri, 24 Aug 2001 04:43:12 -0700 Received: from e4.eyal.emu.id.au ([144.137.83.84]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OBh8d11487 for ; Fri, 24 Aug 2001 04:43:08 -0700 Received: from eyal.emu.id.au (eyal.emu.id.au [192.168.2.7]) by e4.eyal.emu.id.au (8.11.2/8.11.2) with ESMTP id f7OBmdw20045 for ; Fri, 24 Aug 2001 21:48:40 +1000 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 ; Fri, 24 Aug 2001 21:33:47 +1000 (EST) Message-ID: <3B863B9B.7A289825@eyal.emu.id.au> Date: Fri, 24 Aug 2001 21:33:47 +1000 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-ac8 i686) X-Accept-Language: en MIME-Version: 1.0 To: "list, linux-xfs" Subject: multiple writes of same block Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Using XFS (latest 2.4.9-xfs) over raid5 I got a message: raid5: multiple 1 requests for sector 24663824 and the explanation I got from the raid list is: > It means that while raid5 had an outstanding write request on a > particular sector, it received another write request for the same > sector. > > It trys to do the right thing and write them both out in the order > that it received them, but it is a bit of a worry that any filesystem > would do this. I'm guessing that Andrew is using XFS too. Is that > right? > > While raid5 tries to keep the requests in order, and I suspect other > drivers do to, I don't think that it is reasonable to assume that no > device driver will ever re-order two requests for the same sector. > If I were the author of the filesystem I would be worried. > > NeilBrown This truely sounds worrying. Is this OK to be this way or is this an issue that needs fixing? -- Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Fri Aug 24 06:56:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ODuCr14309 for linux-xfs-outgoing; Fri, 24 Aug 2001 06:56:12 -0700 Received: from mplspop4.mpls.uswest.net (mplspop4.mpls.uswest.net [204.147.80.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ODu9d14286 for ; Fri, 24 Aug 2001 06:56:09 -0700 Received: (qmail 35618 invoked from network); 24 Aug 2001 13:56:08 -0000 Received: from mplsdslgw15poolc32.mpls.uswest.net (HELO sgi.com) (63.229.198.32) by mplspop4.mpls.uswest.net with SMTP; 24 Aug 2001 13:56:08 -0000 Date: Fri, 24 Aug 2001 08:52:23 -0500 Message-ID: <3B865C17.A582B094@sgi.com> From: "Eric Sandeen" To: "Jan Strohbehn" Cc: "linux-xfs" 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 Subject: Re: Checking mounted fs References: <20010723095815.B402@chimesnet.com> <200107231404.f6NE4B010447@jen.americas.sgi.com> <3B862623.9060707@artstor.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jan Strohbehn wrote: > My question is, can I run a "xfs_check /dev/.. || xfs_repair /dev/.." > before mounting the disk (during a takeover), or will I run into > additional problems, if the xfs is (accidently) still mounted etc. ?? > (It just happened, that the takeover failed because of a corrupted xfs.) Both commands will simply fail if the filesystem is mounted. You could check /proc/mounts first, I suppose, to see what's mounted before you try to do this? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Aug 24 06:58:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ODwb714482 for linux-xfs-outgoing; Fri, 24 Aug 2001 06:58:37 -0700 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 f7ODwYd14462 for ; Fri, 24 Aug 2001 06:58:34 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GIKS5L00.DY2 for ; Fri, 24 Aug 2001 08:58:33 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001082408583204259 for ; Fri, 24 Aug 2001 08:58:32 -0500 Message-ID: <3B865EAF.8FCA6E59@fnal.gov> Date: Fri, 24 Aug 2001 09:03:27 -0500 From: yocum@fnal.gov 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: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > Back on topic: at least one data analyst moved about 40GB of data around > > last night via NFS from OSF1 to Linux using NFVv3 and there were no inode > > corruptions. The kernel being used *is* 2.4.8-xfs which was compiled with > > gcc-2.96-85 (because I didn't get around to recompiling with kgcc yet, > > mkp). > > If you see it again please recompile it if you can. Or find out what's > going wrong with gcc 2.96. I have, and I'm re-compiling with kgcc as we speak. Hopefully this will fix the problem. Unfortunately, there is nothing the logs that indicates a problem... gr. As always, I'll let you know if I continue to have the problem. 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 Fri Aug 24 06:59:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ODxRh14611 for linux-xfs-outgoing; Fri, 24 Aug 2001 06:59:27 -0700 Received: from mplspop5.mpls.uswest.net (mplspop5.mpls.uswest.net [204.147.80.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ODxPd14592 for ; Fri, 24 Aug 2001 06:59:25 -0700 Received: (qmail 36334 invoked from network); 24 Aug 2001 13:59:23 -0000 Received: from mplsdslgw15poolc32.mpls.uswest.net (HELO sgi.com) (63.229.198.32) by mplspop5.mpls.uswest.net with SMTP; 24 Aug 2001 13:59:23 -0000 Date: Fri, 24 Aug 2001 08:55:38 -0500 Message-ID: <3B865CDA.F8E80B07@sgi.com> From: "Eric Sandeen" To: "Jan Strohbehn" , " linux-xfs" 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 Subject: Re: Checking mounted fs References: <20010723095815.B402@chimesnet.com> <200107231404.f6NE4B010447@jen.americas.sgi.com> <3B862623.9060707@artstor.de> <3B865C17.A582B094@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: > Both commands will simply fail if the filesystem is mounted. Oops, not quite true, xfs_check will run happily on a mounted, _read only_ filesystem. -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 Aug 24 07:03:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OE3bv14828 for linux-xfs-outgoing; Fri, 24 Aug 2001 07:03:37 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OE3Yd14809 for ; Fri, 24 Aug 2001 07:03:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA06375 for ; Fri, 24 Aug 2001 07:03:34 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2798282; Fri, 24 Aug 2001 09:02:17 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA44514; Fri, 24 Aug 2001 09:02:17 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7OE20S02230; Fri, 24 Aug 2001 09:02:01 -0500 Message-Id: <200108241402.f7OE20S02230@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jan Strohbehn cc: linux-xfs Subject: Re: Checking mounted fs In-Reply-To: Message from Jan Strohbehn of "Fri, 24 Aug 2001 12:02:11 +0200." <3B862623.9060707@artstor.de> Date: Fri, 24 Aug 2001 09:02:00 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi !! > > I have a SAN with two servers and one disk with an xfs. > They are connected over heartbeat, so that the second server performs a > failover, if the first fails. > > My question is, can I run a "xfs_check /dev/.. || xfs_repair /dev/.." > before mounting the disk (during a takeover), or will I run into > additional problems, if the xfs is (accidently) still mounted etc. ?? > (It just happened, that the takeover failed because of a corrupted xfs.) > > Thanks, > Jan OK, first off you are playing with fire a little bit here, in this sort of setup it is normal to have some sort of reset mechanism hooked up to the heartbeating, if you detect the alternate machine has gone down then you reset it (STOMITH or shoot the other machine in the head is one term for this) before mounting the filesystem on the second box. In general the mount should work on the second box, the fact that it does not suggests some other problem. What sort of configuration are you using for the filesystem (raid, lvm etc), and what sort of error did you get. If the filesystem is still mounted an active on one machine and you run xfs_repair on the second then you will potentially corrupt it, repair and check both ignore state in the log. Should a system still be running and relying on that log being out on disk then it could write some data out to disk and then have this overwritten by repair. This would be followed by remaining related metadata being written to disk and the filesystem would become inconsistent. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 24 07:23:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OENc015336 for linux-xfs-outgoing; Fri, 24 Aug 2001 07:23:38 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OENYd15309 for ; Fri, 24 Aug 2001 07:23:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA14614 for ; Fri, 24 Aug 2001 07:23:16 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2802705; Fri, 24 Aug 2001 09:22:17 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA93538; Fri, 24 Aug 2001 09:22:17 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7OEM0D02336; Fri, 24 Aug 2001 09:22:00 -0500 Message-Id: <200108241422.f7OEM0D02336@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Eyal Lebedinsky , ak@dkp.com cc: "list, linux-xfs" Subject: Re: multiple writes of same block In-Reply-To: Message from Eyal Lebedinsky of "Fri, 24 Aug 2001 21:33:47 +1000." <3B863B9B.7A289825@eyal.emu.id.au> Date: Fri, 24 Aug 2001 09:22:00 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If someone is experiencing this can they please do the following: o add a call to BUG() after the printk in md, line 786 in drivers/block/md/raid5.c o build the kernel with kdb enabled o do an insmod xfsidbg and insmod kdbm_pg o run until the system crashes. o use the bt command in kdb to report the stack trace for this process. o look at the second argument to add_stripe_bh, use the bh command on it: bh 0xaaaaaaaaaa o send us the output. It would also be useful to add another printk after line 786 to look something like this: printk(KERN_NOTICE "raid5: new bh at blk 0x%x len 0x%x, existing blk 0x%x len 0x%x\n", bh->b_blocknr, bh->b_size, (*bhp)->b_blocknr, (*bhp)->b_size); You can do the latter without all the kdb and panicing the system stuff, it might be a good starting point. Steve > Using XFS (latest 2.4.9-xfs) over raid5 I got a message: > raid5: multiple 1 requests for sector 24663824 > and the explanation I got from the raid list is: > > > It means that while raid5 had an outstanding write request on a > > particular sector, it received another write request for the same > > sector. > > > > It trys to do the right thing and write them both out in the order > > that it received them, but it is a bit of a worry that any filesystem > > would do this. I'm guessing that Andrew is using XFS too. Is that > > right? > > > > While raid5 tries to keep the requests in order, and I suspect other > > drivers do to, I don't think that it is reasonable to assume that no > > device driver will ever re-order two requests for the same sector. > > If I were the author of the filesystem I would be worried. > > > > NeilBrown > > This truely sounds worrying. Is this OK to be this way or is this > an issue that needs fixing? > > -- > Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Fri Aug 24 09:11:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OGBe117687 for linux-xfs-outgoing; Fri, 24 Aug 2001 09:11:40 -0700 Received: from www.fortuitous.com (cs666824-51.austin.rr.com [66.68.24.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OGBbd17668 for ; Fri, 24 Aug 2001 09:11:37 -0700 Received: by www.fortuitous.com (Postfix, from userid 500) id EF41886B; Fri, 24 Aug 2001 11:08:41 -0500 (CDT) Date: Fri, 24 Aug 2001 11:08:41 -0500 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Tera-Byte+ fileservers Message-ID: <20010824110841.A22894@bistro.marx> Reply-To: pac@fortuitous.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anyone know what makes a good inexpensive TeraByte fileserver? Specifically looking for something between 1TB and 100TB. This would run XFS for sure. I'd like to put together several systems, in both IDE and SCSI version. 1. Is there a decent IDE-raid card that can support over a Terabyte? Is there such a thing as a hot-swappable IDE raid card? Whats the fastest thru-put I can expect out of an IDE raid setup? Does an IDE TB server even make sense? 2. Is SCA the way to go for scsi? What cards, backplanes, drives can you recommend? Whats the fastest thru-put I can expect out of an SCSI raid setup? 3. Whats the fastest throughput i can get away with? Gigabit ether? Is there another interface that makes more sense? Thanks, -phil -- .--------------------------------------------------------. | 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 Fri Aug 24 09:53:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OGrbw18481 for linux-xfs-outgoing; Fri, 24 Aug 2001 09:53:37 -0700 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 f7OGrYd18462 for ; Fri, 24 Aug 2001 09:53:34 -0700 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 GIL0B300.L5B for ; Fri, 24 Aug 2001 12:54:39 -0400 Message-ID: <3B86868A.6C773AB4@umbi.umd.edu> Date: Fri, 24 Aug 2001 12:53:30 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: where is xfs_copy? References: <20010824110841.A22894@bistro.marx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi folks, Is xfs_copy available anywhere for Linux? The man page is in the xfsdump rpm, but I don't find the binary. I haven't dug into the src.rpm or the tar.gz yet. I would like to be able to use xfs_copy to clone or relocate XFS filesystems to different partitions. I have been using xfsdump piped to xfsrestore, but at least on IRIX I thought I got better performance with xfs_copy. Thanks, -- "Jonathan F. Dill" (dill@umbi.umd.edu) CARB Systems and Network Administrator Home Page: http://www.umbi.umd.edu/~dill From owner-linux-xfs@oss.sgi.com Fri Aug 24 09:59:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OGxTj18668 for linux-xfs-outgoing; Fri, 24 Aug 2001 09:59:29 -0700 Received: from pipt.oz.cc.utah.edu (jdr1529@pipt.oz.cc.utah.edu [155.99.2.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OGxRd18648 for ; Fri, 24 Aug 2001 09:59:27 -0700 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id KAA18833; Fri, 24 Aug 2001 10:59:22 -0600 (MDT) Date: Fri, 24 Aug 2001 10:59:21 -0600 (MDT) From: james rich To: "Orn E. Hansen" cc: linux-xfs@oss.sgi.com Subject: Re: 911 - Rescue! In-Reply-To: <200108231907.f7NJ70l01399@citadel.oehansen.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 23 Aug 2001, Orn E. Hansen wrote: > (like here) isn't that great... isn't it possible to fit xfs driver on the > driver disk? Salvatore Sisinni has put together a slackware boot/root disk set that has just what you need (xfs built into the kernel). Grab 'em from: ftp://ftp.chowhouse.com/pub/xfs/XFSbare.i ftp://ftp.chowhouse.com/pub/xfs/XFScolor.gz ftp://ftp.chowhouse.com/pub/xfs/XFSnetw.dsk There is also an MD5 checksum file there in the same directory. James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Fri Aug 24 10:24:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OHODB19053 for linux-xfs-outgoing; Fri, 24 Aug 2001 10:24:13 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OHO9d19034 for ; Fri, 24 Aug 2001 10:24:09 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA09451 for ; Fri, 24 Aug 2001 10:23:51 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2802209; Fri, 24 Aug 2001 12:22:52 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA64162; Fri, 24 Aug 2001 12:22:51 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7OHMXW02913; Fri, 24 Aug 2001 12:22:33 -0500 Message-Id: <200108241722.f7OHMXW02913@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: pac@fortuitous.com cc: linux-xfs@oss.sgi.com Subject: Re: Tera-Byte+ fileservers In-Reply-To: Message from pac@fortuitous.com of "Fri, 24 Aug 2001 11:08:41 CDT." <20010824110841.A22894@bistro.marx> Date: Fri, 24 Aug 2001 12:22:33 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Anyone know what makes a good inexpensive TeraByte fileserver? > Specifically looking for something between 1TB and 100TB. > This would run XFS for sure. Remember that the current limit on a block device is 2Tbytes, so the only way to get into this sort of size on linux is with multiple filesystems. There have been some patches floated around to allow 64 bit addresses for disk locations, but actually incorporating one of these into a real live working system is not a task to approach lightly. Just so you are aware of this..... Steve > > I'd like to put together several systems, in both IDE and SCSI version. > > 1. Is there a decent IDE-raid card that can support over a Terabyte? > Is there such a thing as a hot-swappable IDE raid card? > Whats the fastest thru-put I can expect out of an IDE raid setup? > Does an IDE TB server even make sense? > > 2. Is SCA the way to go for scsi? What cards, backplanes, drives > can you recommend? > Whats the fastest thru-put I can expect out of an SCSI raid setup? > > 3. Whats the fastest throughput i can get away with? Gigabit ether? > Is there another interface that makes more sense? > > Thanks, > > -phil > -- > .--------------------------------------------------------. > | 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 Fri Aug 24 10:50:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OHoYr19633 for linux-xfs-outgoing; Fri, 24 Aug 2001 10:50:34 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OHoVd19614 for ; Fri, 24 Aug 2001 10:50:31 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f7OHnnl06459; Fri, 24 Aug 2001 13:49:49 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Fri, 24 Aug 2001 13:49:49 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: cc: Subject: Re: Tera-Byte+ fileservers In-Reply-To: <20010824110841.A22894@bistro.marx> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 24 Aug 2001 at 11:08am, pac@fortuitous.com wrote > I'd like to put together several systems, in both IDE and SCSI version. > > 1. Is there a decent IDE-raid card that can support over a Terabyte? > Is there such a thing as a hot-swappable IDE raid card? > Whats the fastest thru-put I can expect out of an IDE raid setup? > Does an IDE TB server even make sense? You may want to subscribe to the linux-ide-arrays list, where they talk about these very issues... You can subscribe over the web at: http://lists.math.uh.edu/cgi-bin/mj_wwwusr -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Fri Aug 24 11:18:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OII1n20357 for linux-xfs-outgoing; Fri, 24 Aug 2001 11:18:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OIHwd20338 for ; Fri, 24 Aug 2001 11:17:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA04277 for ; Fri, 24 Aug 2001 11:16:10 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2805351; Fri, 24 Aug 2001 13:16:42 -0500 (CDT) Received: from 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 NAA80918; Fri, 24 Aug 2001 13:16:41 -0500 (CDT) Message-ID: <3B8699D5.AD7BC@sgi.com> Date: Fri, 24 Aug 2001 13:15:49 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Dill CC: linux-xfs@oss.sgi.com Subject: Re: where is xfs_copy? References: <20010824110841.A22894@bistro.marx> <3B86868A.6C773AB4@umbi.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jonathan Dill wrote: > > Hi folks, > > Is xfs_copy available anywhere for Linux? The man page is in the > xfsdump rpm, but I don't find the binary. I haven't dug into the > src.rpm or the tar.gz yet. I would like to be able to use xfs_copy to > clone or relocate XFS filesystems to different partitions. I have been > using xfsdump piped to xfsrestore, but at least on IRIX I thought I got > better performance with xfs_copy. Hm, the source is in CVS, but not built - the makefile says: #LTCOMMAND = xfs_copy # NEEDS FURTHER PORTING WORK and the README says: TODO LIST --------- * complete the port of xfs_copy (needs pthreads & locking code) so I guess it's not ready for prime-time... :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Aug 24 11:35:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OIZ3C20992 for linux-xfs-outgoing; Fri, 24 Aug 2001 11:35:03 -0700 Received: from tigger.cc-concepts.com (64-40-83-10.mb.dsl.mebtel.net [64.40.83.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OIYwd20973 for ; Fri, 24 Aug 2001 11:34:58 -0700 Received: from baptistefamily.net (gwy3.cc-concepts.com [64.40.83.12]) by tigger.cc-concepts.com (8.9.3/8.9.3) with ESMTP id OAA14773; Fri, 24 Aug 2001 14:34:56 -0400 Message-ID: <3B869E4E.8090004@baptistefamily.net> Date: Fri, 24 Aug 2001 14:34:54 -0400 From: Mike Baptiste User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: pac@fortuitous.com CC: linux-xfs@oss.sgi.com Subject: Re: Tera-Byte+ fileservers References: <20010824110841.A22894@bistro.marx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I know some folks who put together 1TB file servers for < $5K They used Athlon motherboards and Promise RAID gear (http://www.promise.com/ATARaid/) Their controllers seem to be able to do Hot Swap (see the bottom of their products page) Of course, the throughput and such depend on lots of things, the CPU type, NIC, IDE controller, drive type, etc. If you do SCSI and want hot swap - SCA is the way to go unless you make the very expensive jump to Fibre Channel. One key is make sure whatever enclosure you use for the drives has dual fans and a way to tell if a fan dies - those tiny drive tray fans die all teh time, but are very important given how hot today's drives get. If you really want to go all out, for about $100/drive you can get a drive bay (SCA & IDE) with a built in LCD panel showing +5/+12V readings, drive temp, fan status, drive activity and alarms if the drive or fans fail. Pretty slick. And make sure whatever controlelr you get is supported by your OS! I'm pretty sure the FastTracks are suported in Linux, but I don't know how well. Of course, you can build a 1TB fileserver for just over $3K - but then you have to back it up! :) Mike pac@fortuitous.com wrote: > Anyone know what makes a good inexpensive TeraByte fileserver? > Specifically looking for something between 1TB and 100TB. > This would run XFS for sure. > > I'd like to put together several systems, in both IDE and SCSI version. > > 1. Is there a decent IDE-raid card that can support over a Terabyte? > Is there such a thing as a hot-swappable IDE raid card? > Whats the fastest thru-put I can expect out of an IDE raid setup? > Does an IDE TB server even make sense? > > 2. Is SCA the way to go for scsi? What cards, backplanes, drives > can you recommend? > Whats the fastest thru-put I can expect out of an SCSI raid setup? > > 3. Whats the fastest throughput i can get away with? Gigabit ether? > Is there another interface that makes more sense? > > Thanks, > > -phil > -- > .--------------------------------------------------------. > | 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 Fri Aug 24 11:59:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OIxA721572 for linux-xfs-outgoing; Fri, 24 Aug 2001 11:59:10 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-98.fl.sprintbbd.net [66.1.218.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OIx7d21546 for ; Fri, 24 Aug 2001 11:59:08 -0700 Received: from ieee.org (thebs.cc.absoval.com. [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id OAA27843; Fri, 24 Aug 2001 14:57:55 -0400 Message-ID: <3B86A377.416E7741@ieee.org> Date: Fri, 24 Aug 2001 14:56:55 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: pac@fortuitous.com, linux-xfs@oss.sgi.com Subject: Re: Tera-Byte+ fileservers References: <200108241722.f7OHMXW02913@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: > Remember that the current limit on a block device is 2Tbytes, > so the only way to get into this sort of size on linux is with > multiple filesystems. Which is PC BIOS limitation as well (not that it is an issue in Linux). There is also an ATA limit of 133GB on all but the latest drives. Many "trick BIOS" ATA cards fail to overcome this limit. -- 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 From owner-linux-xfs@oss.sgi.com Fri Aug 24 12:13:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OJDpl21990 for linux-xfs-outgoing; Fri, 24 Aug 2001 12:13:51 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-98.fl.sprintbbd.net [66.1.218.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OJDld21971 for ; Fri, 24 Aug 2001 12:13:48 -0700 Received: from ieee.org (thebs.cc.absoval.com. [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id PAA27907; Fri, 24 Aug 2001 15:11:58 -0400 Message-ID: <3B86A6C3.3046578B@ieee.org> Date: Fri, 24 Aug 2001 15:10:59 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Baptiste CC: pac@fortuitous.com, linux-xfs@oss.sgi.com Subject: Re: Tera-Byte+ fileservers References: <20010824110841.A22894@bistro.marx> <3B869E4E.8090004@baptistefamily.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Baptiste wrote: > I know some folks who put together 1TB file servers for < $5K > They used Athlon motherboards and Promise RAID gear > (http://www.promise.com/ATARaid/) Promise? Ouch. Especially if it is the "trick BIOS" FastTrak. Even the SuperTrak is not _that_ good compared to the Adaptec 2400A or the 3Ware Escaldes -- at least according to StorageReview.COM. The only time I've seen people having problems with 3Ware cards has been when they change the default block size, use RAID-5 (which has slow write performance anyway) or load older run-time monitoring software while running with newer drivers and/or firmware. -- 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 From owner-linux-xfs@oss.sgi.com Fri Aug 24 12:23:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OJNqv22276 for linux-xfs-outgoing; Fri, 24 Aug 2001 12:23:52 -0700 Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OJNmd22257 for ; Fri, 24 Aug 2001 12:23:48 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 15aMYS-0003Yg-0X for linux-xfs@oss.sgi.com; Fri, 24 Aug 2001 20:23:44 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 3BC2C27F0 for ; Fri, 24 Aug 2001 20:23:42 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id 8B6AF125E6; Fri, 24 Aug 2001 20:23:41 +0100 (BST) Date: Fri, 24 Aug 2001 20:23:41 +0100 (BST) From: Keith Matthews Subject: Re[2]: Slides for a talk I will be making To: Linux XFS Mailing List In-Reply-To: References: X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010824192341.8B6AF125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f7OJNnd22258 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 24 Aug 2001 18:47:02 +0800 (PHT) Federico Sevilla III > wrote: > On Fri, 24 Aug 2001 at 12:28, Hans Kratz wrote: > > The Reiserfs slides state that link() on Reiserfs is not synchronous. > > This is correct but is the same not true for XFS as well? > This I do not know, either. Thank you for bringing this up. There is a > clear FAQ entry about ReiserFS not treating link() as synchronous because > of issues with QMail (and most other mail transfer agents, I think, but am > not sure). Cerainly Postfix. Postfix works on XFS, but has some problems as it automatically calls fsync() to ensure safety and calls chattr+S on its files. as chattr is only supported on ext2/ext3 this causes some aggro. I'm getting reports of good postfix performance on ext3, as would be expected, full data journalling is important to such an app. BTW, I'm not sure the entry about JFS and ACLS is correct. I'm on the JFS mailing list and ACL support is still (within last week) being listed as 'todo'. I'll do a little more checking as I have been preparing something similar for my local LUG although the audience will be more techically capable and I was intending a different level of cover. -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Fri Aug 24 12:36:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OJaAa22657 for linux-xfs-outgoing; Fri, 24 Aug 2001 12:36:10 -0700 Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OJa5d22638 for ; Fri, 24 Aug 2001 12:36:05 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.2/8.11.2) id f7OJZt716753; Fri, 24 Aug 2001 21:35:55 +0200 Date: Fri, 24 Aug 2001 21:35:54 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com, mike@bigstorage.com Subject: Re: Tera-Byte+ fileservers Message-ID: <20010824213554.D11527@vestdata.no> References: <20010824110841.A22894@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010824110841.A22894@bistro.marx>; from pac@fortuitous.com on Fri, Aug 24, 2001 at 11:08:41AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 24, 2001 at 11:08:41AM -0500, pac@fortuitous.com wrote: > Anyone know what makes a good inexpensive TeraByte fileserver? > Specifically looking for something between 1TB and 100TB. > This would run XFS for sure. We don't usually advertise on mailingslists, but you asked for it, so... Yes, Big Storage makes good inexpensive TeraByte fileservers. > I'd like to put together several systems, in both IDE and SCSI version. > 1. Is there a decent IDE-raid card that can support over a Terabyte? > Is there such a thing as a hot-swappable IDE raid card? > Whats the fastest thru-put I can expect out of an IDE raid setup? > Does an IDE TB server even make sense? I'm not sure what you mean by IDE-raid card? You obviously can't use PCI RAID-controllers for a setup this big, because you can't fit this many disks close enough to the server and because it's a pain to manage. You should go either with SCSI-SCSI, or IDE-SCSI RAIDs - it's primerely a price vs performance issue. (or FiberChanel) > 2. Is SCA the way to go for scsi? What cards, backplanes, drives > can you recommend? > Whats the fastest thru-put I can expect out of an SCSI raid setup? We've messured 120 MB/s sequential writes (using bonnie++ over XFS on linux) over a single SCSI-channel. If you're after awsome performance you should use multiple RAIDs connected on seperate SCSI-channels. Your bottleneck will be the PCI-bus on your server. You can get better performance on a non x86 system, but if you care about cost and don't need all your 100TB on a single server you get far more for your money by splitting it up on multiple x86 boxes. > 3. Whats the fastest throughput i can get away with? Gigabit ether? > Is there another interface that makes more sense? One or more gigabit sounds like a good solution. As others have alreaddy responded there is a 1 or 2 TB devicesize limit in the linux kernel, depending on what drivers you use. There is work beeing done to fix this, and we've successfully created > 2TB filesystems on our hardware - but it's not likely to be in the standard kernel until 2.5/2.6. It's hard to give you any good advice as you didn't really say much about what you're going to use your system for. Please email us back off the list with more info. -- Ragnar Kjorstad Big Storage From owner-linux-xfs@oss.sgi.com Fri Aug 24 12:46:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OJkEp22977 for linux-xfs-outgoing; Fri, 24 Aug 2001 12:46:14 -0700 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 f7OJkBd22958 for ; Fri, 24 Aug 2001 12:46:11 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7OJpR806981 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Fri, 24 Aug 2001 12:51:28 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA487671 for ; Fri, 24 Aug 2001 21:46:04 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2804835; Fri, 24 Aug 2001 14:44:46 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA07696; Fri, 24 Aug 2001 14:44:45 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7OJiQl03323; Fri, 24 Aug 2001 14:44:27 -0500 Message-Id: <200108241944.f7OJiQl03323@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Federico Sevilla III cc: Linux XFS Mailing List Subject: Re: Slides for a talk I will be making In-Reply-To: Message from Federico Sevilla III of "Fri, 24 Aug 2001 18:47:02 +0800." Date: Fri, 24 Aug 2001 14:44:26 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, 24 Aug 2001 at 12:28, Hans Kratz wrote: > > The Reiserfs slides state that link() on Reiserfs is not synchronous. > > This is correct but is the same not true for XFS as well? > > This I do not know, either. Thank you for bringing this up. There is a > clear FAQ entry about ReiserFS not treating link() as synchronous because > of issues with QMail (and most other mail transfer agents, I think, but am > not sure). > > I was under the impression that XFS treated the link() as a synchronous > operation. Maybe the experts can shed some light on this? > > > Whatever is the case you should state if XFS link()/unlink() is > > synchronous on the XFS slides for symmetry reasons. > > I agree. Thank you very much for the feedback. I will put information on > this in my slides as soon as I get a response from the XFS development > team. > > --> Jijo > link is not synchronous in xfs. The only way to acheive this is to make all transactions synchronous using the wsync mount option. For performance reasons this is not something you want to do unless you absolutely have to. For a back door trick to make sure a transaction is on the disk, you can either do a small O_SYNC write to a file, or some other operation which will flush the log. I do not think there is a hard and fast way to make sure that the link and just the link gets pushed to disk immediately without doing some other operation. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 24 13:54:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OKs8O25003 for linux-xfs-outgoing; Fri, 24 Aug 2001 13:54:08 -0700 Received: from xenon.niehs.nih.gov (xenon.niehs.nih.gov [157.98.12.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OKs5d24984 for ; Fri, 24 Aug 2001 13:54:05 -0700 Received: (from krahn@localhost) by xenon.niehs.nih.gov (8.11.2/8.8.7) id f7OKtIp06801; Fri, 24 Aug 2001 16:55:18 -0400 Date: Fri, 24 Aug 2001 16:55:18 -0400 From: "Dr. Joe Krahn (Joe)" Message-Id: <200108242055.f7OKtIp06801@xenon.niehs.nih.gov> To: allenq@yahoo.com, sandeen@sgi.com Subject: Re: About XFS-1.0.1 Kickstart Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I think the DAC960 problem relates to devfs (causes a lot of new-user problems and maybe should be optional.) The RAID device names are different, such as: /dev/rd/disc0/part1 on my system. You can also try the kernel option devfs=nomount, but this might also cause problems with other parts of the install process. Joe Krahn From owner-linux-xfs@oss.sgi.com Fri Aug 24 14:11:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OLBEk25644 for linux-xfs-outgoing; Fri, 24 Aug 2001 14:11:14 -0700 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 f7OLBBd25624 for ; Fri, 24 Aug 2001 14:11:11 -0700 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 f7OLGS812374 for ; Fri, 24 Aug 2001 14:16:28 -0700 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 QAA2789958; Fri, 24 Aug 2001 16:09:49 -0500 (CDT) Received: from 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 QAA62061; Fri, 24 Aug 2001 16:09:48 -0500 (CDT) Message-ID: <3B86C267.8E4C951F@sgi.com> Date: Fri, 24 Aug 2001 16:08:55 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Joe Krahn (Joe)" CC: allenq@yahoo.com, linux-xfs@oss.sgi.com Subject: Re: About XFS-1.0.1 Kickstart References: <200108242055.f7OKtIp06801@xenon.niehs.nih.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I would vote for that, except devfs is turned off in 1.0.1... :) -Eric "Dr. Joe Krahn (Joe)" wrote: > > I think the DAC960 problem relates to devfs (causes a lot > of new-user problems and maybe should be optional.) > The RAID device names are different, such as: > /dev/rd/disc0/part1 on my system. > You can also try the kernel option devfs=nomount, > but this might also cause problems with other parts > of the install process. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Aug 24 14:16:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OLG5S25872 for linux-xfs-outgoing; Fri, 24 Aug 2001 14:16:05 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OLG2d25852 for ; Fri, 24 Aug 2001 14:16:02 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA25911; Fri, 24 Aug 2001 23:15:24 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA22101; Fri, 24 Aug 2001 23:15:24 +0200 (CEST) Date: Fri, 24 Aug 2001 23:15:24 +0200 (CEST) From: Seth Mos To: Bryan-TheBS-Smith cc: Mike Baptiste , pac@fortuitous.com, linux-xfs@oss.sgi.com Subject: Re: Tera-Byte+ fileservers In-Reply-To: <3B86A6C3.3046578B@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 24 Aug 2001, Bryan-TheBS-Smith wrote: > Mike Baptiste wrote: > > I know some folks who put together 1TB file servers for < $5K > > They used Athlon motherboards and Promise RAID gear > > (http://www.promise.com/ATARaid/) > > Promise? Ouch. Especially if it is the "trick BIOS" FastTrak. > Even the SuperTrak is not _that_ good compared to the Adaptec 2400A > or the 3Ware Escaldes -- at least according to StorageReview.COM. > > The only time I've seen people having problems with 3Ware cards has > been when they change the default block size, use RAID-5 (which has > slow write performance anyway) or load older run-time monitoring > software while running with newer drivers and/or firmware. And use it in a SMP system or with a CPU watchdog enabled. This triggers the watchdog which otherwise would not. Cheers From owner-linux-xfs@oss.sgi.com Fri Aug 24 14:24:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OLO7R26162 for linux-xfs-outgoing; Fri, 24 Aug 2001 14:24:07 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-98.fl.sprintbbd.net [66.1.218.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OLO3d26142 for ; Fri, 24 Aug 2001 14:24:04 -0700 Received: from ieee.org (thebs.cc.absoval.com. [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id RAA28344; Fri, 24 Aug 2001 17:21:44 -0400 Message-ID: <3B86C52D.204F78F@ieee.org> Date: Fri, 24 Aug 2001 17:20:45 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Mike Baptiste , pac@fortuitous.com, linux-xfs@oss.sgi.com Subject: Re: Tera-Byte+ fileservers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > And use it in a SMP system or with a CPU watchdog enabled. > This triggers the watchdog which otherwise would not. Yeah. Do they work fine in SMP systems without a CPU watchdog? I've only used them in single processor systems. -- TheBS P.S. When you say "CPU watchdog" is that the kernel software watchdog, or a BIOS/CMOS setting? -- 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 From owner-linux-xfs@oss.sgi.com Fri Aug 24 14:36:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OLaiA26637 for linux-xfs-outgoing; Fri, 24 Aug 2001 14:36:44 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OLaed26616 for ; Fri, 24 Aug 2001 14:36:40 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA28498; Fri, 24 Aug 2001 23:36:38 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA23117; Fri, 24 Aug 2001 23:36:38 +0200 (CEST) Date: Fri, 24 Aug 2001 23:36:38 +0200 (CEST) From: Seth Mos To: Bryan-TheBS-Smith cc: Mike Baptiste , pac@fortuitous.com, linux-xfs@oss.sgi.com Subject: Re: Tera-Byte+ fileservers In-Reply-To: <3B86C52D.204F78F@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 24 Aug 2001, Bryan-TheBS-Smith wrote: > Seth Mos wrote: > > And use it in a SMP system or with a CPU watchdog enabled. > > This triggers the watchdog which otherwise would not. > > Yeah. Do they work fine in SMP systems without a CPU watchdog? As far as I can tell from messages on the list, yes. > I've only used them in single processor systems. I have not seen any reports yet about the 3ware card in a UNI proccesor with the software watchdog. > P.S. When you say "CPU watchdog" is that the kernel software > watchdog, or a BIOS/CMOS setting? The software watchdog. The more or less Bios versions (well it's mot really a bios). The hardware watchdog works as follows. You boot the machine and the kernel or a user application reads a address that is documented in the docs that came with the motherboard. (or it should). The first time you read this address the hardware watchdog is switched on and will watch that address for further reads. If this this does not happen within the timeout (that you specify in the bios) the watchdog/Bios will send a reset signal. I can think of the situation that during extremely heavy IO or CPU use the kernel or software watchdog can not read the address before the timeout and along comes your journaling fs to the rescue :-) It may be that the timeout is to small for your occasion and you need to make it higher. The motherboard I have starts at 10 secs and can go up to a minute. Although this seems long it will be better then having your box killed when it was in fact very busy. IIRC the limit of the software watchdog is 5 (!) seconds which might be the problem. It will also mean that you will have to wait longer before it reboots. Nice to see you around again. Cheers From owner-linux-xfs@oss.sgi.com Fri Aug 24 14:57:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OLvPA27339 for linux-xfs-outgoing; Fri, 24 Aug 2001 14:57:25 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-98.fl.sprintbbd.net [66.1.218.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OLvKd27317 for ; Fri, 24 Aug 2001 14:57:21 -0700 Received: from ieee.org (thebs.cc.absoval.com. [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id RAA28436; Fri, 24 Aug 2001 17:55:08 -0400 Message-ID: <3B86CD01.AA1B2D7A@ieee.org> Date: Fri, 24 Aug 2001 17:54:09 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Mike Baptiste , pac@fortuitous.com, linux-xfs@oss.sgi.com Subject: Re: Tera-Byte+ fileservers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > As far as I can tell from messages on the list, yes. Well, I'm going to find out. I'm upgrading an existing Abit BP6 / Dual-Celey 466MHz system (that has run a good 18 months) from: RedHat 6.2 2.2.18 & Ext3 0.0.6b (full data journaling) Built-in i440BX-PIIX4 JBOD To: RedHat 7.1 2.4.3 & XFS 1.0.1 3W-7800 RAID-0+1 (four disks to start) > The software watchdog. <... cut ...> I've used ISA/PCI add-on "hardware watchdogs" before. I have also played with the "software watchdog" before. Now are you saying there is a separate "CPU watchdog" that SMP-APIO chipset/mainboards have? If so, is this compiled in the default 2.4.3/XFS 1.0.1 kernels? If so, how do I deactivate it? > Nice to see you around again. I see your name all the time. So where do you remember my insignificant name from? BTW, I've been, more or less, "lurking" around here for awhile. But now that I'm doing Linux 100% of the time (see employer below, AVS ;-), I'm getting back to being on-list more. I've also stopped bothering with my local LUG **, which frees up a _lot_ of personal time too. -- TheBS ** Note: It's good to be involved with your local LUG. Except when the leadership (who are great bureaucrats, which is good for a non-profit organization I guess) continues to be a bunch of non-Linux using individuals. This is then compounded by the fact that they are the most prolific posters who constantly post technically incorrect stuff on-list like they are "experts." Because some get so offended no matter how hard you try to "be nice" when you correct them, most of the us real, experience Linux sysadmins have stopped bothering to post or attend meetings altogether. -- 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 From owner-linux-xfs@oss.sgi.com Fri Aug 24 15:11:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7OMBbg27893 for linux-xfs-outgoing; Fri, 24 Aug 2001 15:11:37 -0700 Received: from reefedge.reefedge.com (IDENT:root@reefedge.com [216.10.14.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OMBZd27874 for ; Fri, 24 Aug 2001 15:11:35 -0700 Received: (from tls@localhost) by reefedge.reefedge.com (8.10.1/8.10.1) id f7OMBYY10205 for linux-xfs@oss.sgi.com; Fri, 24 Aug 2001 18:11:34 -0400 Date: Fri, 24 Aug 2001 18:11:34 -0400 From: tls@reefedge.com To: linux-xfs@oss.sgi.com Subject: Re: About XFS-1.0.1 Kickstart Message-ID: <20010824181134.A10183@reefedge.com> References: <200108242055.f7OKtIp06801@xenon.niehs.nih.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200108242055.f7OKtIp06801@xenon.niehs.nih.gov>; from krahn@xenon.niehs.nih.gov on Fri, Aug 24, 2001 at 04:55:18PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 24, 2001 at 04:55:18PM -0400, Dr. Joe Krahn (Joe) wrote: > I think the DAC960 problem relates to devfs (causes a lot > of new-user problems and maybe should be optional.) > The RAID device names are different, such as: > /dev/rd/disc0/part1 on my system. > You can also try the kernel option devfs=nomount, > but this might also cause problems with other parts > of the install process. What DAC960 problem? My machine has only a DAC960, and I installed from the 1.0.1 image with no trouble. From owner-linux-xfs@oss.sgi.com Fri Aug 24 17:55:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7P0tgP32228 for linux-xfs-outgoing; Fri, 24 Aug 2001 17:55:42 -0700 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 f7P0ted32209 for ; Fri, 24 Aug 2001 17:55:40 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7P10v827498 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Fri, 24 Aug 2001 18:00:57 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA496607 for ; Sat, 25 Aug 2001 02:55:33 +0200 (CEST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA50193 for ; Fri, 24 Aug 2001 18:00:33 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 6190E15A210 for ; Fri, 24 Aug 2001 17:54:15 -0700 (PDT) Subject: corruption of in-memory data From: Florin Andrei To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 24 Aug 2001 17:54:15 -0700 Message-Id: <998700855.22891.43.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Running XFS-1.0.1, kernel-2.4.9 dual PIII, Mylex DAC960 with a large partition (100MB) mounted as /var When booting up the system, while mounting /var, i saw this: Start mounting filesystem: dac960(48,3) Ending clean XFS mount for filesystem: dac960(48,3) VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 208k freed Adding Swap: 1050616k swap-space (priority -1) Start mounting filesystem: dac960(48,4) Starting XFS recovery on filesystem: dac960(48,4) (dev: 48/4) Ending XFS recovery on filesystem: dac960(48,4) (dev: 48/4) xfs_force_shutdown(dac960(48,4),0x8) called from line 4072 of file xfs_bmap.c. Return address = 0xc01b8b9c Corruption of in-memory data detected. Shutting down filesystem: dac960(48,4) Please umount the filesystem, and rectify the problem(s) -- Florin Andrei From owner-linux-xfs@oss.sgi.com Fri Aug 24 21:13:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7P4DIn03143 for linux-xfs-outgoing; Fri, 24 Aug 2001 21:13:18 -0700 Received: from www.fortuitous.com (cs666824-51.austin.rr.com [66.68.24.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7P4DFd03124 for ; Fri, 24 Aug 2001 21:13:15 -0700 Received: by www.fortuitous.com (Postfix, from userid 500) id 48CE486A; Fri, 24 Aug 2001 23:10:18 -0500 (CDT) Date: Fri, 24 Aug 2001 23:10:18 -0500 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Re: Tera-Byte+ fileservers Message-ID: <20010824231018.A26691@bistro.marx> Reply-To: pac@fortuitous.com References: <20010824110841.A22894@bistro.marx> <20010824133620.A15818@cartman.smartware> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010824133620.A15818@cartman.smartware>; from sebastian.schoenwetter@hp.com on Fri, Aug 24, 2001 at 01:36:20PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Aug 24, 2001 at 01:36:20PM +0200, Sebastian Schoenwetter wrote: > Of course I am a bit biased :) but you can try out the "HP VA7100" virtual +array as your storage element. It supports Linux (or Windows) and works over +FibreChannel which is 1gigabit, you can even hook up multiple servers to the +same VA and assign diskspace for every machine individually. Sounds a bit expensive. Why can't I just buy my own Gigabit fiber card on a custon box:? I see gigabit fiber cards for under $200 on pricewatch.. is there a trick with fiber? What is the maximum bandwidth I could hope to get from IDE or Scsi? Im guessing that the cost of fiber switches is what makes it costly. -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 Sat Aug 25 05:10:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7PCAu209101 for linux-xfs-outgoing; Sat, 25 Aug 2001 05:10:56 -0700 Received: from kaperfahrt.nebelschwaden.de ([62.16.151.153]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7PCAqd09082 for ; Sat, 25 Aug 2001 05:10:53 -0700 Received: from nazgul.nebelschwaden.de (nazgul.nebelschwaden.de [172.16.36.10]) by kaperfahrt.nebelschwaden.de (Postfix) with ESMTP id E67AB16EF for ; Sat, 25 Aug 2001 14:10:44 +0200 (CEST) Received: from nebelschwaden.de (nazgul.nebelschwaden.de [172.16.36.10]) by nazgul.nebelschwaden.de (Postfix) with ESMTP id 6B8105844 for ; Sat, 25 Aug 2001 14:10:46 +0200 (CEST) Message-ID: <3B8795C6.8010201@nebelschwaden.de> Date: Sat, 25 Aug 2001 14:10:46 +0200 From: List Account Reply-To: listac@nebelschwaden.de User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010807 X-Accept-Language: de, en-us MIME-Version: 1.0 Cc: linux-xfs@oss.sgi.com Subject: ACL Permission Question References: <20010824110841.A22894@bistro.marx> <20010824133620.A15818@cartman.smartware> <20010824231018.A26691@bistro.marx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I wonder wether it is possible with XFS and ACLs to allow a group to write (copy, ...) a file into a folder (and subfolders thereof), but not delete files out of the folder(s). Basically, one may just put in the bucket, but not take out anything. I have played a bit with ACLs, but havent managed yet. Still, I am far away from really work with it "by heart.", so maybe I lack some basic understanding. Regards Thomas Weberstaedt From owner-linux-xfs@oss.sgi.com Sat Aug 25 09:23:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7PGN0U12504 for linux-xfs-outgoing; Sat, 25 Aug 2001 09:23:00 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7PGMrd12485 for ; Sat, 25 Aug 2001 09:22:53 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id A0DB73003CC; Sat, 25 Aug 2001 18:22:51 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.32 #1 (Debian)) id 15agCx-0000Cn-00 for ; Sat, 25 Aug 2001 18:22:51 +0200 Date: Sat, 25 Aug 2001 18:22:51 +0200 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Oops when installing floppy module Message-ID: <20010825182251.A739@ysabell.wh.vaih> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i X-Operating-System: Linux ysabell 2.4.9-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm having trouble while installing floppy.o (the computer doesn't have a floppy drive, and the floppy controller is disabled at the BIOS level). Right after installing floppy.o I see: floppy0: no floppy controllers found and the kernel oopses. The backtrace: Oops: 0002 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010092 eax: c0259fe4 ebx: 00000292 ecx: c2d55d58 edx: c88bb244 esi: 00000000 edi: c0297240 ebp: 00000000 esp: c2d55d50 Process modprobe (pid: 5879, stackpage=c2d55000) Stack: c029f734 00000000 00000000 00000046 c011a2f6 c0289fe4 c011756a c0117489 00000009 00000001 c0297280 fffffffe c0297280 c011726a c0297280 00000000 c0293900 00000000 c2d55db4 00000046 c010810d c0297e20 00000000 c2d55e6c Call trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 89 4a 04 89 54 24 08 8b 50 04 89 08 89 51 04 89 0a 89 00 89 >>EIP; c0117602 <__run_task_queue+12/60> <===== Trace; c011a2f6 Trace; c011756a Trace; c0117489 Trace; c011726a Trace; c010810d Trace; c0106cc4 Trace; c0216d82 Trace; c015554a Trace; c02173ab <- one of this two is wrong Trace; c02173ab <- I copied the wrong address Trace; c0217426 Trace; c0217444 Trace; c0115854 Trace; c014972a Trace; c0147a38 Trace; c012f5e6 Trace; c0106c3b Code; c0117602 <__run_task_queue+12/60> 00000000 <_EIP>: Code; c0117602 <__run_task_queue+12/60> <===== 0: 89 4a 04 mov %ecx,0x4(%edx) <===== Code; c0117605 <__run_task_queue+15/60> 3: 89 54 24 08 mov %edx,0x8(%esp,1) Code; c0117609 <__run_task_queue+19/60> 7: 8b 50 04 mov 0x4(%eax),%edx Code; c011760c <__run_task_queue+1c/60> a: 89 08 mov %ecx,(%eax) Code; c011760e <__run_task_queue+1e/60> c: 89 51 04 mov %edx,0x4(%ecx) Code; c0117611 <__run_task_queue+21/60> f: 89 0a mov %ecx,(%edx) Code; c0117613 <__run_task_queue+23/60> 11: 89 00 mov %eax,(%eax) Code; c0117615 <__run_task_queue+25/60> 13: 89 00 mov %eax,(%eax) the code that produces the message looks like this: if (have_no_fdc) { DPRINT("no floppy controllers found\n"); floppy_tq.routine = (void *)(void *) empty; mark_bh(IMMEDIATE_BH); schedule(); if (usage_count) floppy_release_irq_and_dma(); blk_cleanup_queue(BLK_DEFAULT_QUEUE(MAJOR_NR)); devfs_unregister_blkdev(MAJOR_NR,"fd"); } Does this look like something that might be specific to the XFS tree (2.4.9-xfs as of today) or should I report this to lkml? -- Marcelo From owner-linux-xfs@oss.sgi.com Sat Aug 25 09:28:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7PGSaJ12653 for linux-xfs-outgoing; Sat, 25 Aug 2001 09:28:36 -0700 Received: from tux.rsn.bth.se (root@tux.rsn.bth.se [194.47.143.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7PGSXd12634 for ; Sat, 25 Aug 2001 09:28:33 -0700 Received: from localhost (gandalf@localhost [127.0.0.1]) by localhost (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10) with ESMTP id f7PGTtN1022007; Sat, 25 Aug 2001 18:29:55 +0200 Date: Sat, 25 Aug 2001 18:29:55 +0200 (CEST) From: Martin Josefsson X-Sender: gandalf@tux.rsn.bth.se To: "Marcelo E. Magallon" cc: linux-xfs@oss.sgi.com Subject: Re: Oops when installing floppy module In-Reply-To: <20010825182251.A739@ysabell.wh.vaih> Message-ID: X-message-flag: Get yourself a real mail client! http://www.washington.edu/pine/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 25 Aug 2001, Marcelo E. Magallon wrote: > Hi, > > I'm having trouble while installing floppy.o (the computer doesn't > have a floppy drive, and the floppy controller is disabled at the BIOS > level). Right after installing floppy.o I see: > > floppy0: no floppy controllers found [snip Oops report] > Does this look like something that might be specific to the XFS tree > (2.4.9-xfs as of today) or should I report this to lkml? This is not specific to the XFS tree, infact it's a known bug. Sometimes it happens and sometimes not. I know that at least Alan Cox knows about it. Please go ahead and mail this to lkml, that way someone else might find out about it and fix it. /Martin From owner-linux-xfs@oss.sgi.com Sat Aug 25 11:09:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7PI9KM13632 for linux-xfs-outgoing; Sat, 25 Aug 2001 11:09:20 -0700 Received: from frodo.ezprohosting.com ([216.74.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7PI9Hd13613 for ; Sat, 25 Aug 2001 11:09:17 -0700 Received: from c922720-a.sttln1.wa.home.com ([65.0.77.21] helo=windows) by frodo.ezprohosting.com with smtp (Exim 3.20 #1) id 15ahru-0001I3-00 for linux-xfs@oss.sgi.com; Sat, 25 Aug 2001 14:09:14 -0400 Message-ID: <01b201c12d90$72e9f3c0$020144c0@windows> From: "Eric Peters" To: References: <200108242055.f7OKtIp06801@xenon.niehs.nih.gov> <3B86C267.8E4C951F@sgi.com> Subject: XFS/setfacl ordering bug still? Date: Sat, 25 Aug 2001 11:04:53 -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 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - frodo.ezprohosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - peters.org Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk # setfacl -R -m u:eric:rx /www gives a bunch of: setfacl: /www/vtc/www.vectortheater.org/inc: Resulting ACL `user::rwx,user:www:r-x,user:tim:rwx,user:er1c:rwx,user:jc:r-x,user:eric:r-x ,group::--x,mask::rwx,other::rwx': Missing or wrong entry at entry 3 Despite the acl_entry_sort(acl); additions, I'm getting this type of error - like when it 'sorts' the entry its doing so alphabetically? like it seems to me that its erroring because of the user: entries are infront of the group/mask/other right? so is this happening because the acl_entry_sort(acl); is doing it just alphabetically when it really should be not? (I'm running hte latest CVS copy of the 'cmd' - or were there perhaps some alterations in the kernel for this too? Eric From owner-linux-xfs@oss.sgi.com Sat Aug 25 22:12:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7Q5CtU21635 for linux-xfs-outgoing; Sat, 25 Aug 2001 22:12:55 -0700 Received: from frodo.ezprohosting.com ([216.74.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7Q5Cod21615 for ; Sat, 25 Aug 2001 22:12:50 -0700 Received: from c922720-a.sttln1.wa.home.com ([65.0.77.21] helo=windows) by frodo.ezprohosting.com with smtp (Exim 3.20 #1) id 15asE3-0004Vb-00 for linux-xfs@oss.sgi.com; Sun, 26 Aug 2001 01:12:47 -0400 Message-ID: <01e501c12ded$29585b40$020144c0@windows> From: "Eric Peters" To: References: <200108242055.f7OKtIp06801@xenon.niehs.nih.gov> <3B86C267.8E4C951F@sgi.com> <01b201c12d90$72e9f3c0$020144c0@windows> Subject: Re: XFS/setfacl ordering bug still? - I think I Fixed ---- I think :) - "patch" included Date: Sat, 25 Aug 2001 22:08:28 -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 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - frodo.ezprohosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - peters.org Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk After doing some gdb work and crap and downloading hte original setfacl port from http://acl.bestbits.at I noticed the acl_check function wasn't allowing more than one ACL_USER entry so: libacl.c line 73: case ACL_USER: if (state != ACL_USER) FAIL_CHECK (ACL_MISS_ERROR); if (ace->ae_id < qual || ace->ae_id == ACL_UNDEFINED_ID) FAIL_CHECK (ACL_DUPLICATE_ERROR); qual = ace->ae_id + 1; should become: case ACL_USER: if (state != ACL_USER) FAIL_CHECK (ACL_MISS_ERROR); if (ace->ae_id < qual || ace->ae_id == ACL_UNDEFINED_ID) FAIL_CHECK (ACL_DUPLICATE_ERROR); qual = ace->ae_id + 1; needs_mask = 1; break; And its kickin! At least its not spitting back pretty errors at me and my developers are able to rwx files :) Cheers! Eric ----- Original Message ----- From: "Eric Peters" To: Sent: Saturday, August 25, 2001 11:04 AM Subject: XFS/setfacl ordering bug still? > # setfacl -R -m u:eric:rx /www > > gives a bunch of: > > setfacl: /www/vtc/www.vectortheater.org/inc: Resulting ACL > `user::rwx,user:www:r-x,user:tim:rwx,user:er1c:rwx,user:jc:r-x,user:eric:r-x > ,group::--x,mask::rwx,other::rwx': Missing or wrong entry at entry 3 > > Despite the acl_entry_sort(acl); additions, I'm getting this type of > error - like when it 'sorts' the entry its doing so alphabetically? like it > seems to me that its erroring because of the user: entries are infront > of the group/mask/other right? > > so is this happening because the acl_entry_sort(acl); is doing it just > alphabetically when it really should be not? > > (I'm running hte latest CVS copy of the 'cmd' - or were there perhaps some > alterations in the kernel for this too? > > Eric > > From owner-linux-xfs@oss.sgi.com Sat Aug 25 22:45:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7Q5jaU22089 for linux-xfs-outgoing; Sat, 25 Aug 2001 22:45:36 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7Q5jXd22070 for ; Sat, 25 Aug 2001 22:45:33 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 93B65C00FC6 for ; Sun, 26 Aug 2001 13:45:38 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 181F6C00FBD for ; Sun, 26 Aug 2001 13:45:37 +0800 (PHT) Date: Sun, 26 Aug 2001 13:45:37 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: Tera-Byte+ fileservers In-Reply-To: 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, 24 Aug 2001 at 23:36, Seth Mos wrote: > I have not seen any reports yet about the 3ware card in a UNI > proccesor with the software watchdog. If by "software watchdog" you mean APIC and NMI Watchdog for uniprocessor support enabled in the kernel, then I'm one who has these two enabled. I use a 3ware 6400 with RAID5. Until kernel 2.4.9 I noticed that a drive going down would halt my system. With 2.4.9 I tried removing one (I have removable bays) and then rebuilt it, all without having to freeze, shutdown or whatever. Great, eh, for IDE? I haven't experienced a real hard drive failure since I used 2.4.9, though, as I did before which caused the hardware lockups. I don't know if pulling out the drive is a good enough simulation. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sun Aug 26 03:33:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7QAXjt25368 for linux-xfs-outgoing; Sun, 26 Aug 2001 03:33:45 -0700 Received: from zero.aec.at (qmailr@zero.aec.at [195.3.98.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7QAXfd25348 for ; Sun, 26 Aug 2001 03:33:42 -0700 Received: (qmail 6427 invoked by uid 99); 26 Aug 2001 10:33:39 -0000 Received: from unknown (HELO fred.muc.de) (unknown) by unknown with SMTP; 26 Aug 2001 10:33:39 -0000 Received: by fred.muc.de (Postfix, from userid 500) id 22592E2D57; Sun, 26 Aug 2001 12:33:54 +0200 (CEST) Date: Sun, 26 Aug 2001 12:33:53 +0200 From: Andi Kleen To: viro@math.psu.edu Cc: linux-xfs@oss.sgi.com Subject: 2.4.9 mount error handling problem Message-ID: <20010826123353.A11825@fred.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just tripped over a bug with 2.4.9+XFS, which I believe is a generic problem. For some unrelated reason the XFS ->read_super failed. After that every df caused an kernel oops in super.c/get_filesystem_info. MANGLE(tmp->mnt_sb->s_type->name); In this ->s_type was NULL. The error handling path of read_super sets s_type to NULL, but the super block was still in the list of some mount with that zero s_type. I unfortunately don't have time to track the exact cause down now, but I guess it should be debuggable with this information. -Andi -- Life would be so much easier if we could just look at the source code. From owner-linux-xfs@oss.sgi.com Sun Aug 26 11:10:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7QIAoH04314 for linux-xfs-outgoing; Sun, 26 Aug 2001 11:10:50 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7QIAld04295 for ; Sun, 26 Aug 2001 11:10:47 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA06986; Sun, 26 Aug 2001 20:10:43 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id UAA10207; Sun, 26 Aug 2001 20:10:43 +0200 (CEST) Date: Sun, 26 Aug 2001 20:10:42 +0200 (CEST) From: Seth Mos To: Federico Sevilla III cc: Linux XFS Mailing List Subject: Re: Tera-Byte+ fileservers 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, 26 Aug 2001, Federico Sevilla III wrote: > On Fri, 24 Aug 2001 at 23:36, Seth Mos wrote: > > I have not seen any reports yet about the 3ware card in a UNI > > proccesor with the software watchdog. > > If by "software watchdog" you mean APIC and NMI Watchdog for uniprocessor > support enabled in the kernel, then I'm one who has these two enabled. I > use a 3ware 6400 with RAID5. Until kernel 2.4.9 I noticed that a drive > going down would halt my system. With 2.4.9 I tried removing one (I have > removable bays) and then rebuilt it, all without having to freeze, > shutdown or whatever. Great, eh, for IDE? I haven't experienced a real > hard drive failure since I used 2.4.9, though, as I did before which > caused the hardware lockups. I don't know if pulling out the drive is a > good enough simulation. :) In that case I am going to add a note to the FAQ that it might be dangerous because the 3ware cards and 1.0 and 1.0.1 will probably not like each other if you switch it on. I will add a note that 2.4.9 and latter might work better then it does with the older kernel. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun Aug 26 11:56:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7QIuLC05001 for linux-xfs-outgoing; Sun, 26 Aug 2001 11:56:21 -0700 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 f7QIuId04982 for ; Sun, 26 Aug 2001 11:56:18 -0700 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 OAA01078; Sun, 26 Aug 2001 14:56:16 -0400 (EDT) Received: from localhost (viro@localhost) by weyl.math.psu.edu (8.9.3/8.9.3) with ESMTP id OAA26483; Sun, 26 Aug 2001 14:56:16 -0400 (EDT) X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs Date: Sun, 26 Aug 2001 14:56:15 -0400 (EDT) From: Alexander Viro To: Andi Kleen cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.9 mount error handling problem In-Reply-To: <20010826123353.A11825@fred.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 26 Aug 2001, Andi Kleen wrote: > > Hi, > > I just tripped over a bug with 2.4.9+XFS, which I believe is a generic > problem. For some unrelated reason the XFS ->read_super failed. After > that every df caused an kernel oops in super.c/get_filesystem_info. > > MANGLE(tmp->mnt_sb->s_type->name); > > In this ->s_type was NULL. The error handling path of read_super sets > s_type to NULL, but the super block was still in the list of some mount > with that zero s_type. > I unfortunately don't have time to track the exact cause down now, but I guess > it should be debuggable with this information. Does xfs_read_super(), by any chance, have an exit path where it * sets ->s_root, * fails _after_ that (i.e. past the point when we had successfully allocated root dentry) and * forgets to clean sb->s_root? From owner-linux-xfs@oss.sgi.com Sun Aug 26 16:55:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7QNtGv09116 for linux-xfs-outgoing; Sun, 26 Aug 2001 16:55:16 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7QNtCd09097 for ; Sun, 26 Aug 2001 16:55:12 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA08293 for ; Sun, 26 Aug 2001 16:53:26 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA2814984; Sun, 26 Aug 2001 18:53:55 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA51003; Sun, 26 Aug 2001 18:53:55 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7QNrEU11851; Sun, 26 Aug 2001 18:53:14 -0500 Message-Id: <200108262353.f7QNrEU11851@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alexander Viro cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: 2.4.9 mount error handling problem In-Reply-To: Message from Alexander Viro of "Sun, 26 Aug 2001 14:56:15 EDT." Date: Sun, 26 Aug 2001 18:53:14 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > On Sun, 26 Aug 2001, Andi Kleen wrote: > > > > > Hi, > > > > I just tripped over a bug with 2.4.9+XFS, which I believe is a generic > > problem. For some unrelated reason the XFS ->read_super failed. After > > that every df caused an kernel oops in super.c/get_filesystem_info. > > > > MANGLE(tmp->mnt_sb->s_type->name); > > > > In this ->s_type was NULL. The error handling path of read_super sets > > s_type to NULL, but the super block was still in the list of some mount > > with that zero s_type. > > I unfortunately don't have time to track the exact cause down now, but I gu > ess > > it should be debuggable with this information. > > Does xfs_read_super(), by any chance, have an exit path where it > * sets ->s_root, > * fails _after_ that (i.e. past the point when we had successfully > allocated root dentry) and > * forgets to clean sb->s_root? Yes it did, there was one way out which did that. Adding the dput and clear of the s_root field should fix it I think, although I did not go to the extent of replicating the failure. Thanks Steve From owner-linux-xfs@oss.sgi.com Sun Aug 26 17:18:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R0IhP09502 for linux-xfs-outgoing; Sun, 26 Aug 2001 17:18:43 -0700 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 f7R0Ifd09483 for ; Sun, 26 Aug 2001 17:18:41 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7R0O5806197 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Sun, 26 Aug 2001 17:24:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA511218 for ; Mon, 27 Aug 2001 02:18:33 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id TAA2817327 for ; Sun, 26 Aug 2001 19:17:14 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id TAA03394 for ; Sun, 26 Aug 2001 19:17:14 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f7R0GXl15132; Sun, 26 Aug 2001 19:16:33 -0500 Message-Id: <200108270016.f7R0GXl15132@jen.americas.sgi.com> Date: Sun, 26 Aug 2001 19:16:33 -0500 Subject: TAKE - fix error cleanup code in mount Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS was confusing the upper vfs layers during a failed mount. We need to clean s_root if a mount fails after we have set it. Date: Sun Aug 26 17:16:10 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101605a linux/fs/xfs/linux/xfs_super.c - 1.135 - Fix cleanup in failed mount case, plus a couple of out of mem cases during mount. From owner-linux-xfs@oss.sgi.com Sun Aug 26 17:19:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R0J2f09564 for linux-xfs-outgoing; Sun, 26 Aug 2001 17:19:02 -0700 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 f7R0Ixd09542 for ; Sun, 26 Aug 2001 17:19:00 -0700 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 f7R0OO806201 for ; Sun, 26 Aug 2001 17:24:24 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23373; Mon, 27 Aug 2001 11:17:37 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA45173; Mon, 27 Aug 2001 11:17:35 +1100 (AEDT) Date: Mon, 27 Aug 2001 11:17:35 +1100 From: Nathan Scott To: Eric Peters Cc: linux-xfs@oss.sgi.com Subject: Re: XFS/setfacl ordering bug still? - I think I Fixed ---- I think :) - "patch" included Message-ID: <20010827111734.A341817@wobbly.melbourne.sgi.com> References: <200108242055.f7OKtIp06801@xenon.niehs.nih.gov> <3B86C267.8E4C951F@sgi.com> <01b201c12d90$72e9f3c0$020144c0@windows> <01e501c12ded$29585b40$020144c0@windows> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01e501c12ded$29585b40$020144c0@windows>; from eric@peters.org on Sat, Aug 25, 2001 at 10:08:28PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sat, Aug 25, 2001 at 10:08:28PM -0700, Eric Peters wrote: > After doing some gdb work and crap and downloading hte original setfacl port > from http://acl.bestbits.at I noticed the acl_check function wasn't allowing > more than one ACL_USER entry so: > > libacl.c line 73: > case ACL_USER: > if (state != ACL_USER) > FAIL_CHECK (ACL_MISS_ERROR); > if (ace->ae_id < qual || ace->ae_id == > ACL_UNDEFINED_ID) > FAIL_CHECK (ACL_DUPLICATE_ERROR); > qual = ace->ae_id + 1; > should become: > case ACL_USER: > if (state != ACL_USER) > FAIL_CHECK (ACL_MISS_ERROR); > if (ace->ae_id < qual || ace->ae_id == > ACL_UNDEFINED_ID) > FAIL_CHECK (ACL_DUPLICATE_ERROR); > qual = ace->ae_id + 1; > needs_mask = 1; > break; > yup, thats clearly a bug. fixed, thanks. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 26 17:20:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R0Ksu09756 for linux-xfs-outgoing; Sun, 26 Aug 2001 17:20:54 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R0Kqd09737 for ; Sun, 26 Aug 2001 17:20:52 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA12142 for ; Sun, 26 Aug 2001 17:20:33 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA98363 for linux-xfs@oss.sgi.com; Mon, 27 Aug 2001 10:19:33 +1000 (EST) Date: Mon, 27 Aug 2001 10:19:33 +1000 (EST) From: Nathan Scott Message-Id: <200108270019.KAA98363@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Aug 26 17:19:03 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101606a cmd/acl/VERSION - 1.13 cmd/acl/debian/changelog - 1.8 cmd/acl/doc/CHANGES - 1.15 - bump the release number, document several fixed bugs. cmd/acl/libacl/libacl.c - 1.3 - fix a bug in acl_check ACL validity check code. From owner-linux-xfs@oss.sgi.com Sun Aug 26 17:50:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R0oDk10253 for linux-xfs-outgoing; Sun, 26 Aug 2001 17:50:13 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R0oAd10231 for ; Sun, 26 Aug 2001 17:50:10 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 326F6C00AC6 for ; Mon, 27 Aug 2001 08:50:19 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id B61B7C00AC1 for ; Mon, 27 Aug 2001 08:50:17 +0800 (PHT) Date: Mon, 27 Aug 2001 08:50:17 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: APIC, NMI Watchdog In-Reply-To: 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 Sun, 26 Aug 2001 at 20:10, Seth Mos wrote: > In that case I am going to add a note to the FAQ that it might be > dangerous because the 3ware cards and 1.0 and 1.0.1 will probably not > like each other if you switch it on. I will add a note that 2.4.9 and > latter might work better then it does with the older kernel. I am not quite sure if it happens with _all_ 3ware cards. Dan Yocum, who does more tests and has access to a wider variety of 3ware controllers, might want to corroborate my statements first before you add that FAQ entry. Aside from NMI Watchdog and the 3ware controller, it _might_ have been APIC (which is a prerequisite of the NMI Watchdog support) for uniprocessors and my VIA chipset. So many possibilities. Sometimes I wonder why I have both APIC and NMI Watchdog enabled. ;> But just in case you want to know what happened circa 2.4.6 to 2.4.8: o 2.4.6 ~ 2.4.7 (estimates, I'm not quite sure _when_ it started because my drive didn't fail with every kernel increment): data corruption that had to be xfs_repair'd. I sent e-mail to the list about this. o 2.4.8: system freeze but no data corruption. I didn't send e-mail to the list about this but just rebooted the machine. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sun Aug 26 19:44:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R2in112014 for linux-xfs-outgoing; Sun, 26 Aug 2001 19:44:49 -0700 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 f7R2ikd11994 for ; Sun, 26 Aug 2001 19:44:46 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7R2pAa17530 for ; Sun, 26 Aug 2001 19:51:11 -0700 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA57635; Mon, 27 Aug 2001 13:43:18 +1100 (EDT) Date: Mon, 27 Aug 2001 13:43:18 +1100 From: Timothy Shimmin To: List Account Cc: linux-xfs@oss.sgi.com Subject: Re: ACL Permission Question Message-ID: <20010827134318.B125742@boing.melbourne.sgi.com> References: <20010824110841.A22894@bistro.marx> <20010824133620.A15818@cartman.smartware> <20010824231018.A26691@bistro.marx> <3B8795C6.8010201@nebelschwaden.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3B8795C6.8010201@nebelschwaden.de>; from listac@nebelschwaden.de on Sat, Aug 25, 2001 at 02:10:46PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Thomas, On Sat, Aug 25, 2001 at 02:10:46PM +0200, List Account wrote: > Hi, > > I wonder wether it is possible with XFS and ACLs to allow a group to > write (copy, ...) a file into a folder (and subfolders thereof), but not > delete files out of the folder(s). Basically, one may just put in the > bucket, but not take out anything. > I don't believe so. The ACLs only use the standard permissions of rwx. However, I believe Connex do have a patch for extended ACLs with extra permissions (including deletion): "Change Permission", "Delete", and "Change Ownership". John Trostel (jtrostel@mindspring.com) informed me of their patch. BTW, general questions about ACLs (not XFS specific) are usually best directed at the ACL mailing list. web site: http://acl.bestbits.at/ mail subscription: http://acl.bestbits.at/mailman/listinfo/acl-devel Cheers, Tim. From owner-linux-xfs@oss.sgi.com Sun Aug 26 20:20:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R3K7A12638 for linux-xfs-outgoing; Sun, 26 Aug 2001 20:20:07 -0700 Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R3K2d12618 for ; Sun, 26 Aug 2001 20:20:02 -0700 Received: from jtsdell (user-38ld5s5.dialup.mindspring.com [209.86.151.133]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id XAA20601; Sun, 26 Aug 2001 23:20:00 -0400 (EDT) From: jtrostel@snapserver.com Message-ID: X-Mailer: XFMail 1.5.1 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010827134318.B125742@boing.melbourne.sgi.com> Date: Sun, 26 Aug 2001 23:20:24 -0400 (EDT) Reply-To: jtrostel@snapserver.com Organization: Snap Appliances To: XFS list Subject: Re: ACL Permission Question Cc: List Account Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, as Tim says we have made a patch which extends ACLs to include 'delete', 'change permissions', and 'take ownership'. I have gotten all but 'take ownership' to work fairly well with SAMBA. You might want to keep in mind that these permissions do fairly unexpected things to people and programs which expect 'normal' rwx-type behavior. For instance, you might have 'rwx' permissions but NOT be able to delete the file. You might be the owner and not be able to delete the file (until you change the 'delete' ACL of course). for example: [jt@jtsdell xfs_part]$ touch test.txt [jt@jtsdell xfs_part]$ ls -l test.txt -rw-rw-rw- 1 jt jt 0 Aug 26 23:15 test.txt [jt@jtsdell xfs_part]$ chmod o+rwx test.txt [jt@jtsdell xfs_part]$ ls -l test.txt -rw-rw-rwx 1 jt jt 0 Aug 26 23:15 test.txt [jt@jtsdell xfs_part]$ chacl -l test.txt test.txt [u::rw----,g::rwxdpo,o::rwx---,m::rw----] [jt@jtsdell xfs_part]$ rm test.txt rm: cannot unlink `test.txt': Permission denied so, the owner needs to change the ACLs to actually allow deletion (even by 'owner') [jt@jtsdell xfs_part]$ chacl u::rwxdpo,g::rwxdpo,o::rw----,m::rw---- test.txt [jt@jtsdell xfs_part]$ rm test.txt [jt@jtsdell xfs_part]$ Various other 'unexpected' behaviors can also occur. For this reason, this patch is in neither the mainstream XFS or in the mainstream SAMBA CVS trees. P.S. Connex has been acquired by Snap.... see the new e-mail address ;-> P.P.S I have the patches implemented up to 2.4.9pre4 so far. On 27-Aug-2001 Timothy Shimmin wrote: > Hi Thomas, > > On Sat, Aug 25, 2001 at 02:10:46PM +0200, List Account wrote: >> Hi, >> >> I wonder wether it is possible with XFS and ACLs to allow a group to >> write (copy, ...) a file into a folder (and subfolders thereof), but not >> delete files out of the folder(s). Basically, one may just put in the >> bucket, but not take out anything. >> > I don't believe so. > The ACLs only use the standard permissions of rwx. > However, I believe Connex do have a patch for extended ACLs with > extra permissions (including deletion): > "Change Permission", "Delete", and "Change Ownership". > John Trostel (jtrostel@mindspring.com) informed me of their patch. > > > BTW, general questions about ACLs (not XFS specific) are usually > best directed at the ACL mailing list. > web site: http://acl.bestbits.at/ > mail subscription: http://acl.bestbits.at/mailman/listinfo/acl-devel > > Cheers, > Tim. -- John M. Trostel Senior Software Engineer Quantum / SnapAppliances jtrostel@snapserver.com From owner-linux-xfs@oss.sgi.com Mon Aug 27 00:26:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R7Q0P16542 for linux-xfs-outgoing; Mon, 27 Aug 2001 00:26:00 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R7Psd16517 for ; Mon, 27 Aug 2001 00:25:54 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.2/8.11.2) with ESMTP id f7R7WeF27523 for ; Mon, 27 Aug 2001 09:32:40 +0200 Date: Mon, 27 Aug 2001 09:32:40 +0200 (CEST) From: Matteo Centonza To: Subject: xfsdump question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, that's the output from last night backup with amanda using xfsdump: FAILED AND STRANGE DUMP DETAILS: /-- xxxxx /home lev 0 STRANGE sendbackup: start [xxxxx:/home level 0] sendbackup: info BACKUP=/usr/sbin/xfsdump sendbackup: info RECOVER_CMD=/usr/sbin/xfsrestore -f... - sendbackup: info end | xfsdump: version 3.0 - Running single-threaded | xfsdump: saving user quota information for: /home | xfsdump: WARNING: overwriting: /home/xfsdump_quotas ? sh: xfsdq: command not found ? xfsdump: ERROR: xfsdq failed with exit status: 32512 ? xfsdump: ERROR: failed to save user quota information, continuing | xfsdump: level 0 dump of xxxxx.xxx.xx:/home | xfsdump: dump date: Mon Aug 27 00:28:11 2001 | xfsdump: session id: 8f57da27-3ed0-4f2f-9c71-ac67eef248e2 | xfsdump: session label: "" | xfsdump: ino map phase 1: skipping (no subtrees specified) | xfsdump: ino map phase 2: constructing initial dump list | xfsdump: ino map phase 3: skipping (no pruning necessary) | xfsdump: ino map phase 4: skipping (size estimated in phase 2) | xfsdump: ino map phase 5: skipping (only one dump stream) | xfsdump: ino map construction complete | xfsdump: estimated dump size: 6390738752 bytes | xfsdump: creating dump session media file 0 (media 0, file 0) | xfsdump: dumping ino map | xfsdump: dumping directories | xfsdump: dumping non-directory files | xfsdump: WARNING: could not open regular file ino 17048187 mode 0x000081a4: No such file or directory: not dumped | xfsdump: WARNING: could not open regular file ino 17048190 mode 0x000081a4: No such file or directory: not dumped | xfsdump: WARNING: could not open regular file ino 17109993 mode 0x000081a4: No such file or directory: not dumped | xfsdump: ending media file | xfsdump: media file size 6217415200 bytes | xfsdump: dump size (non-dir files) : 6188187768 bytes | xfsdump: dump complete: 1135 seconds elapsed sendbackup: size 6071695 sendbackup: end \-------- getting rid of quota informations which probably has a path problem, the strange thing is that xfsdump doesn't dump three files that i'm able to pick up with find: xxxxx:/home# find /home -inum 17048187 /xxxx/xxxxxx/.gnome/panel.d/default/Applet_7_Extern and so the remaining two. The same three files were mentioned in the last week backup as not dumped too. This filesystem is on a LVM'ed soft RAID5 array with quota enabled, using CVS copy as of 2001-07-24 (kernel 2.4.7, xfsdump 1.1.2-0). Ciao, -m From owner-linux-xfs@oss.sgi.com Mon Aug 27 00:25:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R7PTB16485 for linux-xfs-outgoing; Mon, 27 Aug 2001 00:25:29 -0700 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 f7R7PQd16466 for ; Mon, 27 Aug 2001 00:25:26 -0700 Received: from tmsgi7.humanmodeling.tecmath.de ([192.168.98.14]) by mail.hs.tecmath.com with esmtp (Exim 3.16 #1) id 15bGlt-0001QX-00 for linux-xfs@oss.sgi.com; Mon, 27 Aug 2001 09:25:21 +0200 Date: Mon, 27 Aug 2001 09:25:24 +0200 From: Martin Apel X-Sender: apel@tmsgi7.humanmodeling.tecmath.de To: linux-xfs@oss.sgi.com Subject: "getfh failed" again Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I tried moving some of my filesystems exported via NFS from ext2 to XFS. Unfortunately I had the same error message getfh failed: Operation not permitted when trying to mount the filesystem from an NFS client as previously discussed on this list. I compiled a 2.4.5 kernel with the XFS 1.0.1 patches using egcs egcs-2.91.66.1. Any help appreciated, Martin ________________________________________________________________________ Martin Apel, Dipl.-Inform. t e c m a t h A G Group Manager Software Development Human Solutions Division phone +49 (0)6301 606-300 Sauerwiesen 2, 67661 Kaiserslautern fax +49 (0)6301 606-309 Germany apel@hs.tecmath.com http://www.tecmath.com ________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Mon Aug 27 00:32:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R7WEc16808 for linux-xfs-outgoing; Mon, 27 Aug 2001 00:32:14 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R7WCd16789 for ; Mon, 27 Aug 2001 00:32:12 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA07132 for ; Mon, 27 Aug 2001 00:30:26 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA08655 for linux-xfs@oss.sgi.com; Mon, 27 Aug 2001 17:29:41 +1000 (EST) Date: Mon, 27 Aug 2001 17:29:41 +1000 (EST) From: Timothy Shimmin Message-Id: <200108270729.RAA08655@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfstests/common.dump Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Needed for xfstests/024. Date: Mon Aug 27 00:28:34 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101609a cmd/xfstests/common.dump - 1.12 - Add call to _stable_fs so that bstat's ctime and mtime will match with reality. From owner-linux-xfs@oss.sgi.com Mon Aug 27 00:56:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R7uTM17275 for linux-xfs-outgoing; Mon, 27 Aug 2001 00:56:29 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R7uPd17256 for ; Mon, 27 Aug 2001 00:56:25 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id C6F5EC001C5 for ; Mon, 27 Aug 2001 15:56:27 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 6B02BC00FA6 for ; Mon, 27 Aug 2001 15:56:26 +0800 (PHT) Date: Mon, 27 Aug 2001 15:56:26 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: "getfh failed" again In-Reply-To: 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 Mon, 27 Aug 2001 at 09:25, Martin Apel wrote: > I tried moving some of my filesystems exported via NFS from ext2 to > XFS. Unfortunately I had the same error message > getfh failed: Operation not permitted > when trying to mount the filesystem from an NFS client as previously > discussed on this list. I compiled a 2.4.5 kernel with the XFS 1.0.1 > patches using egcs egcs-2.91.66.1. I don't know how to fix this, but I'd like to let the list know of my setup which works: o Linux kernel 2.4.9 from the XFS CVS tree o NFSv3 using the kernel server v0.3.2 o Debian GNU/Linux sid (unstable tree) Things seem to work fine although I must admit that load is not that high yet. But mounting works, and transfer rates are almost wire speed. I use NFS mainly to transfer files to a workstation running a similar setup that takes care of burning ISOs. Unfortunately the system is not quite able to stream the ISOs, so I still need to copy them to a local hard drive. I will not have to do this when I upgrade to a BURN-Proof CD writer, though. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Aug 27 01:38:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R8cfX18412 for linux-xfs-outgoing; Mon, 27 Aug 2001 01:38:41 -0700 Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R8ccd18392 for ; Mon, 27 Aug 2001 01:38:38 -0700 Received: from rebel.net.au (dialup-7.rebel.net.au [203.20.69.77]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id SAA08777 for ; Mon, 27 Aug 2001 18:08:35 +0930 Message-ID: <3B8A087C.AFEC581F@rebel.net.au> Date: Mon, 27 Aug 2001 18:14:44 +0930 From: David Lloyd 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: GCC|KGCC + Redhat + Linux-2.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Compiling the Linus Linux Kernel 2.4.5 patched by SGI for XFS with the default gcc installed by RedHat appears to: * fail to unlink files (especially when using vim but other files, such as images, saved by Opera) Furthermore, it managed to corrupt my file system to the extent that I had to run xfs_repair in single user mode. I lost nothing, but... Interestingly, the prepackaged 2.4.3 release (i.e. SGI had compiled it) did not display this behaviour. FYI DSL -- MegaHAL: Linuxsa is not incorporated. User: Can an incorporated association send out a press release? MegaHAL: Linuxsa is a religion. - Quoting "megahal" (download: http://megahal.sourceforge.net/) From owner-linux-xfs@oss.sgi.com Mon Aug 27 02:33:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R9XCi19519 for linux-xfs-outgoing; Mon, 27 Aug 2001 02:33:12 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R9X9d19500 for ; Mon, 27 Aug 2001 02:33:09 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f7R9WuR01637; Mon, 27 Aug 2001 11:33:02 +0200 Message-Id: <4.3.2.7.2.20010827113044.03f34730@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 11:32:20 +0200 To: David Lloyd , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: GCC|KGCC + Redhat + Linux-2.4.5 In-Reply-To: <3B8A087C.AFEC581F@rebel.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 18:14 27-8-2001 +0930, David Lloyd wrote: >Compiling the Linus Linux Kernel 2.4.5 patched by SGI for XFS with the >default gcc installed by RedHat appears to: Don't use the redhat gcc on production systems. >* fail to unlink files (especially when using vim but other files, such >as images, saved by Opera) > >Furthermore, it managed to corrupt my file system to the extent that I >had to run xfs_repair in single user mode. I lost nothing, but... > >Interestingly, the prepackaged 2.4.3 release (i.e. SGI had compiled it) >did not display this behaviour. Probably because it included patches to make the kernel compile decently with their 2.96 compiler. Know issue. 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 Aug 27 02:47:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R9l0S19924 for linux-xfs-outgoing; Mon, 27 Aug 2001 02:47:00 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R9kpd19902 for ; Mon, 27 Aug 2001 02:46:52 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 2D8BAC001C5 for ; Mon, 27 Aug 2001 17:46:58 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id BFF80C00FA6 for ; Mon, 27 Aug 2001 17:46:56 +0800 (PHT) Date: Mon, 27 Aug 2001 17:46:56 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Errors building acl Debian packages 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 everyone, Using the latest CVS copy (synced just now), I'm experiencing the following when trying to build the acl package. I get to this by running "debian/rules build" from the cmd/acl directory: acl.c: In function `acl_verbose_abort': acl.c:176: `va_list' undeclared (first use in this function) acl.c:176: (Each undeclared identifier is reported only once acl.c:176: for each function it appears in.) acl.c:176: parse error before "ap" acl.c:177: warning: implicit declaration of function `va_start' acl.c:177: `ap' undeclared (first use in this function) acl.c:179: warning: implicit declaration of function `va_end' make[2]: *** [acl.lo] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.9-xfs-20010827/cmd/acl' make: *** [built] Error 2 I do not know if this will also happen if I use gcc-2.95, but currently I am using the latest gcc in sid, gcc-3.0.1-pre. I do not know if it has anything to do with that, but since the XFS team is aiming to get things seamlessly working with gcc-3.0, then here is the bug report. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Aug 27 02:56:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R9uFL20213 for linux-xfs-outgoing; Mon, 27 Aug 2001 02:56:15 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R9u6d20193 for ; Mon, 27 Aug 2001 02:56:07 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 38C19C001C5 for ; Mon, 27 Aug 2001 17:56:10 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id D7CE7C00FA6 for ; Mon, 27 Aug 2001 17:56:08 +0800 (PHT) Date: Mon, 27 Aug 2001 17:56:08 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: Errors building acl Debian packages In-Reply-To: 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 Follow-up to my problem building the acl package: I tested on a copy of the CVS tree dated 20010818 that I still have (also 2.4.9) and things build fine (acl, in particular). Must have been a recent take. Maybe someone can beat me to finding out which take caused this... --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Aug 27 02:56:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R9uL920271 for linux-xfs-outgoing; Mon, 27 Aug 2001 02:56:21 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R9uId20251 for ; Mon, 27 Aug 2001 02:56:18 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 06E921E12F; Mon, 27 Aug 2001 11:56:13 +0200 (MEST) Date: Mon, 27 Aug 2001 11:56:07 +0200 From: Andi Kleen To: Federico Sevilla III Cc: linux-xfs@oss.sgi.com Subject: Re: Errors building acl Debian packages Message-ID: <20010827115607.A6677@gruyere.muc.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jijo@leathercollection.ph on Mon, Aug 27, 2001 at 05:46:56PM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Aug 27, 2001 at 05:46:56PM +0800, Federico Sevilla III wrote: > acl.c: In function `acl_verbose_abort': > acl.c:176: `va_list' undeclared (first use in this function) [....] I just sent a patch for it to Tim 5 minutes ago. Here it is again. Index: acl/libacl/acl.c =================================================================== RCS file: /cvs/linux-2.4-xfs/cmd/acl/libacl/acl.c,v retrieving revision 1.15 diff -u -u -r1.15 acl.c --- acl/libacl/acl.c 2001/08/24 05:51:02 1.15 +++ acl/libacl/acl.c 2001/08/27 09:51:47 @@ -45,6 +45,7 @@ #include #include #include +#include #include -Andi From owner-linux-xfs@oss.sgi.com Mon Aug 27 03:00:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RA05j20554 for linux-xfs-outgoing; Mon, 27 Aug 2001 03:00:05 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RA00d20505 for ; Mon, 27 Aug 2001 03:00:01 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id E4F2CC001C5 for ; Mon, 27 Aug 2001 18:00:07 +0800 (PHT) Received: from gusi.leathercollection.local (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 79D3CC00FA6 for ; Mon, 27 Aug 2001 18:00:06 +0800 (PHT) Date: Mon, 27 Aug 2001 18:00:06 +0800 (PHT) From: Federico Sevilla III X-X-Sender: To: Linux XFS Mailing List Subject: Re: Errors building acl Debian packages In-Reply-To: <20010827115607.A6677@gruyere.muc.suse.de> 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 Mon, 27 Aug 2001 at 11:56, Andi Kleen wrote: > I just sent a patch for it to Tim 5 minutes ago. Here it is again. Wow ... hahaha. :) > +#include Great, that worked. Gracias! :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Mon Aug 27 05:44:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RCiuB23259 for linux-xfs-outgoing; Mon, 27 Aug 2001 05:44:56 -0700 Received: from mplspop4.mpls.uswest.net (mplspop4.mpls.uswest.net [204.147.80.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RCiqd23240 for ; Mon, 27 Aug 2001 05:44:53 -0700 Received: (qmail 19629 invoked from network); 27 Aug 2001 12:44:51 -0000 Received: from mplsdslgw15poolc32.mpls.uswest.net (HELO sgi.com) (63.229.198.32) by mplspop4.mpls.uswest.net with SMTP; 27 Aug 2001 12:44:51 -0000 Date: Mon, 27 Aug 2001 07:41:03 -0500 Message-ID: <3B8A3FDF.48AE6F9A@sgi.com> From: "Eric Sandeen" To: "David Lloyd" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: GCC|KGCC + Redhat + Linux-2.4.5 References: <3B8A087C.AFEC581F@rebel.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi David - Yes, using Red Hat's stock gcc has resulted in some strange behavior before. The hunch is that all of XFS's 64-bit code does not get along well with some versions of gcc. All of our RPMs were built with "kgcc" which is probably why they do not exhibit this behavior. -Eric David Lloyd wrote: > > Compiling the Linus Linux Kernel 2.4.5 patched by SGI for XFS with the > default gcc installed by RedHat appears to: > > * fail to unlink files (especially when using vim but other files, such > as images, saved by Opera) > > Furthermore, it managed to corrupt my file system to the extent that I > had to run xfs_repair in single user mode. I lost nothing, but... > > Interestingly, the prepackaged 2.4.3 release (i.e. SGI had compiled it) > did not display this behaviour. > > FYI > > DSL -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Aug 27 06:09:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RD9kh23808 for linux-xfs-outgoing; Mon, 27 Aug 2001 06:09:46 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RD9id23789 for ; Mon, 27 Aug 2001 06:09:44 -0700 Received: (qmail 83456 invoked from network); 27 Aug 2001 13:09:44 -0000 Received: from mplsdslgw15poolc32.mpls.uswest.net (HELO sgi.com) (63.229.198.32) by mplspop2.mpls.uswest.net with SMTP; 27 Aug 2001 13:09:44 -0000 Date: Mon, 27 Aug 2001 08:05:54 -0500 Message-ID: <3B8A45B2.D5590146@sgi.com> From: "Eric Sandeen" To: "Martin Apel" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: "getfh failed" again References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Martin - Would you be willing to try the latest version, either via cvs or with the 2.4.9 patch? If you're still having trouble, we can start doing some real debugging... Thanks, -Eric Martin Apel wrote: > I tried moving some of my filesystems exported via NFS from ext2 to > XFS. Unfortunately I had the same error message > getfh failed: Operation not permitted > when trying to mount the filesystem from an NFS client as previously > discussed on this list. I compiled a 2.4.5 kernel with the XFS 1.0.1 > patches using egcs egcs-2.91.66.1. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Aug 27 07:28:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RESHo25601 for linux-xfs-outgoing; Mon, 27 Aug 2001 07:28:17 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RESDd25582 for ; Mon, 27 Aug 2001 07:28:13 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 1C8A21AB15; Mon, 27 Aug 2001 10:28:12 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 87F7A6EE; Mon, 27 Aug 2001 10:28:11 -0400 (EDT) Date: Mon, 27 Aug 2001 10:28:11 -0400 From: Andrew Klaassen To: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: "raid5: multiple 1 requests for sector ..." Message-ID: <20010827102811.B24169@dkp.com> Mail-Followup-To: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com References: <20010817165205.B14697@dkp.com> <15238.10897.127840.647086@notabene.cse.unsw.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15238.10897.127840.647086@notabene.cse.unsw.edu.au> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS+RAID5... Below, Neil Brown says, "If I were the author of the filesystem I would be worried." Are the authors of the filesystem worried? ;) (I'm CCing this to both the linux-xfs and linux-raid lists; hope no-one minds...) Andrew Klaassen On Fri, Aug 24, 2001 at 08:21:05PM +1000, Neil Brown wrote: > On Friday August 17, ak@dkp.com wrote: > > kernel: raid5: multiple 1 requests for sector 32029440 > ... > > kernel: raid5: multiple 1 requests for sector 40 > > kernel: raid5: multiple 1 requests for sector 76260224 > > (etc) > On Friday August 24, eyal@eyal.emu.id.au wrote: > > I noticed this message recently. What does it mean? Is is harmfull? > > > > Running 2.4.9 with xfs. > It means that while raid5 had an outstanding write request on a > particular sector, it received another write request for the same > sector. > > It trys to do the right thing and write them both out in the order > that it received them, but it is a bit of a worry that any filesystem > would do this. I'm guessing that Andrew is using XFS too. Is that > right? > > While raid5 tries to keep the requests in order, and I suspect other > drivers do to, I don't think that it is reasonable to assume that no > device driver will ever re-order two requests for the same sector. > If I were the author of the filesystem I would be worried. > > NeilBrown From owner-linux-xfs@oss.sgi.com Mon Aug 27 07:34:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7REYwr25860 for linux-xfs-outgoing; Mon, 27 Aug 2001 07:34:58 -0700 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 f7REYtd25841 for ; Mon, 27 Aug 2001 07:34:55 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GIQDU500.5AB for ; Mon, 27 Aug 2001 09:34:53 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001082709345305901 for ; Mon, 27 Aug 2001 09:34:53 -0500 Message-ID: <3B8A5A8E.9173F95D@fnal.gov> Date: Mon, 27 Aug 2001 09:34:54 -0500 From: yocum@fnal.gov 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: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: <3B865EAF.8FCA6E59@fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk yocum@fnal.gov wrote: > > Seth Mos wrote: > > > > Back on topic: at least one data analyst moved about 40GB of data around > > > last night via NFS from OSF1 to Linux using NFVv3 and there were no inode > > > corruptions. The kernel being used *is* 2.4.8-xfs which was compiled with > > > gcc-2.96-85 (because I didn't get around to recompiling with kgcc yet, > > > mkp). > > > > If you see it again please recompile it if you can. Or find out what's > > going wrong with gcc 2.96. > > I have, and I'm re-compiling with kgcc as we speak. Hopefully this will fix > the problem. > > Unfortunately, there is nothing the logs that indicates a problem... gr. > > As always, I'll let you know if I continue to have the problem. *Big sigh* OK, I'm using my kgcc compiled 2.4.8-xfs kernel, and I'm still seeing inode corruption, even on a "static" filesystem (i.e., mounted noatime and no writes occuring). This is a very bad thing. I'm about to punt and reformat the entire partition as XFS, and if it happens again, then I'll have to reformat as ext2, which I really don't want to do since it's 1.12TB. If anyone has any ideas/patches please, please send 'em my way. 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 Mon Aug 27 07:45:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7REj8T26190 for linux-xfs-outgoing; Mon, 27 Aug 2001 07:45:08 -0700 Received: from mplspop6.mpls.uswest.net (mplspop6.mpls.uswest.net [204.147.80.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7REj6d26171 for ; Mon, 27 Aug 2001 07:45:06 -0700 Received: (qmail 7864 invoked from network); 27 Aug 2001 14:45:06 -0000 Received: from mplsdslgw15poolc32.mpls.uswest.net (HELO sgi.com) (63.229.198.32) by mplspop6.mpls.uswest.net with SMTP; 27 Aug 2001 14:45:06 -0000 Date: Mon, 27 Aug 2001 09:41:15 -0500 Message-ID: <3B8A5C0B.660040BC@sgi.com> From: "Eric Sandeen" To: yocum@fnal.gov Cc: "xfs-list" 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 Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: <3B865EAF.8FCA6E59@fnal.gov> <3B8A5A8E.9173F95D@fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Only thing I can think of is that this might be a >1TB problem? Trying to remember - have you done any tricks at mkfs time to keep inode numbers under 32 bits? -Eric yocum@fnal.gov wrote: > OK, I'm using my kgcc compiled 2.4.8-xfs kernel, and I'm still seeing inode > corruption, even on a "static" filesystem (i.e., mounted noatime and no > writes occuring). > > This is a very bad thing. > > I'm about to punt and reformat the entire partition as XFS, and if it > happens again, then I'll have to reformat as ext2, which I really don't want > to do since it's 1.12TB. > > If anyone has any ideas/patches please, please send 'em my way. > > Thanks, > Dan -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Aug 27 08:04:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RF4i526778 for linux-xfs-outgoing; Mon, 27 Aug 2001 08:04:44 -0700 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 f7RF4fd26759 for ; Mon, 27 Aug 2001 08:04:41 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GIQF7S00.R80 for ; Mon, 27 Aug 2001 10:04:40 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001082710044021278 ; Mon, 27 Aug 2001 10:04:40 -0500 Message-ID: <3B8A6188.94E3D3D@fnal.gov> Date: Mon, 27 Aug 2001 10:04:40 -0500 From: yocum@fnal.gov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: xfs-list Subject: Re: xfs_create looping, missing dirs/files, corrupt inode tables, etc. References: <3B865EAF.8FCA6E59@fnal.gov> <3B8A5A8E.9173F95D@fnal.gov> <3B8A5C0B.660040BC@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: > > Only thing I can think of is that this might be a >1TB problem? > > Trying to remember - have you done any tricks at mkfs time to keep inode > numbers under 32 bits? Lemme think. We talked about it, but in the end it wouldn't work with r1.0.1 for some unknown reason and I upgraded to CVS TOT and then 'mkfs.xfs /dev/md0' worked just fine. Dan > > -Eric > > yocum@fnal.gov wrote: > > > OK, I'm using my kgcc compiled 2.4.8-xfs kernel, and I'm still seeing inode > > corruption, even on a "static" filesystem (i.e., mounted noatime and no > > writes occuring). > > > > This is a very bad thing. > > > > I'm about to punt and reformat the entire partition as XFS, and if it > > happens again, then I'll have to reformat as ext2, which I really don't want > > to do since it's 1.12TB. > > > > If anyone has any ideas/patches please, please send 'em my way. > > > > Thanks, > > Dan > > -- > 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 Aug 27 12:16:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RJGxj00429 for linux-xfs-outgoing; Mon, 27 Aug 2001 12:16:59 -0700 Received: from anagyris.wanadoo.fr (smtp-rt-1.wanadoo.fr [193.252.19.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RJGpd00410 for ; Mon, 27 Aug 2001 12:16:52 -0700 Received: from mahonia.wanadoo.fr (193.252.19.58) by anagyris.wanadoo.fr; 27 Aug 2001 21:16:45 +0200 Received: from duron750.fdupoux.org (193.248.254.175) by mahonia.wanadoo.fr; 27 Aug 2001 21:16:39 +0200 Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?q?Fran=E7ois=20Dupoux?= To: linux-xfs@oss.sgi.com Subject: segfault in xfsprogs/xfs_db Date: Mon, 27 Aug 2001 21:16:47 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01082721164700.00907@duron750.fdupoux.org> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I had a segfault with xfs_db compiled from xfsprogs-1.3.5.src.tar.gz. Kernel 2.4.9, Redhat-7.1 The segfault happens when I run the command "freesp -d -s" with "xfs_db -x /dev/hdc5". This partition was formatted by mkfs.xfs. This is a 14.16 GB partition, with 5.34 GB used. duron750:/home/dupoux# xfs_db -x /dev/hdc5 xfs_db: freesp -d -s 0 43730 1 0 43731 1 0 43732 1 0 43733 1 0 43734 1 0 43735 1 Segmentation fault (core dumped) --------------- gdb /sbin/xfs_db core ------------------- GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `xfs_db -x /dev/hdc5'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 scanfunc_bno (ablock=0x0, typ=TYP_BNOBT, level=0, agf=0x80ab5e0) at /usr/include/linux/byteorder/swab.h:132 132 { -------------------------------------------------------- ------------ informations about /dev/hdc5 ------------- Block size....................4096 bytes Total blocks count............3710999 Used blocks count.............1400933 Free blocks count.............2310066 Space usage:..................37 % Total space:..................14.16 GB Used space....................5.34 GB Free space....................8.81 GB Bitmap size...................453.00 KB Allocation Group count:.......15 Blocks per Allocation Group...262144 Allocation Group size:........1.00 GB -------------------------------------------------------- You can download the core file from http://www.partimage.org/misc/core.gz It seems that the "freelist" is working, and it segfault at beginning of reading the btree (the BNO one). Here is the beginning of the result I d'like to obtain: --------------------------------------------------------- addToHist: 0 43730 1 addToHist: 0 43731 1 addToHist: 0 43732 1 addToHist: 0 43733 1 addToHist: 0 43734 1 addToHist: 0 43735 1 addToHist: 0 12 1 addToHist: 0 54 247 addToHist: 0 325 89 addToHist: 0 566 25 addToHist: 0 628 821 addToHist: 0 1465 11 addToHist: 0 1813 159 addToHist: 0 1976 1 ...... --------------------------------------------------------- The partition was very fragmented. There is no problem when reading files from the mount point. (I am using the patch XFS-2001-08-19 for 2.4.9). Here is how I made this 14 GB partition: mkfs.xfs /dev/hdc5 mount /dev/hdc5 /mnt/ess cd /mnt/ess createdata -d6 . mv a r mv b s createdata -d6 . umount /mnt/ess createdata is a small program which creates a lot of files of a random size, with random data. It fills the partition. When there is no space left, it erases a lot of files (it keeps 1 file for 6 files when the option -d6 is used). It's very useful to make a fragmented file system. You can download the source code on http://www.partimage.org/misc/createdata.cpp. I already had the same problem, after formatting and filling this partition with the same method (other random files) thanks From owner-linux-xfs@oss.sgi.com Mon Aug 27 12:58:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RJwbN01450 for linux-xfs-outgoing; Mon, 27 Aug 2001 12:58:37 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RJwZd01431 for ; Mon, 27 Aug 2001 12:58:35 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA06143 for ; Mon, 27 Aug 2001 12:58:33 -0700 (PDT) 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 OAA2822788 for ; Mon, 27 Aug 2001 14:57:15 -0500 (CDT) 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 OAA25032 for ; Mon, 27 Aug 2001 14:57:15 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7RJtra26451; Mon, 27 Aug 2001 14:55:53 -0500 Message-Id: <200108271955.f7RJtra26451@stout.americas.sgi.com> Date: Mon, 27 Aug 2001 14:55:53 -0500 From: Eric Sandeen Subject: TAKE - pre-allocated buffer heads in pagebuf / OOM Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS doesn't like asking for memory and not getting any. This mod adds a pre-allocated pool of NR_RESERVED_BH (64) buffer heads for pagebuf to use; if a normal buffer head allocation request fails, it will draw from this pool to make sure XFS gets what it wants. If the pool is empty, the process will sleep until some get returned to the pool. Even restricting XFS to _ONLY_ getting buffer heads from this pool, a filesystem will still mount & pass a small fsstress run, so hopefully this will be enough to get us out of sticky situations. If people have been having XFS OOM problems, please give this a shot and see if it helps. Date: Mon Aug 27 12:48:45 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101656a linux/fs/pagebuf/page_buf.c - 1.98 - Add pre-allocated buffer head pool for low memory situations From owner-linux-xfs@oss.sgi.com Mon Aug 27 15:39:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RMd5904897 for linux-xfs-outgoing; Mon, 27 Aug 2001 15:39:05 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RMd0d04876 for ; Mon, 27 Aug 2001 15:39:00 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA05287 for ; Mon, 27 Aug 2001 15:37:15 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2827392; Mon, 27 Aug 2001 17:37:43 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA34767; Mon, 27 Aug 2001 17:37:43 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7RMarn16012; Mon, 27 Aug 2001 17:36:53 -0500 Message-Id: <200108272236.f7RMarn16012@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Klaassen cc: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: "raid5: multiple 1 requests for sector ..." In-Reply-To: Message from Andrew Klaassen of "Mon, 27 Aug 2001 10:28:11 EDT." <20010827102811.B24169@dkp.com> Date: Mon, 27 Aug 2001 17:36:51 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > XFS+RAID5... > > Below, Neil Brown says, "If I were the author of the filesystem > I would be worried." > > Are the authors of the filesystem worried? ;) I responded to this when the original message went out, and no one followed up on my suggestions. I am currently on the other side of the Pacific ocean and have too a heavy meeting schedule to get involved in this right now, maybe Eric can dig out my original message to the xfs list and resend it. Steve > > (I'm CCing this to both the linux-xfs and linux-raid lists; hope > no-one minds...) > > Andrew Klaassen > > > On Fri, Aug 24, 2001 at 08:21:05PM +1000, > Neil Brown wrote: > > > On Friday August 17, ak@dkp.com wrote: > > > > kernel: raid5: multiple 1 requests for sector 32029440 > > ... > > > kernel: raid5: multiple 1 requests for sector 40 > > > kernel: raid5: multiple 1 requests for sector 76260224 > > > (etc) > > > On Friday August 24, eyal@eyal.emu.id.au wrote: > > > > I noticed this message recently. What does it mean? Is is harmfull? > > > > > > Running 2.4.9 with xfs. > > > It means that while raid5 had an outstanding write request on a > > particular sector, it received another write request for the same > > sector. > > > > It trys to do the right thing and write them both out in the order > > that it received them, but it is a bit of a worry that any filesystem > > would do this. I'm guessing that Andrew is using XFS too. Is that > > right? > > > > While raid5 tries to keep the requests in order, and I suspect other > > drivers do to, I don't think that it is reasonable to assume that no > > device driver will ever re-order two requests for the same sector. > > If I were the author of the filesystem I would be worried. > > > > NeilBrown From owner-linux-xfs@oss.sgi.com Mon Aug 27 15:42:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RMgTu05053 for linux-xfs-outgoing; Mon, 27 Aug 2001 15:42:29 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RMgPd05034 for ; Mon, 27 Aug 2001 15:42:26 -0700 Received: (qmail 25928 invoked by uid 8); 27 Aug 2001 22:42:24 -0000 From: Juri Haberland Reply-To: Juri Haberland X-Newsgroups: spoiled.linux.sgi.xfs Subject: Lockup since 2.4.4 when switching from X to console Date: Mon, 27 Aug 2001 22:42:24 +0000 (UTC) Organization: spoiled dot org Lines: 29 Distribution: local Message-ID: X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (OpenBSD/2.9 (i386)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi list, I started using XFS with the RH-7.1-XFS release. No Problems at all - great work! I then upgraded to the 2.4.3 release - again no problems. A following attempt to upgrade the kernel to 2.4.4 using CVS and all later releases lead to a complete lockup when switching from X to the console. First I tried to eliminate the obvious possibilities for that problem: - disabling all unneeded drivers - disabling framebuffer - compiling for a generic i386 and so on, but to no avail. Then I converted all my filesystems back to ext2 and compiled the newest "vanilla" kernel 2.4.9. No problems whatsoever... I did again a cvs checkout and compiled a 2.4.9-xfs with the .config from my previous 2.4.9-vanilla kernel without XFS. Again complete lockup. On all test I used the kgcc. Every time besides the last (2.4.9) test I compiled the XFS-enabled kernel with kdb, but not even the kdb kicked in. Any hints on how to debug? I really would like to use XFS on this system... Cheers, Juri -- Juri Haberland From owner-linux-xfs@oss.sgi.com Mon Aug 27 16:15:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RNFd305769 for linux-xfs-outgoing; Mon, 27 Aug 2001 16:15:39 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RNFbd05750 for ; Mon, 27 Aug 2001 16:15:37 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 2502B1AB10; Mon, 27 Aug 2001 19:15:36 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 2353E6EE; Mon, 27 Aug 2001 19:15:34 -0400 (EDT) Date: Mon, 27 Aug 2001 19:15:34 -0400 From: Andrew Klaassen To: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: "raid5: multiple 1 requests for sector ..." Message-ID: <20010827191534.B28680@dkp.com> Mail-Followup-To: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com References: <200108272236.f7RMarn16012@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200108272236.f7RMarn16012@jen.americas.sgi.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Aug 27, 2001 at 05:36:51PM -0500, Steve Lord wrote: > I responded to this when the original message went out, and no > one followed up on my suggestions. I am currently on the other > side of the Pacific ocean and have too a heavy meeting > schedule to get involved in this right now, maybe Eric can dig > out my original message to the xfs list and resend it. Mmm... yes. Sorry - missed that the first time around. A couple of things: - I'm not sure I'll have a chance to do a recompile and reboot on the server any time soon (I'll do so if I get the chance, though)... - The errors haven't occured for a couple of days, and I'm not sure if they'll come back... - The box doesn't crash, so I'm not sure how I'd do a backtrace and get you the info you need even if the errors do show up again... Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Aug 27 16:28:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7RNSiS06027 for linux-xfs-outgoing; Mon, 27 Aug 2001 16:28:44 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7RNSfd06008 for ; Mon, 27 Aug 2001 16:28:41 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id C2F761AB10 for ; Mon, 27 Aug 2001 19:28:40 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 4CD256EE; Mon, 27 Aug 2001 19:28:40 -0400 (EDT) Date: Mon, 27 Aug 2001 19:28:39 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: "raid5: multiple 1 requests for sector ..." Message-ID: <20010827192839.A7064@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200108272236.f7RMarn16012@jen.americas.sgi.com> <20010827191534.B28680@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010827191534.B28680@dkp.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Aug 27, 2001 at 07:15:34PM -0400, I wrote: > - The box doesn't crash... ...though I do see that 1/2 an hour later the logs report: kernel: I/O error in filesystem ("md(9,2)") meta-data dev 0x903 block 0x13fbe kernel: ("") error -1070893103 buf count 5 kernel: xfs_force_shutdown(md(9,2),0x2) called from line 940 of file xfs_log.c. Return address = 0xc01c329c kernel: Log I/O Error Detected. Shutting down filesystem: md(9,2) kernel: Please umount the filesystem, and rectify the problem(s) I've got no idea if this might be related or not. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Aug 27 20:10:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S3AMP09568 for linux-xfs-outgoing; Mon, 27 Aug 2001 20:10:22 -0700 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 f7S3AId09548 for ; Mon, 27 Aug 2001 20:10:18 -0700 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 f7S3Fi802160 for ; Mon, 27 Aug 2001 20:15:45 -0700 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA11235 for linux-xfs@oss.sgi.com; Tue, 28 Aug 2001 13:10:08 +1000 Date: Tue, 28 Aug 2001 13:10:08 +1000 From: Tim Shimmin Message-Id: <200108280310.NAA11235@sherman.melbourne.sgi.com> Subject: TAKE - libacl/acl.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Aug 27 20:08:13 PDT 2001 Workarea: sherman.melbourne.sgi.com:/hosts/snort/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:101701a cmd/acl/libacl/acl.c - 1.16 - Adding header for Andi K. for SuSE. From owner-linux-xfs@oss.sgi.com Mon Aug 27 20:34:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S3YrH09994 for linux-xfs-outgoing; Mon, 27 Aug 2001 20:34:53 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7S3Yod09974 for ; Mon, 27 Aug 2001 20:34:51 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.4/8.11.4) id f7S3Yio26797 for linux-xfs@oss.sgi.com; Mon, 27 Aug 2001 23:34:44 -0400 Date: Mon, 27 Aug 2001 23:34:44 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: Re: TAKE - libacl/acl.c Message-ID: <20010827233444.A26794@wwweasel.geeksrus.net> References: <200108280310.NAA11235@sherman.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: <200108280310.NAA11235@sherman.melbourne.sgi.com>; from tes@sherman.melbourne.sgi.com on Tue, Aug 28, 2001 at 01:10:08PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Aug 28, 2001 at 01:10:08PM +1000, Tim Shimmin wrote: >Date: Mon Aug 27 20:08:13 PDT 2001 >Workarea: sherman.melbourne.sgi.com:/hosts/snort/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:101701a >cmd/acl/libacl/acl.c - 1.16 > - Adding header for Andi K. for SuSE. > It's not just SuSE. The stuff won't link on RH either. In fact, it probably should not compile cleanly on any system, and probably will not link anywhere since those are compiler builtins. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Mon Aug 27 21:23:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S4NAP10794 for linux-xfs-outgoing; Mon, 27 Aug 2001 21:23:10 -0700 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 f7S4N8d10769 for ; Mon, 27 Aug 2001 21:23:08 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7S4TYa32278 for ; Mon, 27 Aug 2001 21:29:34 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA20489; Tue, 28 Aug 2001 14:22:54 +1000 Date: Tue, 28 Aug 2001 14:22:54 +1000 From: Keith Owens Message-Id: <200108280422.OAA20489@sherman.melbourne.sgi.com> Subject: TAKE - Remove unused warning message without quotas Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove unused warning message without quotas Date: Mon Aug 27 21:21:45 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101702a linux/Documentation/mips/pci/pci.README - 1.1 linux/drivers/tc/lk201-map.map - 1.1 linux/drivers/tc/lk201-remap.c - 1.1 linux/drivers/tc/lk201.c - 1.1 linux/drivers/tc/lk201.h - 1.1 linux/fs/xfs/linux/xfs_super.c - 1.136 From owner-linux-xfs@oss.sgi.com Mon Aug 27 21:25:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S4Pmk10866 for linux-xfs-outgoing; Mon, 27 Aug 2001 21:25:48 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7S4Pid10847 for ; Mon, 27 Aug 2001 21:25:44 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA01716 for ; Mon, 27 Aug 2001 21:25:43 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA20836; Tue, 28 Aug 2001 14:25:41 +1000 Date: Tue, 28 Aug 2001 14:25:41 +1000 From: Keith Owens Message-Id: <200108280425.OAA20836@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to 2.4.10-pre1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade to 2.4.10-pre1 Date: Mon Aug 27 21:24:15 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101703a linux/mm/memory.c - 1.56 linux/kernel/signal.c - 1.18 linux/kernel/ksyms.c - 1.101 linux/include/linux/kernel.h - 1.22 linux/include/asm-alpha/keyboard.h - 1.5 linux/fs/umsdos/emd.c - 1.8 linux/fs/inode.c - 1.48 linux/drivers/usb/Makefile - 1.39 linux/drivers/usb/Config.in - 1.43 linux/drivers/sgi/char/usema.c - 1.8 linux/drivers/sgi/char/shmiq.c - 1.16 linux/drivers/sgi/char/sgiserial.h - 1.4 linux/drivers/sgi/char/sgiserial.c - 1.9 linux/drivers/sgi/char/sgicons.c - 1.5 linux/drivers/sgi/char/rrm.c - 1.5 linux/drivers/sgi/char/newport.c - 1.6 linux/drivers/sgi/char/graphics.c - 1.15 linux/arch/i386/defconfig - 1.64 linux/arch/alpha/kernel/alpha_ksyms.c - 1.25 linux/Makefile - 1.115 linux/MAINTAINERS - 1.69 linux/Documentation/Configure.help - 1.94 linux/Documentation/00-INDEX - 1.11 linux/drivers/tc/zs.h - 1.3 linux/drivers/tc/zs.c - 1.6 linux/drivers/tc/tcsyms.c - 1.3 linux/drivers/tc/tc.c - 1.5 linux/drivers/sgi/char/graphics_syms.c - 1.4 linux/drivers/sgi/char/ds1286.c - 1.9 linux/drivers/pci/names.c - 1.9 linux/drivers/atm/Makefile - 1.13 linux/include/asm-i386/kmap_types.h - 1.4 linux/drivers/char/drm/drmP.h - 1.13 linux/include/linux/pci_ids.h - 1.43 linux/include/linux/highmem.h - 1.13 linux/include/linux/agp_backend.h - 1.11 linux/drivers/char/drm/tdfx_drv.c - 1.10 linux/drivers/char/agp/agpgart_be.c - 1.21 linux/drivers/char/agp/agp.h - 1.14 linux/fs/cramfs/inode.c - 1.17 linux/drivers/sound/awe_wave.c - 1.8 linux/drivers/ide/via82cxxx.c - 1.15 linux/drivers/char/drm/r128_drv.h - 1.7 linux/drivers/char/drm/mga_drv.h - 1.7 linux/drivers/atm/firestream.c - 1.4 linux/drivers/atm/firestream.h - 1.3 linux/drivers/char/drm/r128_cce.c - 1.4 linux/drivers/char/drm/radeon_cp.c - 1.4 linux/drivers/char/drm/radeon_drv.h - 1.3 linux/drivers/net/wireless/airport.c - 1.3 linux/fs/ntfs/unistr.c - 1.3 linux/drivers/char/drm/drm_ioctl.h - 1.2 linux/drivers/char/drm/drm_vm.h - 1.3 linux/drivers/char/drm/drm_scatter.h - 1.3 linux/drivers/char/drm/drm_agpsupport.h - 1.2 linux/drivers/char/drm/ati_pcigart.h - 1.3 linux/drivers/usb/kaweth.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Aug 27 21:56:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S4uCo11346 for linux-xfs-outgoing; Mon, 27 Aug 2001 21:56:12 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7S4uAd11327 for ; Mon, 27 Aug 2001 21:56:10 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA14837 for ; Mon, 27 Aug 2001 21:55:51 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA32757; Tue, 28 Aug 2001 14:56:02 +1000 Date: Tue, 28 Aug 2001 14:56:02 +1000 From: Keith Owens Message-Id: <200108280456.OAA32757@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kdb Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sync with kdb Date: Mon Aug 27 21:54:07 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101704a linux/drivers/char/Makefile - 1.46 From owner-linux-xfs@oss.sgi.com Mon Aug 27 22:23:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S5NeU11971 for linux-xfs-outgoing; Mon, 27 Aug 2001 22:23:40 -0700 Received: from exocore.com ([202.4.185.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7S5NZd11948 for ; Mon, 27 Aug 2001 22:23:35 -0700 Received: (from shanu@localhost) by exocore.com (8.11.2/8.11.2) id f7S5Ncm04711 for linux-xfs@oss.sgi.com; Tue, 28 Aug 2001 10:53:38 +0530 Date: Tue, 28 Aug 2001 10:53:37 +0530 From: Shanker Balan To: Linux-XFS Subject: Umask bug in the Installer - Solved? Message-ID: <20010828105337.A4688@exocore.com> Reply-To: Shanker Balan Mail-Followup-To: Linux-XFS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organisation: Exocore Consulting (P) Ltd Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello: This is with reference to the RHL-XFS 1.0.1 installer which created files under /etc with world read/write perms and one had to run the fix-perms.sh script to restore sane permissions. Has this issue been resolved in the Installer ISO? -- Shanu -- ------------------------------------------( Shanu )------------------- Shanker Balan http://people.exocore.com/shanu A Microsoft Certified Systems Engineer is to computing what a McDonalds Certified Food Specialist is to fine cuisine ---------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Aug 27 22:28:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S5S4N12200 for linux-xfs-outgoing; Mon, 27 Aug 2001 22:28:04 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7S5S2d12181 for ; Mon, 27 Aug 2001 22:28:02 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA00550; Tue, 28 Aug 2001 07:28:00 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA00662; Tue, 28 Aug 2001 07:28:00 +0200 (CEST) Date: Tue, 28 Aug 2001 07:27:59 +0200 (CEST) From: Seth Mos To: Shanker Balan cc: Linux-XFS Subject: Re: Umask bug in the Installer - Solved? In-Reply-To: <20010828105337.A4688@exocore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 28 Aug 2001, Shanker Balan wrote: > Hello: > > This is with reference to the RHL-XFS 1.0.1 installer which created > files under /etc with world read/write perms and one had to run the > fix-perms.sh script to restore sane permissions. > > Has this issue been resolved in the Installer ISO? Not sure, Eric Sandeen knows. Cheers Seth From owner-linux-xfs@oss.sgi.com Mon Aug 27 22:34:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S5Y0U12395 for linux-xfs-outgoing; Mon, 27 Aug 2001 22:34:00 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7S5Xvd12376 for ; Mon, 27 Aug 2001 22:33:57 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA01120; Tue, 28 Aug 2001 07:33:56 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA00923; Tue, 28 Aug 2001 07:33:56 +0200 (CEST) Date: Tue, 28 Aug 2001 07:33:56 +0200 (CEST) From: Seth Mos To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: "raid5: multiple 1 requests for sector ..." In-Reply-To: <20010827192839.A7064@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 Mon, 27 Aug 2001, Andrew Klaassen wrote: > On Mon, Aug 27, 2001 at 07:15:34PM -0400, > I wrote: > > > - The box doesn't crash... > > ...though I do see that 1/2 an hour later the logs report: > > kernel: I/O error in filesystem ("md(9,2)") meta-data dev 0x903 block 0x13fbe > kernel: ("") error -1070893103 buf count 5 > kernel: xfs_force_shutdown(md(9,2),0x2) called from line 940 of file xfs_log.c. Return address = 0xc01c329c > kernel: Log I/O Error Detected. Shutting down filesystem: md(9,2) > kernel: Please umount the filesystem, and rectify the problem(s) > > I've got no idea if this might be related or not. It seems so related to the problems you mentioned earlier that you would almost think so. It doesn't have to be perse. What was the kernel and with what compiler? I remember you saw this with a OSF1 nfs client? I'll have to look this up when I get to work. Cheers From owner-linux-xfs@oss.sgi.com Tue Aug 28 00:07:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S77wp14210 for linux-xfs-outgoing; Tue, 28 Aug 2001 00:07:58 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7S77qd14190 for ; Tue, 28 Aug 2001 00:07:52 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id AAA09958 for ; Tue, 28 Aug 2001 00:07:43 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28696; Tue, 28 Aug 2001 18:06:24 +1100 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id RAA28258; Tue, 28 Aug 2001 17:06:24 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Tue, 28 Aug 2001 17:06:23 +1000 To: Matteo Centonza cc: Subject: Re: xfsdump question 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, 27 Aug 2001, Matteo Centonza wrote: > | xfsdump: saving user quota information for: /home > | xfsdump: WARNING: overwriting: /home/xfsdump_quotas > ? sh: xfsdq: command not found > ? xfsdump: ERROR: xfsdq failed with exit status: 32512 > ? xfsdump: ERROR: failed to save user quota information, continuing xfsdump assumes /sbin is in root's path. If it isn't, it probably should be. If it is, then be sure that xfsdq is there. > | xfsdump: dumping non-directory files > | xfsdump: WARNING: could not open regular file ino 17048187 mode > 0x000081a4: No such file or directory: not dumped > | xfsdump: WARNING: could not open regular file ino 17048190 mode > 0x000081a4: No such file or directory: not dumped > | xfsdump: WARNING: could not open regular file ino 17109993 mode > 0x000081a4: No such file or directory: not dumped > | xfsdump: ending media file > | xfsdump: media file size 6217415200 bytes > | xfsdump: dump size (non-dir files) : 6188187768 bytes > | xfsdump: dump complete: 1135 seconds elapsed > sendbackup: size 6071695 > sendbackup: end > \-------- > > getting rid of quota informations which probably has a path problem, > the strange thing is that xfsdump doesn't dump three files that i'm > able to pick up with find: > > xxxxx:/home# find /home -inum 17048187 > /xxxx/xxxxxx/.gnome/panel.d/default/Applet_7_Extern > > and so the remaining two. The same three files were mentioned in the last > week backup as not dumped too. > This filesystem is on a LVM'ed soft RAID5 array with quota enabled, using > CVS copy as of 2001-07-24 (kernel 2.4.7, xfsdump 1.1.2-0). Hm, this is a bit odd. One might expect these failures if xfsdump were running on a busy filesystem, where a file may be deleted between the time that xfsdump finds out about it, and the time it decides to finally dump it to tape. However, I assume that the files in question are not subject to regular deletion and creation, so ... hmmm. Can you try the following commands: . stat . ls -li (confirm that regular stat will work on files) . df -klT (is /xxxx/xxxxxx/.gnome/panel.d/default/Applet_7_Extern on the same filesystem as /home) . cat (is the file readable) . xfs_check . xfs_repair (chech for inconsistencies within the filesystem) Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Tue Aug 28 01:05:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S85BP15138 for linux-xfs-outgoing; Tue, 28 Aug 2001 01:05:11 -0700 Received: from sgisrv1.teleworld.at (ns2.teleworld.at [212.152.248.30] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7S854d15119 for ; Tue, 28 Aug 2001 01:05:05 -0700 Received: from teleworld.at (twagw [10.53.77.20]) by sgisrv1.teleworld.at (8.9.3/8.9.3) with ESMTP id KAA11822; Tue, 28 Aug 2001 10:03:32 +0200 (CEST) Message-ID: <3B8B50A6.D0D11A3A@teleworld.at> Date: Tue, 28 Aug 2001 10:04:54 +0200 From: Gerald Weber Reply-To: gerald.weber@teleworld.at X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: oops with 2.4.9-xfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi there, oops with 2.4.9 (cvs checkout from oss.sgi.com,18-aug-01) on a dell 2450 / dual p3 with ~800mhz running suse-7.1 1 mylex accelraid 170,single channel 1 mylex accelraid 352 dual channel (serving ~300gb xfs raid5) Aug 28 00:36:11 twasrv1 kernel: invalid operand: 0000 Aug 28 00:36:11 twasrv1 kernel: CPU: 0 Aug 28 00:36:11 twasrv1 kernel: EIP: 0010:[__get_free_pages+8/24] Aug 28 00:36:11 twasrv1 kernel: EFLAGS: 00010682 Aug 28 00:36:11 twasrv1 kernel: eax: d19bf1f4 ebx: 00000000 ecx: c10a91a0 edx: 00000000 Aug 28 00:36:11 twasrv1 kernel: esi: c10a9173 edi: 00000ce4 ebp: d09170e4 esp: cc345e90 Aug 28 00:36:11 twasrv1 kernel: ds: 0018 es: 0018 ss: 0018 Aug 28 00:36:11 twasrv1 kernel: Process tar (pid: 9716, stackpage=cc345000) Aug 28 00:36:11 twasrv1 kernel: Stack: c0125f9b 00001ce4 080691f0 00000000 dfcc8000 dfe9d930 00000000 00000ce4 Aug 28 00:36:11 twasrv1 kernel: 00000001 00000000 00000001 d0917040 c0126377 de95b800 cc345f8c cc345ee0 Aug 28 00:36:11 twasrv1 kernel: c01262c0 de95b800 00001ce4 080691f0 00001000 00000ce4 0806a1f0 00000000 Aug 28 00:36:11 twasrv1 kernel: Call Trace: [do_generic_file_read+563/1368] [generic_file_read+99/128] [file_read_actor+0/84] [xfs_read+650/724] [linvfs_read+167/212] Aug 28 00:36:11 twasrv1 kernel: Code: ff ff 85 c0 75 03 31 c0 c3 8b 40 3c c3 8d 76 00 57 31 d2 53 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: ff (bad) Code; 00000001 Before first symbol 1: ff 85 c0 75 03 31 incl 0x310375c0(%ebp) Code; 00000007 Before first symbol 7: c0 c3 8b rol $0x8b,%bl Code; 0000000a Before first symbol a: 40 inc %eax Code; 0000000b Before first symbol b: 3c c3 cmp $0xc3,%al Code; 0000000d Before first symbol d: 8d 76 00 lea 0x0(%esi),%esi Code; 00000010 Before first symbol 10: 57 push %edi Code; 00000011 Before first symbol 11: 31 d2 xor %edx,%edx Code; 00000013 Before first symbol 13: 53 push %ebx this is the command causing the oops: tar cf - . | gzip -c > backup.tar.gz the dir in which tar is looking for files is exported via nfs (not knfsd) to other hosts. kernel 2.4.[3-8] usually die at this point.no network,no console,caps lock and scroll lock are blinking on keyboard... gcc used to compile kernel: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) any hints ? tell me if anyone needs more info.. please cc me if possible,i'm not subscibed to the list. this mail is going to xfs-mailing list also.. thanks, gerald weber From owner-linux-xfs@oss.sgi.com Tue Aug 28 02:33:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7S9XGV16914 for linux-xfs-outgoing; Tue, 28 Aug 2001 02:33:16 -0700 Received: from lacrosse.corp.redhat.com (host154.207-175-42.redhat.com [207.175.42.154]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7S9XCd16895 for ; Tue, 28 Aug 2001 02:33:12 -0700 Received: from meme.surrey.redhat.com (meme.surrey.redhat.com [172.16.10.38]) by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id FAA24968; Tue, 28 Aug 2001 05:33:10 -0400 Received: (from twaugh@localhost) by meme.surrey.redhat.com (8.11.6/8.11.6) id f7S9X5m10247; Tue, 28 Aug 2001 10:33:05 +0100 Date: Tue, 28 Aug 2001 10:33:05 +0100 From: Tim Waugh To: David Lloyd Cc: linux-xfs@oss.sgi.com Subject: Re: GCC|KGCC + Redhat + Linux-2.4.5 Message-ID: <20010828103305.G14506@redhat.com> References: <3B8A087C.AFEC581F@rebel.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="PtV1LuJoEDsm7sfb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B8A087C.AFEC581F@rebel.net.au>; from lloy0076@rebel.net.au on Mon, Aug 27, 2001 at 06:14:44PM +0930 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --PtV1LuJoEDsm7sfb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2001 at 06:14:44PM +0930, David Lloyd wrote: > Compiling the Linus Linux Kernel 2.4.5 patched by SGI for XFS with the > default gcc installed by RedHat appears to: >=20 > * fail to unlink files (especially when using vim but other files, such > as images, saved by Opera) What about with GCC 3.0.1? Tim. */ --PtV1LuJoEDsm7sfb 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 iD8DBQE7i2VRONXnILZ4yVIRAopkAJ9cywvonUJ9QqCy5wCmWNrgxqqKzQCeKH5u zYzbi9wi6DFCjXeBRPIY88I= =wDJg -----END PGP SIGNATURE----- --PtV1LuJoEDsm7sfb-- From owner-linux-xfs@oss.sgi.com Tue Aug 28 03:41:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SAfvp18025 for linux-xfs-outgoing; Tue, 28 Aug 2001 03:41:57 -0700 Received: from www.tsrv.ru ([213.132.71.136]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SAfsd18006 for ; Tue, 28 Aug 2001 03:41:54 -0700 Received: from narod.ru (novoross-163.ts.kuban.ru [195.161.59.163]) by www.tsrv.ru (8.9.3/8.9.3) with ESMTP id OAA63857; Tue, 28 Aug 2001 14:41:42 +0400 (MSD) (envelope-from tzukanov@narod.ru) Message-ID: <3B8B6EFA.1030307@narod.ru> Date: Tue, 28 Aug 2001 14:14:18 +0400 From: Serguei Tzukanov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: ru, en-us MIME-Version: 1.0 To: bug-grub@gnu.org CC: linux-xfs@oss.sgi.com Subject: [ANNOUNCE] XFS for GRUB Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Native XFS filesystem support for GRUB. The patch and info is at http://tzukanov.narod.ru/grub-jfs_xfs. From owner-linux-xfs@oss.sgi.com Tue Aug 28 04:24:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SBO8B19072 for linux-xfs-outgoing; Tue, 28 Aug 2001 04:24:08 -0700 Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SBO6d19053 for ; Tue, 28 Aug 2001 04:24:06 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id NAA08006; Tue, 28 Aug 2001 13:23:59 +0200 (CEST) Message-Id: <4.3.2.7.2.20010828132217.032db940@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Aug 2001 13:23:20 +0200 To: Serguei Tzukanov , bug-grub@gnu.org From: Seth Mos Subject: Re: [ANNOUNCE] XFS for GRUB Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B8B6EFA.1030307@narod.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:14 28-8-2001 +0400, Serguei Tzukanov wrote: >Native XFS filesystem support for GRUB. >The patch and info is at http://tzukanov.narod.ru/grub-jfs_xfs. Changed in the FAQ Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Aug 28 06:03:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SD32Z21244 for linux-xfs-outgoing; Tue, 28 Aug 2001 06:03:02 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SD2xd21225 for ; Tue, 28 Aug 2001 06:02:59 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 95D3D1AB10 for ; Tue, 28 Aug 2001 09:02:58 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 57111823; Tue, 28 Aug 2001 09:02:58 -0400 (EDT) Date: Tue, 28 Aug 2001 09:02:58 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: "raid5: multiple 1 requests for sector ..." Message-ID: <20010828090257.A27882@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Aug 28, 2001 at 07:33:56AM +0200, Seth Mos wrote: > On Mon, 27 Aug 2001, Andrew Klaassen wrote: > > On Mon, Aug 27, 2001 at 07:15:34PM -0400, > > I wrote: > > > > > - The box doesn't crash... > > > > ...though I do see that 1/2 an hour later the logs report: > > > > kernel: I/O error in filesystem ("md(9,2)") meta-data dev 0x903 block 0x13fbe > > kernel: ("") error -1070893103 buf count 5 > > kernel: xfs_force_shutdown(md(9,2),0x2) called from line 940 of file xfs_log.c. Return address = 0xc01c329c > > kernel: Log I/O Error Detected. Shutting down filesystem: md(9,2) > > kernel: Please umount the filesystem, and rectify the problem(s) > > > > I've got no idea if this might be related or not. > It seems so related to the problems you mentioned earlier that > you would almost think so. It doesn't have to be perse. > What was the kernel and with what compiler? A 2.4.9 CVS checkout from August 17. > I remember you saw this with a OSF1 nfs client? No, that must have been somebody else... Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Aug 28 06:51:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SDpsf22933 for linux-xfs-outgoing; Tue, 28 Aug 2001 06:51:54 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SDpod22914 for ; Tue, 28 Aug 2001 06:51:50 -0700 Received: (qmail 5693 invoked from network); 28 Aug 2001 13:51:50 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop2.mpls.uswest.net with SMTP; 28 Aug 2001 13:51:50 -0000 Date: Tue, 28 Aug 2001 08:48:04 -0500 Message-ID: <3B8BA114.7ED21B57@sgi.com> From: "Eric Sandeen" To: "Juri Haberland" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: Lockup since 2.4.4 when switching from X to console References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juri Haberland wrote: > On all test I used the kgcc. Every time besides the last (2.4.9) test I > compiled the XFS-enabled kernel with kdb, but not even the kdb kicked in. > > Any hints on how to debug? I really would like to use XFS on this system... hi Juri - I really wouldn't suspect XFS, but it sounds like you do have it narrowed down. :) By complete lockup, do you mean NOTHING works, or is just the console hung up? Can you access the machine over the network? If so, can you see what is running via "ps" from a normal network login? If you can't get to it over the network, what I would do is enable KDB, and hook up a serial console if you can... then when the machine locks up, invoke KDB yourself (CTRL-A on the serial console), and type "ps" to see what's running. You could try hitting the "pause" key on the normal console, but if the machine is in X, you won't see the kdb prompt. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 06:55:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SDtTt23086 for linux-xfs-outgoing; Tue, 28 Aug 2001 06:55:29 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SDtQd23067 for ; Tue, 28 Aug 2001 06:55:26 -0700 Received: (qmail 11180 invoked from network); 28 Aug 2001 13:55:27 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop2.mpls.uswest.net with SMTP; 28 Aug 2001 13:55:27 -0000 Date: Tue, 28 Aug 2001 08:51:41 -0500 Message-ID: <3B8BA1ED.8B5CCBC3@sgi.com> From: "Eric Sandeen" To: "Seth Mos" Cc: "Shanker Balan" , "Linux-XFS" 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 Subject: Re: Umask bug in the Installer - Solved? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > This is with reference to the RHL-XFS 1.0.1 installer which created > > files under /etc with world read/write perms and one had to run the > > fix-perms.sh script to restore sane permissions. > > > > Has this issue been resolved in the Installer ISO? >From the README in the installer directory on the ftp site, > You should either grab the update disk image from the updates/ > directory, or run the "fix-perms" script as root immediately > after you install your system with this ISO. We did not re-spin the original ISO, but if you use one of the two above methods when installing, everything will be fine... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 07:02:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SE2qX23613 for linux-xfs-outgoing; Tue, 28 Aug 2001 07:02:52 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SE2nd23593 for ; Tue, 28 Aug 2001 07:02:49 -0700 Received: (qmail 22818 invoked from network); 28 Aug 2001 14:02:49 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop2.mpls.uswest.net with SMTP; 28 Aug 2001 14:02:49 -0000 Date: Tue, 28 Aug 2001 08:59:02 -0500 Message-ID: <3B8BA3A6.14B75B08@sgi.com> From: "Eric Sandeen" To: gerald.weber@teleworld.at Cc: linux-xfs@oss.sgi.com 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 Subject: Re: oops with 2.4.9-xfs References: <3B8B50A6.D0D11A3A@teleworld.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Gerald - Gerald Weber wrote: > oops with 2.4.9 (cvs checkout from oss.sgi.com,18-aug-01) on a dell 2450 / dual > p3 with ~800mhz > running suse-7.1 > 1 mylex accelraid 170,single channel > 1 mylex accelraid 352 dual channel (serving ~300gb xfs raid5) > kernel 2.4.[3-8] usually die at this point.no network,no console,caps lock and > scroll lock are blinking > on keyboard... This means that it is in KDB, if you're not in X, you will see the kdb prompt, and typing "bt" will give you a backtrace of what happened... > gcc used to compile kernel: > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Are you certain that this is the version used to compile the kernel? Does SuSE 7.1 have 2 versions of gcc installed? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 07:04:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SE4Xw23776 for linux-xfs-outgoing; Tue, 28 Aug 2001 07:04:33 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SE4Vd23757 for ; Tue, 28 Aug 2001 07:04:31 -0700 Received: (qmail 25502 invoked from network); 28 Aug 2001 14:04:31 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop2.mpls.uswest.net with SMTP; 28 Aug 2001 14:04:31 -0000 Date: Tue, 28 Aug 2001 09:00:43 -0500 Message-ID: <3B8BA40B.3F75D9C3@sgi.com> From: "Eric Sandeen" To: "Serguei Tzukanov" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: [ANNOUNCE] XFS for GRUB References: <3B8B6EFA.1030307@narod.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Great news! Thanks! Any known problems or issues? -Eric Serguei Tzukanov wrote: > > Native XFS filesystem support for GRUB. > The patch and info is at http://tzukanov.narod.ru/grub-jfs_xfs. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 07:05:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SE5Va23902 for linux-xfs-outgoing; Tue, 28 Aug 2001 07:05:31 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SE5Qd23883 for ; Tue, 28 Aug 2001 07:05:26 -0700 Received: (qmail 4544 invoked by uid 8); 28 Aug 2001 14:05:25 -0000 From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: Lockup since 2.4.4 when switching from X to console Date: Tue, 28 Aug 2001 16:06:54 +0200 Organization: spoiled dot org Lines: 35 Distribution: local Message-ID: References: <3B8BA114.7ED21B57@sgi.com> Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.9-xfs (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Eric Sandeen" wrote: > Juri Haberland wrote: >> On all test I used the kgcc. Every time besides the last (2.4.9) test I >> compiled the XFS-enabled kernel with kdb, but not even the kdb kicked in. >> >> Any hints on how to debug? I really would like to use XFS on this system... > hi Juri - > I really wouldn't suspect XFS, but it sounds like you do have it > narrowed down. :) > By complete lockup, do you mean NOTHING works, or is just the console > hung up? Can you access the machine over the network? If so, can you > see what is running via "ps" from a normal network login? > If you can't get to it over the network, what I would do is enable KDB, > and hook up a serial console if you can... then when the machine locks > up, invoke KDB yourself (CTRL-A on the serial console), and type "ps" to > see what's running. You could try hitting the "pause" key on the normal > console, but if the machine is in X, you won't see the kdb prompt. maybe its kdb somehow itself - as far as i can see the only component which differs from the plain kernel and the xfs one which has a little bit to do with the console ... maybe trying to disable it or on the other side: add the kdb patch to the plain kernel and see if the problem apears there too ... t -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Tue Aug 28 07:11:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SEBeo24140 for linux-xfs-outgoing; Tue, 28 Aug 2001 07:11:40 -0700 Received: from mplspop2.mpls.uswest.net (mplspop2.mpls.uswest.net [204.147.80.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SEBcd24121 for ; Tue, 28 Aug 2001 07:11:38 -0700 Received: (qmail 36554 invoked from network); 28 Aug 2001 14:11:38 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop2.mpls.uswest.net with SMTP; 28 Aug 2001 14:11:38 -0000 Date: Tue, 28 Aug 2001 09:07:52 -0500 Message-ID: <3B8BA5B8.D1D3BAC9@sgi.com> From: "Eric Sandeen" To: "thomas graichen" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: Lockup since 2.4.4 when switching from X to console References: <3B8BA114.7ED21B57@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk thomas graichen wrote: > maybe its kdb somehow itself - as far as i can see the only > component which differs from the plain kernel and the xfs one > which has a little bit to do with the console ... Good point, you might try "echo 0 > /proc/sys/kernel/kdb" and see if that makes anything better... or perhaps even disable kdb in your config. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 07:17:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SEHnq24371 for linux-xfs-outgoing; Tue, 28 Aug 2001 07:17:49 -0700 Received: from sgisrv1.teleworld.at (ns2.teleworld.at [212.152.248.30] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SEHid24352 for ; Tue, 28 Aug 2001 07:17:45 -0700 Received: from teleworld.at (twagw [10.53.77.20]) by sgisrv1.teleworld.at (8.9.3/8.9.3) with ESMTP id QAA24180; Tue, 28 Aug 2001 16:16:11 +0200 (CEST) Message-ID: <3B8BA7FB.2D1E8568@teleworld.at> Date: Tue, 28 Aug 2001 16:17:31 +0200 From: Gerald Weber Reply-To: gerald.weber@teleworld.at X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: oops with 2.4.9-xfs References: <3B8B50A6.D0D11A3A@teleworld.at> <3B8BA3A6.14B75B08@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, KDB...type bt... thats the prob,i can't type anything on the keyboard..screen stays dark.. suse7.1 comes with gcc-2.95.3. i first tried to compile it with this one but after a few crashes i installed egcs-2.91.66 (i read somewhere to use this version with xfs...) gerald Eric Sandeen wrote: > > hi Gerald - > > Gerald Weber wrote: > > > oops with 2.4.9 (cvs checkout from oss.sgi.com,18-aug-01) on a dell 2450 / dual > > p3 with ~800mhz > > running suse-7.1 > > 1 mylex accelraid 170,single channel > > 1 mylex accelraid 352 dual channel (serving ~300gb xfs raid5) > > > > > kernel 2.4.[3-8] usually die at this point.no network,no console,caps lock and > > scroll lock are blinking > > on keyboard... > > This means that it is in KDB, if you're not in X, you will see the kdb > prompt, and typing "bt" will give you a backtrace of what happened... > > > gcc used to compile kernel: > > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs > > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > Are you certain that this is the version used to compile the kernel? > Does SuSE 7.1 have 2 versions of gcc installed? > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 07:22:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SEM7e24540 for linux-xfs-outgoing; Tue, 28 Aug 2001 07:22:07 -0700 Received: from warp9.koschikode.com (pD9517C39.dip.t-dialin.net [217.81.124.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SEM4d24520 for ; Tue, 28 Aug 2001 07:22:04 -0700 Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id EB55CCDED; Tue, 28 Aug 2001 16:21:54 +0200 (CEST) Message-ID: <3B8BA902.F1A76EB1@koschikode.com> Date: Tue, 28 Aug 2001 16:21:54 +0200 From: Juri Haberland X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Lockup since 2.4.4 when switching from X to console References: <3B8BA114.7ED21B57@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: > > Juri Haberland wrote: > > > On all test I used the kgcc. Every time besides the last (2.4.9) test I > > compiled the XFS-enabled kernel with kdb, but not even the kdb kicked in. > > > > Any hints on how to debug? I really would like to use XFS on this system... > > hi Juri - > > I really wouldn't suspect XFS, but it sounds like you do have it > narrowed down. :) > > By complete lockup, do you mean NOTHING works, or is just the console > hung up? Can you access the machine over the network? If so, can you > see what is running via "ps" from a normal network login? Unfortunately it is really a *complete* lockup. The host stops immediately responding to pings :-( > If you can't get to it over the network, what I would do is enable KDB, > and hook up a serial console if you can... then when the machine locks > up, invoke KDB yourself (CTRL-A on the serial console), and type "ps" to > see what's running. You could try hitting the "pause" key on the normal > console, but if the machine is in X, you won't see the kdb prompt. I will try that this evening. Thanks, Juri From owner-linux-xfs@oss.sgi.com Tue Aug 28 07:39:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SEd4t24971 for linux-xfs-outgoing; Tue, 28 Aug 2001 07:39:04 -0700 Received: from mplspop3.mpls.uswest.net (mplspop3.mpls.uswest.net [204.147.80.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SEd2d24951 for ; Tue, 28 Aug 2001 07:39:02 -0700 Received: (qmail 19914 invoked from network); 28 Aug 2001 14:39:00 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop3.mpls.uswest.net with SMTP; 28 Aug 2001 14:39:00 -0000 Date: Tue, 28 Aug 2001 09:35:16 -0500 Message-ID: <3B8BAC24.1A825217@sgi.com> From: "Eric Sandeen" To: gerald.weber@teleworld.at Cc: linux-xfs@oss.sgi.com 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 Subject: Re: oops with 2.4.9-xfs References: <3B8B50A6.D0D11A3A@teleworld.at> <3B8BA3A6.14B75B08@sgi.com> <3B8BA7FB.2D1E8568@teleworld.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Gerald Weber wrote: > > hi, > > KDB...type bt... > thats the prob,i can't type anything on the keyboard..screen stays dark.. If the machine is in X, or if the console has blanked, this will be the case... if you start your tar command from a text console, do you see the kdb prompt when it hangs? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 07:53:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SErTr25498 for linux-xfs-outgoing; Tue, 28 Aug 2001 07:53:29 -0700 Received: from warp9.koschikode.com (pD9517C39.dip.t-dialin.net [217.81.124.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SErPd25479 for ; Tue, 28 Aug 2001 07:53:26 -0700 Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id 2C514CE06; Tue, 28 Aug 2001 16:53:19 +0200 (CEST) Message-ID: <3B8BB05F.A433F027@koschikode.com> Date: Tue, 28 Aug 2001 16:53:19 +0200 From: Juri Haberland X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen Cc: thomas graichen , linux-xfs@oss.sgi.com Subject: Re: Lockup since 2.4.4 when switching from X to console References: <3B8BA114.7ED21B57@sgi.com> <3B8BA5B8.D1D3BAC9@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: > > thomas graichen wrote: > > > maybe its kdb somehow itself - as far as i can see the only > > component which differs from the plain kernel and the xfs one > > which has a little bit to do with the console ... > > Good point, you might try "echo 0 > /proc/sys/kernel/kdb" > > and see if that makes anything better... or perhaps even disable kdb in > your config. No, I don't think so, because (as I wrote in my first mail) the last test that I ran was with the .config from the vanilla kernel (via 'make oldconfig'). I did not enable XFS or KDB for that last test. So it was a XFS kernel but without XFS or KDB compiled in... Juri From owner-linux-xfs@oss.sgi.com Tue Aug 28 08:17:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SFHRM26078 for linux-xfs-outgoing; Tue, 28 Aug 2001 08:17:27 -0700 Received: from warp9.koschikode.com (pD9517C39.dip.t-dialin.net [217.81.124.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SFHOd26058 for ; Tue, 28 Aug 2001 08:17:24 -0700 Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id D83EBCDED; Tue, 28 Aug 2001 17:17:17 +0200 (CEST) Message-ID: <3B8BB5FD.3CAE47CE@koschikode.com> Date: Tue, 28 Aug 2001 17:17:17 +0200 From: Juri Haberland X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: thomas graichen Cc: linux-xfs@oss.sgi.com Subject: Re: Lockup since 2.4.4 when switching from X to console References: <3B8BA114.7ED21B57@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk thomas graichen wrote: > > maybe its kdb somehow itself - as far as i can see the only > component which differs from the plain kernel and the xfs one > which has a little bit to do with the console ... maybe trying > to disable it or on the other side: add the kdb patch to the > plain kernel and see if the problem apears there too ... Ah, a good point, Thomas. But I'm not sure about what patch to use: is the patch from the kdb project the same code that is included in the xfs patches? Juri From owner-linux-xfs@oss.sgi.com Tue Aug 28 08:25:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SFP0426388 for linux-xfs-outgoing; Tue, 28 Aug 2001 08:25:00 -0700 Received: from longsword.omniti.com (IDENT:exim@longsword.omniti.com [216.0.51.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SFOvd26369 for ; Tue, 28 Aug 2001 08:24:57 -0700 Received: from warhammer.omniti.com ([216.0.51.145] helo=omniti.com) by longsword.omniti.com with esmtp (Exim 3.22 #2) id 15bkjX-0005FW-00; Tue, 28 Aug 2001 11:24:55 -0400 Message-ID: <3B8BB7C7.4020808@omniti.com> Date: Tue, 28 Aug 2001 11:24:55 -0400 From: "Theo E. Schlossnagle" Organization: OmniTI, Inc. -- Computer Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: exim-users@exim.org, linux-xfs@oss.sgi.com Subject: Exim and XFS filesystem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, We have been running exim for a while and we run it on over 75 machines (Linux, BSDs Solaris). We recently started using SGI's xfs filesystem for most of our operations because of its speed and stability -- we are _very_ happy with it. I have never had any problems with it ... until now. Exim v3.14,v3.22,v3.33 and Linux 2.4.2-xfs. The xfs parition in question is running atop a RAID-1 md device on two 9GB scsi drives. After running Exim with its spool directory on an xfs partition and under low load (100 messages/minute) I would soon get an Exim process spinning CPU bound and I could not kill it [kill -9 did nothing]. The system was stuck on disk writes (so any process that calls fsync or friends would get stuck in the run queue never to come out again.) No modified files were writted to disk (by any process) after this point. A reboot was required and restore "normal" operation. We tried many things to fix this with no success, but as soon as we configured exim to use a non xfs (ext2 in this case) mounted spool directory, the problem instantly disappeared. It looked as if the kernel had a thread stuck writing to or reading from the filesystem journal. If anyone knows a solution to this problem, I am all ears. Otherwise, steer clear of running you Exim spools on xfs. -- Theo Schlossnagle 1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 From owner-linux-xfs@oss.sgi.com Tue Aug 28 08:32:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SFWFW26679 for linux-xfs-outgoing; Tue, 28 Aug 2001 08:32:15 -0700 Received: from banana.psenterprise.com (banana.psenterprise.com [194.70.241.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SFW5d26653 for ; Tue, 28 Aug 2001 08:32:07 -0700 Received: from BUCKEYE (buckeye [194.70.241.110]) by banana.psenterprise.com (8.11.2/8.11.2) with SMTP id f7SFVmQ13276 for ; Tue, 28 Aug 2001 16:31:48 +0100 From: "Christian Schulz" To: Subject: Re: xfsrestore assertion failure Date: Tue, 28 Aug 2001 16:31:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7SFWDd26660 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I'd just like to comment on the fix which has been suggested by Steve Roseman since nobody mentioned if a real restore would work with this fix. I found out that I couldn't restore any of our backups (2.4.7 with xfs-patches, xfsdump 1.0.9). After I applied the patch to the xfsdump-src-1.0.9, I found that I could restore without problems. Regards, Christian From owner-linux-xfs@oss.sgi.com Tue Aug 28 08:33:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SFXhf26818 for linux-xfs-outgoing; Tue, 28 Aug 2001 08:33:43 -0700 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 f7SFXfd26799 for ; Tue, 28 Aug 2001 08:33:41 -0700 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 f7SFeDa17147 for ; Tue, 28 Aug 2001 08:40:13 -0700 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 KAA2829826 for ; Tue, 28 Aug 2001 10:32:20 -0500 (CDT) 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 KAA82104 for ; Tue, 28 Aug 2001 10:32:20 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7SFUpC03371; Tue, 28 Aug 2001 10:30:51 -0500 Message-Id: <200108281530.f7SFUpC03371@stout.americas.sgi.com> Date: Tue, 28 Aug 2001 10:30:51 -0500 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:101630a Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Aug 28 08:31:39 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101719a linux/fs/xfs/xfs_trans.c - 1.124 - Merge irix6.5f:irix:101630a Split xfs_trans_alloc into freezeable and non-freezable versions. linux/fs/xfs/xfs_trans.h - 1.108 - Merge irix6.5f:irix:101630a Add _xfs_trans_alloc declaration. linux/fs/xfs/xfs_fsops.c - 1.67 - Merge irix6.5f:irix:101630a Adds dummy log record after umount -k to force recovery. From owner-linux-xfs@oss.sgi.com Tue Aug 28 08:42:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SFg1L27056 for linux-xfs-outgoing; Tue, 28 Aug 2001 08:42:01 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SFfwd27037 for ; Tue, 28 Aug 2001 08:41:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA07267 for ; Tue, 28 Aug 2001 08:41:58 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2832032; Tue, 28 Aug 2001 10:40:33 -0500 (CDT) Received: from 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 KAA42450; Tue, 28 Aug 2001 10:40:32 -0500 (CDT) Message-ID: <3B8BBB17.FD7AF0E5@sgi.com> Date: Tue, 28 Aug 2001 10:39:03 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Theo E. Schlossnagle" CC: exim-users@exim.org, linux-xfs@oss.sgi.com Subject: Re: Exim and XFS filesystem References: <3B8BB7C7.4020808@omniti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Theo E. Schlossnagle" wrote: > Exim v3.14,v3.22,v3.33 and Linux 2.4.2-xfs. The xfs parition in question is > running atop a RAID-1 md device on two 9GB scsi drives. > It looked as if the kernel had a thread stuck writing to or reading from the > filesystem journal. If anyone knows a solution to this problem, I am all > ears. Otherwise, steer clear of running you Exim spools on xfs. My first suggestion would be to upgrade to XFS-1.0.1 if possible, 2.4.2/XFS-1.0 is a bit old, and several fixes went into 1.0.1 1.0.1 is available as a patch against vanilla 2.4.5, or coupled with Red Hat's 2.4.3 kernel release for RH Linux 7.1. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 09:09:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SG9jh27796 for linux-xfs-outgoing; Tue, 28 Aug 2001 09:09:45 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SG9fd27777 for ; Tue, 28 Aug 2001 09:09:42 -0700 Received: (qmail 25179 invoked by uid 8); 28 Aug 2001 16:09:40 -0000 From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: Lockup since 2.4.4 when switching from X to console Date: Tue, 28 Aug 2001 18:08:31 +0200 Organization: spoiled dot org Lines: 21 Distribution: local Message-ID: References: <3B8BA114.7ED21B57@sgi.com> <3B8BB5FD.3CAE47CE@koschikode.com> Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.9-xfs (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juri Haberland wrote: > thomas graichen wrote: >> maybe its kdb somehow itself - as far as i can see the only >> component which differs from the plain kernel and the xfs one >> which has a little bit to do with the console ... maybe trying >> to disable it or on the other side: add the kdb patch to the >> plain kernel and see if the problem apears there too ... > Ah, a good point, Thomas. > But I'm not sure about what patch to use: is the patch from the kdb > project the same code that is included in the xfs patches? i assume yes - because keith (who is doing a lot on kdb) is also active in xfs land - so i assume they are identical ... keith? t -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Tue Aug 28 09:13:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SGDEC27961 for linux-xfs-outgoing; Tue, 28 Aug 2001 09:13:14 -0700 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 f7SGDBd27942 for ; Tue, 28 Aug 2001 09:13:12 -0700 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 f7SGIf823490 for ; Tue, 28 Aug 2001 09:18:42 -0700 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 LAA2824891; Tue, 28 Aug 2001 11:11:51 -0500 (CDT) Received: from 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 LAA23374; Tue, 28 Aug 2001 11:11:50 -0500 (CDT) Message-ID: <3B8BC26D.FB366435@sgi.com> Date: Tue, 28 Aug 2001 11:10:21 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Martin Apel CC: linux-xfs@oss.sgi.com Subject: Re: "getfh failed" again - Resolved References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Martin Apel wrote: > > Hi, > > I tried moving some of my filesystems exported via NFS from ext2 to > XFS. Unfortunately I had the same error message > getfh failed: Operation not permitted > when trying to mount the filesystem from an NFS client as previously > discussed on this list. I compiled a 2.4.5 kernel with the XFS 1.0.1 > patches using egcs egcs-2.91.66.1. Ok, the problem here appears to be that Martin had ftp://ftp.namesys.com/pub/reiserfs-for-2.4/linux-2.4.5-reiserfs-quota+knfsd+umount-fix.patch.bz2 applied, which adds an "nfsd_operations" interface between knfsd and the filesystem. XFS doesn't have this by default (since this is not part of the standard kernel) but the patch Jan submitted at http://marc.theaimsgroup.com/?l=linux-xfs&m=99535721113926&w=2 will probably make these play nice together again. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 09:15:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SGFsw28134 for linux-xfs-outgoing; Tue, 28 Aug 2001 09:15:54 -0700 Received: from the-penguin.otak.com (mail@the-penguin.otak.com [216.122.56.136]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SGFod28109 for ; Tue, 28 Aug 2001 09:15:50 -0700 Received: from lawrence by the-penguin.otak.com with local (Exim 3.32 #1 (Debian)) id 15blWU-0003fs-00; Tue, 28 Aug 2001 09:15:30 -0700 Date: Tue, 28 Aug 2001 09:15:30 -0700 From: Lawrence Walton To: "Theo E. Schlossnagle" Cc: exim-users@exim.org, linux-xfs@oss.sgi.com Subject: Re: [Exim] Exim and XFS filesystem Message-ID: <20010828091530.A13434@the-penguin.otak.com> References: <3B8BB7C7.4020808@omniti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B8BB7C7.4020808@omniti.com> User-Agent: Mutt/1.3.20i X-Operating-System: Linux 2.4.8-ac10 on an i686 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Theo E. Schlossnagle [jesus@omniti.com] wrote: > Hello all, > > We have been running exim for a while and we run it on over 75 machines > (Linux, BSDs Solaris). We recently started using SGI's xfs filesystem for > most of our operations because of its speed and stability -- we are _very_ > happy with it. I have never had any problems with it ... until now. > > Exim v3.14,v3.22,v3.33 and Linux 2.4.2-xfs. The xfs parition in question is > > running atop a RAID-1 md device on two 9GB scsi drives. > > After running Exim with its spool directory on an xfs partition and under > low load (100 messages/minute) I would soon get an Exim process spinning CPU > bound and I could not kill it [kill -9 did nothing]. The system was stuck > on disk writes (so any process that calls fsync or friends would get stuck > in the run queue never to come out again.) No modified files were writted > to disk (by any process) after this point. A reboot was required and > restore "normal" operation. > > We tried many things to fix this with no success, but as soon as we > configured exim to use a non xfs (ext2 in this case) mounted spool > directory, the problem instantly disappeared. > > It looked as if the kernel had a thread stuck writing to or reading from the > > filesystem journal. If anyone knows a solution to this problem, I am all > ears. Otherwise, steer clear of running you Exim spools on xfs. > > -- > Theo Schlossnagle > 1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984 > 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 > > > > > -- > ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim > details at http://www.exim.org/ ## You might try a newer version, of xfs, I have been running the CVS version dated Aug 2nd 2.4.7-xfs. Though a production box, it's load is not what yours is, and is not running raid. SGI is very active supporting XFS. -- *--* Mail: lawrence@otak.com *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://www.otak-k.com/~lawrence/ -------------------------------------- - - - - - - O t a k i n c . - - - - - From owner-linux-xfs@oss.sgi.com Tue Aug 28 10:16:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SHGLq29372 for linux-xfs-outgoing; Tue, 28 Aug 2001 10:16:21 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SHGGd29353 for ; Tue, 28 Aug 2001 10:16:16 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.2/8.11.2) with ESMTP id f7SHN4c16021; Tue, 28 Aug 2001 19:23:04 +0200 Date: Tue, 28 Aug 2001 19:23:04 +0200 (CEST) From: Matteo Centonza To: cc: Subject: Re: xfsdump question 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 Ivan, > xfsdump assumes /sbin is in root's path. If it isn't, it probably should > be. If it is, then be sure that xfsdq is there. i think that the dump program is executed by the amanda user that in any case has /sbin in the path (just as root). I suppose is a problem inherited from amanda autoconf. > Hm, this is a bit odd. One might expect these failures if xfsdump were > running on a busy filesystem, where a file may be deleted between the time > that xfsdump finds out about it, and the time it decides to finally dump > it to tape. > > However, I assume that the files in question are not subject to regular > deletion and creation, so ... hmmm. Filesystems are dumped early in the morning, when activity is very poor. On the other hand, that's the second message i get about the same three files, so it's very unlikely that this is the case. > > Can you try the following commands: > > . stat > . ls -li > (confirm that regular stat will work on files) > > . df -klT > (is /xxxx/xxxxxx/.gnome/panel.d/default/Applet_7_Extern on the same > filesystem as /home) > > . cat > (is the file readable) > > . xfs_check > . xfs_repair > (chech for inconsistencies within the filesystem) > Yes files are on the same fs.... I've tried all commands but xfs_repair and stuff _seems_ in good shape. Hope this helps, -m From owner-linux-xfs@oss.sgi.com Tue Aug 28 10:46:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SHkLh30039 for linux-xfs-outgoing; Tue, 28 Aug 2001 10:46:21 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SHkId30017 for ; Tue, 28 Aug 2001 10:46:18 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id TAA14426; Tue, 28 Aug 2001 19:46:16 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA28178; Tue, 28 Aug 2001 19:46:16 +0200 (CEST) Date: Tue, 28 Aug 2001 19:46:16 +0200 (CEST) From: Seth Mos To: Juri Haberland cc: thomas graichen , linux-xfs@oss.sgi.com Subject: Re: Lockup since 2.4.4 when switching from X to console In-Reply-To: <3B8BB5FD.3CAE47CE@koschikode.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 28 Aug 2001, Juri Haberland wrote: > thomas graichen wrote: > > > > > maybe its kdb somehow itself - as far as i can see the only > > component which differs from the plain kernel and the xfs one > > which has a little bit to do with the console ... maybe trying > > to disable it or on the other side: add the kdb patch to the > > plain kernel and see if the problem apears there too ... > > Ah, a good point, Thomas. > But I'm not sure about what patch to use: is the patch from the kdb > project the same code that is included in the xfs patches? Yes. From owner-linux-xfs@oss.sgi.com Tue Aug 28 11:00:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SI0mO30397 for linux-xfs-outgoing; Tue, 28 Aug 2001 11:00:48 -0700 Received: from codon.com (stampingchat.com [64.78.130.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SI0kd30377 for ; Tue, 28 Aug 2001 11:00:46 -0700 Received: (qmail 32570 invoked by uid 516); 28 Aug 2001 18:14:25 -0000 Received: from nw@codon.com by helix with qmail-scanner-0.96 (. Clean. Processed in 0.052279 secs); 28 Aug 2001 18:14:25 -0000 Received: from weasel.local.iboats.com (HELO weasel) (64.78.130.80) by codon.com with SMTP; 28 Aug 2001 18:14:24 -0000 Message-ID: <002501c12fea$b1091620$50824e40@iboats.com> From: "Steve Wolfe" To: Subject: Problems with DAT tape.... Date: Tue, 28 Aug 2001 11:55:46 -0600 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 A while ago, I took one of the machines here and started using XFS on it. The kernel is 2.4.6, with the appropriate xfs patches. All of the XFS stuff works marvelously, but now I'm having quite a bit of trouble trying to make backups to the DAT drive in it. After I upgraded the machine, whenever I try and send a tar to the tape (i.e., "trying tar cf /dev/nst0 BACKUP.LABEL"), I get: ST0: Write not multiple of tape block size The kernel does have SCSI tape and generic support, and the backup script hasn't changed. I could start fiddling with mt trying to change the blocksize, but something just keeps nagging at me that it should be working, and there's probably something else that I'm missing. Anyone have any ideas? steve From owner-linux-xfs@oss.sgi.com Tue Aug 28 12:11:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SJBsu31938 for linux-xfs-outgoing; Tue, 28 Aug 2001 12:11:54 -0700 Received: from warp9.koschikode.com (pD9517C39.dip.t-dialin.net [217.81.124.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SJBod31919 for ; Tue, 28 Aug 2001 12:11:50 -0700 Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id 17129CDED; Tue, 28 Aug 2001 21:11:47 +0200 (CEST) Message-ID: <3B8BECF2.412A4CDC@koschikode.com> Date: Tue, 28 Aug 2001 21:11:46 +0200 From: Juri Haberland X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Lockup since 2.4.4 when switching from X to console References: <3B8BA114.7ED21B57@sgi.com> <3B8BB5FD.3CAE47CE@koschikode.com> <3B8BB772.C1FD1BD1@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: > > Juri Haberland wrote: > > > Ah, a good point, Thomas. > > But I'm not sure about what patch to use: is the patch from the kdb > > project the same code that is included in the xfs patches? > > You can probably reverse-apply the standard 2.4.9-kdb patch, but I can > mail you one that's specifically for backing it out of XFS, if you'd > like - it's about 500k. Ok, after a lot of compiler and fsck runs and with the kdb-patch from Eric I narrowed it down to the kdb patch in conjunction with apm. If I enable apm _and_ the kernel option "Enable console blanking using APM" the system hangs when switching from X to the console (via CTRL-ALT-F1). The XFS kernel without kdb is fine. First I thought it must be the frame-buffer console stuff but it wasn't. Hope that helps a bit. Juri From owner-linux-xfs@oss.sgi.com Tue Aug 28 12:26:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SJQdA32294 for linux-xfs-outgoing; Tue, 28 Aug 2001 12:26:39 -0700 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 f7SJQXd32275 for ; Tue, 28 Aug 2001 12:26:35 -0700 Received: from [10.109.21.30] (IDENT:jjaakkol@adsl-2-5.cs.helsinki.fi [128.214.204.234]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id f7SJQCS24066; Tue, 28 Aug 2001 22:26:12 +0300 Date: Tue, 28 Aug 2001 22:26:11 +0300 (EEST) From: Jani Jaakkola To: Juri Haberland cc: Subject: Re: Lockup since 2.4.4 when switching from X to console In-Reply-To: <3B8BECF2.412A4CDC@koschikode.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 28 Aug 2001, Juri Haberland wrote: > > after a lot of compiler and fsck runs and with the kdb-patch from Eric I > narrowed it down to the kdb patch in conjunction with apm. If I enable > apm _and_ the kernel option "Enable console blanking using APM" the > system hangs when switching from X to the console (via CTRL-ALT-F1). > > The XFS kernel without kdb is fine. > > First I thought it must be the frame-buffer console stuff but it wasn't. > > Hope that helps a bit. I just a few weeks ago had to install a new kernel to a few hundred machines, since I had accidentally enabled "Enable console blanking using APM" switch. There are lots of motherboards around which have somewhat broken APM support or at least do not work correctly with Linux APM. Many of these machines just hang, when console blanking or unblanking using APM is attempted. This is not XFS spesific and is not even 2.4 kernel spesific. Most of those few hundred machines I had to update were running 2.2.19 kernel. You just should not enable console blanking using APM, unless you are running a laptop machine and you are sure that it actually works. With PC workstations or servers the plain VESA screen blanking support works very well, so the APM support is not very useful anyway. And most good laptops are smart enough to do screen blanking themselves without any help from Linux kernel. - Jani From owner-linux-xfs@oss.sgi.com Tue Aug 28 12:34:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SJYTM32613 for linux-xfs-outgoing; Tue, 28 Aug 2001 12:34:29 -0700 Received: from idi.vamo.orbitel.bg (dns.vamo.orbitel.bg [195.24.63.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SJYMd32594 for ; Tue, 28 Aug 2001 12:34:24 -0700 Received: from localhost (ivandi@localhost) by idi.vamo.orbitel.bg (8.11.4/8.11.4) with ESMTP id f7SJYDm04445 for ; Tue, 28 Aug 2001 22:34:13 +0300 X-Authentication-Warning: idi.vamo.orbitel.bg: ivandi owned process doing -bs Date: Tue, 28 Aug 2001 22:34:12 +0300 (EEST) From: Ivan Ivanov To: Subject: Data destruction Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I spent two days to hack Slackware 8 installer and to add support for XFS root filesystem and xfsprogs.tgz package. Kernel is 2.4.6 patched for XFS. I have the following problems: 1. When XFS is root filesystem it can't be checked for errors. Wnen I go to runlevel 1 and remount / readonly all xfs repair tools say that filesystem is mounted. The only way is to make two boot disks with kernel and static linked repair tools on ramdisk. 2. Data in most of the files which are open during power fail is lost. Files are here, size is right but data is garbage. So where is journal? I think that only metadata is journaled but not file data. ReiserFS has the same problem. In fact only ext3 works fine. I like XFS features like ACL and extended attributes but if the system or power fails data is lost. About year ago I had some problems with hard drives with 2MB write back cache but this is not the case now. Regards Ivan From owner-linux-xfs@oss.sgi.com Tue Aug 28 12:41:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SJf4Y00404 for linux-xfs-outgoing; Tue, 28 Aug 2001 12:41:04 -0700 Received: from warp9.koschikode.com (pD9517C39.dip.t-dialin.net [217.81.124.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SJf1d00385 for ; Tue, 28 Aug 2001 12:41:01 -0700 Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id 5BC3CCDED; Tue, 28 Aug 2001 21:40:58 +0200 (CEST) Message-ID: <3B8BF3C9.2FF00EF1@koschikode.com> Date: Tue, 28 Aug 2001 21:40:57 +0200 From: Juri Haberland X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jani Jaakkola Cc: linux-xfs@oss.sgi.com Subject: Re: Lockup since 2.4.4 when switching from X to console References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jani Jaakkola wrote: > > There are lots of motherboards around which have somewhat broken APM > support or at least do not work correctly with Linux APM. Many of these > machines just hang, when console blanking or unblanking using APM is > attempted. This is not XFS spesific and is not even 2.4 kernel spesific. See, the point is that with a vanilla kernel it works without a problem but with the kdb patch applied it locks up. So somehow the kdb patch breaks the apm stuff and this should be investigated and, if possible, resolved. Juri From owner-linux-xfs@oss.sgi.com Tue Aug 28 12:43:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SJh0k00554 for linux-xfs-outgoing; Tue, 28 Aug 2001 12:43:00 -0700 Received: from finn.cns.montana.edu (finn.cns.montana.edu [153.90.178.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SJgwd00534 for ; Tue, 28 Aug 2001 12:42:58 -0700 Received: from case.cns.montana.edu (case.cns.montana.edu [153.90.178.21]) by finn.cns.montana.edu (8.9.3/8.9.3) with ESMTP id NAA20648 for ; Tue, 28 Aug 2001 13:42:58 -0600 (MDT) Date: Tue, 28 Aug 2001 13:42:57 -0600 From: Gary Orser To: linux-xfs@oss.sgi.com Subject: nfs3 problems w/xfs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've installed linux 2.4.5, with xfs on a Suse 7.1 base install. Got xfs working as well as nfs3 between an Irix 6.5.13m system. I can copy files < 2g, but get errors on large files > 4g. cannot stat 'somelargefile' Input/output error I've searched through the faq and group lists but can't find anything related. The only thing I haven't been able to try is kgcc and/or the egcs compiler. I can't find these for the Suse distro. Cheers, Gary ------------------------------------------------------ Gary Orser , (406) 994-6451, orser@nervana.montana.edu Montana State University Center for Computational Biology 1 Lewis Hall, Bozeman MT, 59717 From owner-linux-xfs@oss.sgi.com Tue Aug 28 12:44:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SJiUa00785 for linux-xfs-outgoing; Tue, 28 Aug 2001 12:44:30 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SJiRd00766 for ; Tue, 28 Aug 2001 12:44:28 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA11573 for ; Tue, 28 Aug 2001 12:44:08 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2802575; Tue, 28 Aug 2001 14:43:10 -0500 (CDT) Received: from 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 OAA53086; Tue, 28 Aug 2001 14:43:09 -0500 (CDT) Message-ID: <3B8BF3F2.3291510@sgi.com> Date: Tue, 28 Aug 2001 14:41:38 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Ivan Ivanov CC: linux-xfs@oss.sgi.com Subject: Re: Data destruction References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ivan Ivanov wrote: > 1. When XFS is root filesystem it can't be checked for errors. > Wnen I go to runlevel 1 and remount / readonly all xfs repair tools say > that filesystem is mounted. The only way is to make two boot disks with kernel > and static linked repair tools on ramdisk. If you only want to _check_ for errors, you can do "xfs_repair -n /dev/foo" on a read-only-mounted device. You can also run xfs_check on the read-only device. If you actually want to repair a filesystem, then yes, it must be unmounted. > 2. Data in most of the files which are open during power fail is lost. > Files are here, size is right but data is garbage. > So where is journal? I think that only metadata is journaled but not file > data. ReiserFS has the same problem. In fact only ext3 works fine. XFS and ReiserFS don't journal data, only metadata. Data journaling is an option in ext3. In general, journaling filesystems don't guarantee against data loss, they only guarantee a consistent filesystem. You can't expect that if you click off power in the middle of a write, that the data won't be lost - at a minimum, there is write-caching in the picture. http://oss.sgi.com/projects/xfs/faq.html#nulls -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Aug 28 13:28:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SKSi402024 for linux-xfs-outgoing; Tue, 28 Aug 2001 13:28:44 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SKSfd02005 for ; Tue, 28 Aug 2001 13:28:41 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA07396 for ; Tue, 28 Aug 2001 13:26:56 -0700 (PDT) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2833226; Tue, 28 Aug 2001 15:27:21 -0500 (CDT) 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 PAA70156; Tue, 28 Aug 2001 15:27:21 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id PAA77582; Tue, 28 Aug 2001 15:27:20 -0500 (CDT) Message-Id: <200108282027.PAA77582@fsgi158.americas.sgi.com> Subject: Re: nfs3 problems w/xfs? To: orser@cns.montana.edu (Gary Orser) Date: Tue, 28 Aug 2001 15:27:18 -0500 (CDT) Cc: linux-xfs@oss.sgi.com In-Reply-To: from "Gary Orser" at Aug 28, 2001 01:42:57 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 > > Hi, > > I've installed linux 2.4.5, with xfs on a Suse 7.1 base install. > > Got xfs working as well as nfs3 between an Irix 6.5.13m system. > Gary, I assume xfs-linux is NFS server and Irix is NFS client? I've used 10g files without problems. Maybe a snoop from the Irix side would tell us something. Thanks, Tad > I can copy files < 2g, but get errors on large files > 4g. > cannot stat 'somelargefile' Input/output error > > I've searched through the faq and group lists but can't > find anything related. > > The only thing I haven't been able to try is kgcc and/or > the egcs compiler. I can't find these for the Suse distro. > > Cheers, Gary > ------------------------------------------------------ > Gary Orser , (406) 994-6451, orser@nervana.montana.edu > Montana State University > Center for Computational Biology > 1 Lewis Hall, Bozeman MT, 59717 > From owner-linux-xfs@oss.sgi.com Tue Aug 28 13:37:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SKbJX02349 for linux-xfs-outgoing; Tue, 28 Aug 2001 13:37:19 -0700 Received: from finn.cns.montana.edu (finn.cns.montana.edu [153.90.178.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SKbEd02330 for ; Tue, 28 Aug 2001 13:37:15 -0700 Received: from case.cns.montana.edu (case.cns.montana.edu [153.90.178.21]) by finn.cns.montana.edu (8.9.3/8.9.3) with ESMTP id OAA22144; Tue, 28 Aug 2001 14:36:52 -0600 (MDT) Date: Tue, 28 Aug 2001 14:36:52 -0600 From: Gary Orser To: Tad Dolphay cc: linux-xfs@oss.sgi.com Subject: Re: nfs3 problems w/xfs? In-Reply-To: <200108282027.PAA77582@fsgi158.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 Tad, xfs-linux was the client, Irix the server. Cheers, Gary ------------------------------------------------------ Gary Orser , (406) 994-6451, orser@nervana.montana.edu Montana State University Center for Computational Biology 1 Lewis Hall, Bozeman MT, 59717 On Tue, 28 Aug 2001, Tad Dolphay wrote: > > > > Hi, > > > > I've installed linux 2.4.5, with xfs on a Suse 7.1 base install. > > > > Got xfs working as well as nfs3 between an Irix 6.5.13m system. > > > > Gary, > > I assume xfs-linux is NFS server and Irix is NFS client? I've used 10g > files without problems. Maybe a snoop from the Irix side would tell us > something. > > Thanks, > Tad > > > I can copy files < 2g, but get errors on large files > 4g. > > cannot stat 'somelargefile' Input/output error > > > > I've searched through the faq and group lists but can't > > find anything related. > > > > The only thing I haven't been able to try is kgcc and/or > > the egcs compiler. I can't find these for the Suse distro. > > > > Cheers, Gary > > ------------------------------------------------------ > > Gary Orser , (406) 994-6451, orser@nervana.montana.edu > > Montana State University > > Center for Computational Biology > > 1 Lewis Hall, Bozeman MT, 59717 > > > From owner-linux-xfs@oss.sgi.com Tue Aug 28 15:01:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SM1Fl04055 for linux-xfs-outgoing; Tue, 28 Aug 2001 15:01:15 -0700 Received: from codon.com (www.gingerstamp.com [64.78.130.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SM1Cd04036 for ; Tue, 28 Aug 2001 15:01:12 -0700 Received: (qmail 3923 invoked by uid 516); 28 Aug 2001 22:14:53 -0000 Received: from nw@codon.com by helix with qmail-scanner-0.96 (. Clean. Processed in 0.052895 secs); 28 Aug 2001 22:14:53 -0000 Received: from weasel.local.iboats.com (HELO weasel) (64.78.130.80) by codon.com with SMTP; 28 Aug 2001 22:14:53 -0000 Message-ID: <000f01c1300c$47d70820$50824e40@iboats.com> From: "Steve Wolfe" To: References: <002501c12fea$b1091620$50824e40@iboats.com> Subject: Re: Problems with DAT tape.... Date: Tue, 28 Aug 2001 15:55:33 -0600 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 > A while ago, I took one of the machines here and started using XFS on > it. The kernel is 2.4.6, with the appropriate xfs patches. All of the > XFS stuff works marvelously, but now I'm having quite a bit of trouble > trying to make backups to the DAT drive in it. > > After I upgraded the machine, whenever I try and send a tar to the tape > (i.e., "trying tar cf /dev/nst0 BACKUP.LABEL"), I get: > > ST0: Write not multiple of tape block size Well, I think that I found the problem. It looks like it just managed to happen during the transition to XFS, but is not XFS-related. The ultimate problem, upon investigation, was that the tape's block size was set to 1 megabyte. I got poking around, and it looks like the result of a poorly-written script. A previous admin had installed a backup script from O'Reilly's "Unix Backup and Recovery". One of the kludgy things that it does is temporarily set the block size on the tape to a megabyte, to fool something into thinking that the tape is huge. Apparently, someone must have started the script, then stopped it before it could reset the block size of the tape. The 1500+ line script was quickly replaced by a very short one. ; ) steve From owner-linux-xfs@oss.sgi.com Tue Aug 28 15:23:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SMNun04573 for linux-xfs-outgoing; Tue, 28 Aug 2001 15:23:56 -0700 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 f7SMNsd04554 for ; Tue, 28 Aug 2001 15:23:54 -0700 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 f7SMTO821248 for ; Tue, 28 Aug 2001 15:29:24 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00991; Wed, 29 Aug 2001 09:22:30 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA48982; Wed, 29 Aug 2001 09:22:29 +1100 (AEDT) Date: Wed, 29 Aug 2001 09:22:29 +1100 From: Nathan Scott To: Eric Sandeen Cc: Ivan Ivanov , linux-xfs@oss.sgi.com Subject: Re: Data destruction Message-ID: <20010829092229.E323889@wobbly.melbourne.sgi.com> References: <3B8BF3F2.3291510@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: <3B8BF3F2.3291510@sgi.com>; from sandeen@sgi.com on Tue, Aug 28, 2001 at 02:41:38PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Tue, Aug 28, 2001 at 02:41:38PM -0500, Eric Sandeen wrote: > Ivan Ivanov wrote: > > > 1. When XFS is root filesystem it can't be checked for errors. > > Wnen I go to runlevel 1 and remount / readonly all xfs repair tools say > > that filesystem is mounted. The only way is to make two boot disks with kernel > > and static linked repair tools on ramdisk. > > If you only want to _check_ for errors, you can do "xfs_repair -n > /dev/foo" on a read-only-mounted device. You can also run xfs_check on > the read-only device. If you actually want to repair a filesystem, then > yes, it must be unmounted. > I made some changes awhile ago now which will allow xfs_repair to run on a readonly, mounted filesystem. root was a little tricky, but should still work - Ivan, which version of xfsprogs are you using and can you try the latest version? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 28 15:30:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SMUgd04777 for linux-xfs-outgoing; Tue, 28 Aug 2001 15:30:42 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SMUcd04757 for ; Tue, 28 Aug 2001 15:30:39 -0700 Received: (qmail 2598 invoked from network); 28 Aug 2001 22:30:28 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Aug 2001 22:30:28 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: thomas graichen cc: linux-xfs@oss.sgi.com Subject: Re: Lockup since 2.4.4 when switching from X to console In-reply-to: Your message of "Tue, 28 Aug 2001 18:08:31 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Aug 2001 08:30:27 +1000 Message-ID: <17719.999037827@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 28 Aug 2001 18:08:31 +0200, thomas graichen wrote: >Juri Haberland wrote: >> But I'm not sure about what patch to use: is the patch from the kdb >> project the same code that is included in the xfs patches? > >i assume yes - because keith (who is doing a lot on kdb) is also >active in xfs land - so i assume they are identical ... keith? Apart from line number and RCS $Id$ djustments, kdb in the xfs tree is identical to the free standing kdb patch. But as has already been pointed out, compiling without XFS and kdb has the same problem. There is kdb code in the console path but it only checks for the pause key or ^A. Apart from that, kdb has no effect on consoles. From owner-linux-xfs@oss.sgi.com Tue Aug 28 15:36:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SMaAb04930 for linux-xfs-outgoing; Tue, 28 Aug 2001 15:36:10 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SMa6d04911 for ; Tue, 28 Aug 2001 15:36:06 -0700 Received: (qmail 2616 invoked from network); 28 Aug 2001 22:36:03 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Aug 2001 22:36:03 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Juri Haberland cc: linux-xfs@oss.sgi.com Subject: Re: Lockup since 2.4.4 when switching from X to console In-reply-to: Your message of "Tue, 28 Aug 2001 21:40:57 +0200." <3B8BF3C9.2FF00EF1@koschikode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Aug 2001 08:36:02 +1000 Message-ID: <17766.999038162@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 28 Aug 2001 21:40:57 +0200, Juri Haberland wrote: >Jani Jaakkola wrote: > >> There are lots of motherboards around which have somewhat broken APM >> support or at least do not work correctly with Linux APM. Many of these >> machines just hang, when console blanking or unblanking using APM is >> attempted. This is not XFS spesific and is not even 2.4 kernel spesific. > >See, the point is that with a vanilla kernel it works without a problem >but with the kdb patch applied it locks up. So somehow the kdb patch >breaks the apm stuff and this should be investigated and, if possible, >resolved. The kdb patch goes nowhere near apm. It sounds like apm has a bug that is sensitive to the layout of the kernel or stack,particularly since compiling without kdb configured on still has the problem. Did you compile the kernel with frame pointers on or with kallsyms and does removing those options make a difference? From owner-linux-xfs@oss.sgi.com Tue Aug 28 15:40:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SMedg05131 for linux-xfs-outgoing; Tue, 28 Aug 2001 15:40:39 -0700 Received: from femail45.sdc1.sfba.home.com (femail45.sdc1.sfba.home.com [24.254.60.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SMebd05110 for ; Tue, 28 Aug 2001 15:40:37 -0700 Received: from there ([24.10.81.118]) by femail45.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010828224031.JZQZ25401.femail45.sdc1.sfba.home.com@there> for ; Tue, 28 Aug 2001 15:40:31 -0700 Content-Type: text/plain; charset="iso-8859-1" From: machack Reply-To: machack@sscsonline.org Organization: SSCS To: linux-xfs@oss.sgi.com Subject: Kernel Dump on quotaon Date: Tue, 28 Aug 2001 18:21:59 -0400 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Message-Id: <20010828224031.JZQZ25401.femail45.sdc1.sfba.home.com@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7SMebd05111 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk rc.sysinit cuases the kernel to dump when it hits quotaon. this problem only happens on kernels newer then 2.4.6 on these later kernels I have no problems when I pass devfs=nomount on boot. Am I the only one to have this problem or is it documented. my root partion is xfs. -- http://machack.sscsonline.org/ZapQuake/ Don't just play quake feel it! SSCS Office Phone: 355-2418 || 3634A2h Room#: ATC 308 || 0x134 From owner-linux-xfs@oss.sgi.com Tue Aug 28 16:33:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SNXLQ06082 for linux-xfs-outgoing; Tue, 28 Aug 2001 16:33:21 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SNXHd06062 for ; Tue, 28 Aug 2001 16:33:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA18649 for ; Tue, 28 Aug 2001 16:32:58 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01197; Wed, 29 Aug 2001 10:31:57 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA08013; Wed, 29 Aug 2001 10:31:56 +1100 (AEDT) Date: Wed, 29 Aug 2001 10:31:55 +1100 From: Nathan Scott To: machack , Jan Kara Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Dump on quotaon Message-ID: <20010829103155.G323889@wobbly.melbourne.sgi.com> References: <20010828224031.JZQZ25401.femail45.sdc1.sfba.home.com@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010828224031.JZQZ25401.femail45.sdc1.sfba.home.com@there>; from machack@sscsonline.org on Tue, Aug 28, 2001 at 06:21:59PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Tue, Aug 28, 2001 at 06:21:59PM -0400, machack wrote: > rc.sysinit cuases the kernel to dump when it hits quotaon. this problem only > happens on kernels newer then 2.4.6 on these later kernels I have no > problems when I pass devfs=nomount on boot. Am I the only one to have this > problem or is it documented. my root partion is xfs. > I'd be interested in seeing a kdb or ksymoops backtrace if you can provide one. quotaon at startup is always ignored by XFS - enabling quota is a mount time operation for XFS filesystems, so this is likely to be a problem in the interaction between the quotactl system call (takes a device special file as its second argument) with Q_QUOTAON and devfs; and unrelated to XFS. If you only have XFS filesystems using quota (and no ext2/other filesystems using quota), you can safely remove the "quotaon -a" from your startup scripts (thats really not a very nice solution though...) Jan, any chance you've come across this one before? I don't remember there being anything new/changed in 2.4.6 in the quota subsystem, so seems odd that this would suddenly start to fail. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 28 16:38:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7SNcRQ06260 for linux-xfs-outgoing; Tue, 28 Aug 2001 16:38:27 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7SNcOd06239 for ; Tue, 28 Aug 2001 16:38:24 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA19348 for ; Tue, 28 Aug 2001 16:38:05 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA31040; Wed, 29 Aug 2001 10:37:05 +1100 (EDT) Date: Wed, 29 Aug 2001 10:37:05 +1100 From: Timothy Shimmin To: Steve Wolfe Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with DAT tape.... Message-ID: <20010829103705.H114864@boing.melbourne.sgi.com> References: <002501c12fea$b1091620$50824e40@iboats.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <002501c12fea$b1091620$50824e40@iboats.com>; from nw@codon.com on Tue, Aug 28, 2001 at 11:55:46AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, On Tue, Aug 28, 2001 at 11:55:46AM -0600, Steve Wolfe wrote: > > A while ago, I took one of the machines here and started using XFS on > it. The kernel is 2.4.6, with the appropriate xfs patches. All of the > XFS stuff works marvelously, but now I'm having quite a bit of trouble > trying to make backups to the DAT drive in it. > > After I upgraded the machine, whenever I try and send a tar to the tape > (i.e., "trying tar cf /dev/nst0 BACKUP.LABEL"), I get: > > ST0: Write not multiple of tape block size > > The kernel does have SCSI tape and generic support, and the backup > script hasn't changed. I could start fiddling with mt trying to change > the blocksize, but something just keeps nagging at me that it should be > working, and there's probably something else that I'm missing. Anyone > have any ideas? > > steve > > As you mentioned in your follow up email - your scsi tape driver had its blocksize set (large) such that the write size that tar wanted to use was not a multiple of that block size. As you'd see from "mt -f /dev/st0 status" and by doing an strace on tar. I would recommend just putting the scsi tape driver into variable block sized mode. # mt -f /dev/st0 setblk 0 --Tim From owner-linux-xfs@oss.sgi.com Tue Aug 28 17:33:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T0XZH07415 for linux-xfs-outgoing; Tue, 28 Aug 2001 17:33:35 -0700 Received: from femail33.sdc1.sfba.home.com (femail33.sdc1.sfba.home.com [24.254.60.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7T0XSd07396 for ; Tue, 28 Aug 2001 17:33:28 -0700 Received: from airways.com ([24.1.223.28]) by femail33.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010829003322.IYBU4276.femail33.sdc1.sfba.home.com@airways.com> for ; Tue, 28 Aug 2001 17:33:22 -0700 Message-ID: <3B8C38BE.7000600@airways.com> Date: Tue, 28 Aug 2001 17:35:10 -0700 From: "D. Lance Robinson" Reply-To: lancer@airways.com Organization: Airways Technology User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: multiple writes of same block References: <3B8A78A5.3020106@airways.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, Doing some more rigorous tests, I find that the 'multiple x requests for sector y' error can come about quite often with the raid-5 driver. In about 70 minutes, the message was given 40 times. Here is my environment and the type of test being run... Linux 2.4.9, xfs snapshot 26-Aug-01 64kb memory, PPC platform, 5 disk raid 5 (1 disk is FibreChannel array using Qlogicfc driver, 4 scsi disks using sym53c8xx driver) XFS was created using 'xfs -b 4096 /dev/md2'. The size is about 70GB. Test observations... Running 10 processes that do random mix of file io (read, write, append, open, close, create, delete). HOWEVER, The first phase of the test populates the disk with files is all create and write operations. Each process is working on its own subdirectory and creating a mix of file sizes 2K-10MB. This create phase produces a lot of the errors. <>< Lance. D. Lance Robinson wrote: > I added the suggested printk statement to the raid5 driver and got a > few instances of the warning/error while running a test. The test > consists of five processes doing a mix of access patterns (reads, > writes, append, open, close, deletes) to their own set of files and > directories. Each file is accessed by only one process. The 5 errors > came at random times within a 7 hour test period using the 2.4.9 > kernel and the 17-Aug-01 xfs snapshot. This is run on a PPC. > > Let me know if you have any patches to test or if any other info would > be helpful. Unfortunately, I cannot release the test being used. raid5: multiple 1 requests for sector 12947328 raid5: new bh at blk 0x62c7f0 len 0x1000, existing blk 0x3163f80 len 0x1000 raid5: multiple 1 requests for sector 12948352 raid5: new bh at blk 0x62c9f0 len 0x1000, existing blk 0x3164f80 len 0x1000 raid5: multiple 1 requests for sector 12949248 raid5: new bh at blk 0x62cb80 len 0x1000, existing blk 0x3165c00 len 0x1000 raid5: multiple 1 requests for sector 12949888 raid5: new bh at blk 0x3166780 len 0x1000, existing blk 0x62ccf0 len 0x1000 raid5: multiple 1 requests for sector 4697184 raid5: new bh at blk 0x23d60c len 0x1000, existing blk 0x11eb060 len 0x1000 raid5: multiple 1 requests for sector 19149312 raid5: new bh at blk 0x490c980 len 0x1000, existing blk 0x921930 len 0x1000 raid5: multiple 1 requests for sector 19150464 raid5: new bh at blk 0x921b50 len 0x1000, existing blk 0x490da80 len 0x1000 raid5: multiple 1 requests for sector 17107808 raid5: new bh at blk 0x82859c len 0x1000, existing blk 0x4142ce0 len 0x1000 raid5: multiple 1 requests for sector 19156224 raid5: new bh at blk 0x922680 len 0x1000, existing blk 0x4913400 len 0x1000 raid5: multiple 1 requests for sector 8853376 raid5: new bh at blk 0x438bf0 len 0x1000, existing blk 0x21c5f80 len 0x1000 raid5: multiple 1 requests for sector 10771712 raid5: new bh at blk 0x522ea0 len 0x1000, existing blk 0x2917500 len 0x1000 raid5: multiple 1 requests for sector 14839424 raid5: new bh at blk 0x713750 len 0x1000, existing blk 0x389ba80 len 0x1000 raid5: multiple 1 requests for sector 13024128 raid5: new bh at blk 0x635dc0 len 0x1000, existing blk 0x31aee00 len 0x1000 raid5: multiple 1 requests for sector 4734848 raid5: new bh at blk 0x241ff0 len 0x1000, existing blk 0x120ff80 len 0x1000 raid5: multiple 1 requests for sector 19194240 raid5: new bh at blk 0x9270e0 len 0x1000, existing blk 0x4938700 len 0x1000 raid5: multiple 1 requests for sector 21320064 raid5: new bh at blk 0xa2a8f0 len 0x1000, existing blk 0x5154780 len 0x1000 raid5: multiple 1 requests for sector 8871912 raid5: new bh at blk 0x43afed len 0x1000, existing blk 0x21d7f68 len 0x1000 raid5: multiple 1 requests for sector 10790248 raid5: new bh at blk 0x52529d len 0x1000, existing blk 0x29294e8 len 0x1000 raid5: multiple 1 requests for sector 21338600 raid5: new bh at blk 0xa2cced len 0x1000, existing blk 0x5166768 len 0x1000 raid5: multiple 1 requests for sector 10818944 raid5: new bh at blk 0x2945700 len 0x1000, existing blk 0x528ae0 len 0x1000 raid5: multiple 1 requests for sector 10825088 raid5: new bh at blk 0x5296f0 len 0x1000, existing blk 0x294b780 len 0x1000 raid5: multiple 1 requests for sector 10825216 raid5: new bh at blk 0x529730 len 0x1000, existing blk 0x294b980 len 0x1000 raid5: multiple 1 requests for sector 10825984 raid5: new bh at blk 0x294c580 len 0x1000, existing blk 0x5298b0 len 0x1000 raid5: multiple 1 requests for sector 10827648 raid5: new bh at blk 0x529bc0 len 0x1000, existing blk 0x294de00 len 0x1000 raid5: multiple 1 requests for sector 10828800 raid5: new bh at blk 0x529e30 len 0x1000, existing blk 0x294f180 len 0x1000 raid5: multiple 1 requests for sector 10829184 raid5: new bh at blk 0x529ec0 len 0x1000, existing blk 0x294f600 len 0x1000 raid5: multiple 1 requests for sector 10832128 raid5: new bh at blk 0x52a480 len 0x1000, existing blk 0x2952400 len 0x1000 raid5: multiple 1 requests for sector 10833152 raid5: new bh at blk 0x2953500 len 0x1000, existing blk 0x52a6a0 len 0x1000 raid5: multiple 1 requests for sector 10833536 raid5: new bh at blk 0x52a740 len 0x1000, existing blk 0x2953a00 len 0x1000 raid5: multiple 1 requests for sector 10834432 raid5: new bh at blk 0x52a930 len 0x1000, existing blk 0x2954980 len 0x1000 raid5: multiple 1 requests for sector 19091584 raid5: new bh at blk 0x91a840 len 0x1000, existing blk 0x48d4200 len 0x1000 raid5: multiple 1 requests for sector 21256832 raid5: new bh at blk 0xa22d50 len 0x1000, existing blk 0x5116a80 len 0x1000 raid5: multiple 1 requests for sector 12925184 raid5: new bh at blk 0x629c90 len 0x1000, existing blk 0x314e480 len 0x1000 raid5: multiple 1 requests for sector 12940160 raid5: new bh at blk 0x62b9e0 len 0x1000, existing blk 0x315cf00 len 0x1000 raid5: multiple 1 requests for sector 10813056 raid5: new bh at blk 0x527f40 len 0x1000, existing blk 0x293fa00 len 0x1000 raid5: multiple 1 requests for sector 33782144 raid5: new bh at blk 0x101bcc0 len 0x1000, existing blk 0x80de600 len 0x1000 raid5: multiple 1 requests for sector 19097344 raid5: new bh at blk 0x91b380 len 0x1000, existing blk 0x48d9c00 len 0x1000 raid5: multiple 1 requests for sector 10709120 raid5: new bh at blk 0x51b440 len 0x1000, existing blk 0x28da200 len 0x1000 raid5: multiple 1 requests for sector 6622464 raid5: new bh at blk 0x328680 len 0x1000, existing blk 0x1943400 len 0x1000 raid5: multiple 1 requests for sector 12921344 raid5: new bh at blk 0x629510 len 0x1000, existing blk 0x314a880 len 0x1000 raid5: multiple 1 requests for sector 10710144 raid5: new bh at blk 0x51b660 len 0x1000, existing blk 0x28db300 len 0x1000 From owner-linux-xfs@oss.sgi.com Tue Aug 28 18:46:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T1kri08941 for linux-xfs-outgoing; Tue, 28 Aug 2001 18:46:53 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7T1kmd08919 for ; Tue, 28 Aug 2001 18:46:48 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA08419 for ; Tue, 28 Aug 2001 18:46:47 -0700 (PDT) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA2829723; Tue, 28 Aug 2001 20:45:17 -0500 (CDT) 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 UAA04684; Tue, 28 Aug 2001 20:45:17 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id UAA79114; Tue, 28 Aug 2001 20:45:16 -0500 (CDT) Message-Id: <200108290145.UAA79114@fsgi158.americas.sgi.com> Subject: Re: nfs3 problems w/xfs? To: orser@cns.montana.edu (Gary Orser) Date: Tue, 28 Aug 2001 20:45:15 -0500 (CDT) Cc: tbd@sgi.com (Tad Dolphay), linux-xfs@oss.sgi.com In-Reply-To: from "Gary Orser" at Aug 28, 2001 02:36:52 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 > > Tad, > > xfs-linux was the client, Irix the server. > Gary, Assuming you can use 4g files locally on the xfs-linux machine without problems and can use 4g files locally on the Irix machine without problems then I think a snoop from the Irix machine would still be useful. Thanks, Tad > Cheers, Gary > ------------------------------------------------------ > Gary Orser , (406) 994-6451, orser@nervana.montana.edu > Montana State University > Center for Computational Biology > 1 Lewis Hall, Bozeman MT, 59717 > > On Tue, 28 Aug 2001, Tad Dolphay wrote: > > > > > > > Hi, > > > > > > I've installed linux 2.4.5, with xfs on a Suse 7.1 base install. > > > > > > Got xfs working as well as nfs3 between an Irix 6.5.13m system. > > > > > > > Gary, > > > > I assume xfs-linux is NFS server and Irix is NFS client? I've used 10g > > files without problems. Maybe a snoop from the Irix side would tell us > > something. > > > > Thanks, > > Tad > > > > > I can copy files < 2g, but get errors on large files > 4g. > > > cannot stat 'somelargefile' Input/output error > > > > > > I've searched through the faq and group lists but can't > > > find anything related. > > > > > > The only thing I haven't been able to try is kgcc and/or > > > the egcs compiler. I can't find these for the Suse distro. > > > > > > Cheers, Gary > > > ------------------------------------------------------ > > > Gary Orser , (406) 994-6451, orser@nervana.montana.edu > > > Montana State University > > > Center for Computational Biology > > > 1 Lewis Hall, Bozeman MT, 59717 > > > > > > From owner-linux-xfs@oss.sgi.com Tue Aug 28 20:26:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T3Q8311490 for linux-xfs-outgoing; Tue, 28 Aug 2001 20:26:08 -0700 Received: from aaa.com ([211.101.185.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7T3Q5d11471 for ; Tue, 28 Aug 2001 20:26:05 -0700 Received: from coldice [211.101.185.79] by aaa.com [211.101.185.66] with SMTP (MDaemon.Standard.v4.0.5.R) for ; Wed, 29 Aug 2001 11:26:16 +0800 Message-ID: <003201c1303a$77d46850$4fb965d3@coldice> From: "Du Jun" To: References: Subject: umount lvm snapshot panic Date: Wed, 29 Aug 2001 11:27:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 X-MDRemoteIP: 211.101.185.79 X-Return-Path: dujun@aaafie.com X-MDaemon-Deliver-To: linux-xfs@oss.sgi.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f7T3Q6d11472 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, I met a problem with 2.4.9+xfs-08-26+lvm. I used following steps: 1.xfs_freeze -f /mnt/xfs 2.lvcreate -L 100M -s -n s1 /dev/lvm/lv1 3.xfs_freeze -u /mnt/xfs 4.mount -o ro, nouuid -t xfs /dev/lvm/s1 /mnt/xfs_snap 5.umount /mnt/xfs_snap then kernel panic. has anyone met the same problem before? thx. Jun From owner-linux-xfs@oss.sgi.com Tue Aug 28 22:50:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T5obU14030 for linux-xfs-outgoing; Tue, 28 Aug 2001 22:50:37 -0700 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 f7T5oYd14011 for ; Tue, 28 Aug 2001 22:50:34 -0700 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 f7T5u5807282 for ; Tue, 28 Aug 2001 22:56:05 -0700 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 QAA02327; Wed, 29 Aug 2001 16:49:12 +1100 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA49435; Wed, 29 Aug 2001 15:49:12 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Wed, 29 Aug 2001 15:49:11 +1000 To: Matteo Centonza cc: Subject: Re: xfsdump question 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, 28 Aug 2001, Matteo Centonza wrote: > > xfsdump assumes /sbin is in root's path. If it isn't, it probably should > > be. If it is, then be sure that xfsdq is there. > > i think that the dump program is executed by the amanda user that in any > case has /sbin in the path (just as root). I suppose is a problem > inherited from amanda autoconf. xfsdump requires that it be run as root. But, yes, it's probably just a config problem. > Yes files are on the same fs.... > > I've tried all commands but xfs_repair and stuff _seems_ in good shape. > > Hope this helps, Very strange. Would you be able to run xfsdump without amanda, and increase it's verbosity using '-v5'? You should redirect the output to a file - there will be _alot_ of it. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Tue Aug 28 23:11:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T6B6914594 for linux-xfs-outgoing; Tue, 28 Aug 2001 23:11:06 -0700 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 f7T6Awd14572 for ; Tue, 28 Aug 2001 23:10:58 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7T6GT808090 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 28 Aug 2001 23:16:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id IAA634537 for ; Wed, 29 Aug 2001 08:10:50 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id BAA2750618; Wed, 29 Aug 2001 01:09:32 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id BAA49990; Wed, 29 Aug 2001 01:09:32 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7T68Tp19414; Wed, 29 Aug 2001 01:08:29 -0500 Message-Id: <200108290608.f7T68Tp19414@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: lancer@airways.com cc: linux-xfs@oss.sgi.com Subject: Re: multiple writes of same block In-Reply-To: Message from "D. Lance Robinson" of "Tue, 28 Aug 2001 17:35:10 PDT." <3B8C38BE.7000600@airways.com> Date: Wed, 29 Aug 2001 01:08:29 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks very much for this info, I am going to tied up in meetings and then sat on extremely long plane trips for a couple more days. Hopefuly I can use this to make some progress next week. Can you possibly send your raidtab file. My first observation though is that in terms of where they are in the filesystem itself, these requests are no where near each other and are not going to cause a problem. Steve > Steve, > > Doing some more rigorous tests, I find that the 'multiple x requests for > sector y' error can come about quite often with the raid-5 driver. In > about 70 minutes, the message was given 40 times. Here is my > environment and the type of test being run... > > Linux 2.4.9, xfs snapshot 26-Aug-01 > 64kb memory, PPC platform, > 5 disk raid 5 (1 disk is FibreChannel array using Qlogicfc driver, 4 > scsi disks using sym53c8xx driver) > XFS was created using 'xfs -b 4096 /dev/md2'. The size is about 70GB. > > Test observations... > Running 10 processes that do random mix of file io (read, write, append, > open, close, create, delete). HOWEVER, The first phase of the test > populates the disk with files is all create and write operations. Each > process is working on its own subdirectory and creating a mix of file > sizes 2K-10MB. This create phase produces a lot of the errors. > > <>< Lance. > > > D. Lance Robinson wrote: > > > I added the suggested printk statement to the raid5 driver and got a > > few instances of the warning/error while running a test. The test > > consists of five processes doing a mix of access patterns (reads, > > writes, append, open, close, deletes) to their own set of files and > > directories. Each file is accessed by only one process. The 5 errors > > came at random times within a 7 hour test period using the 2.4.9 > > kernel and the 17-Aug-01 xfs snapshot. This is run on a PPC. > > > > Let me know if you have any patches to test or if any other info would > > be helpful. Unfortunately, I cannot release the test being used. > > raid5: multiple 1 requests for sector 12947328 > raid5: new bh at blk 0x62c7f0 len 0x1000, existing blk 0x3163f80 len 0x1000 > raid5: multiple 1 requests for sector 12948352 > raid5: new bh at blk 0x62c9f0 len 0x1000, existing blk 0x3164f80 len 0x1000 > raid5: multiple 1 requests for sector 12949248 > raid5: new bh at blk 0x62cb80 len 0x1000, existing blk 0x3165c00 len 0x1000 > raid5: multiple 1 requests for sector 12949888 > raid5: new bh at blk 0x3166780 len 0x1000, existing blk 0x62ccf0 len 0x1000 > raid5: multiple 1 requests for sector 4697184 > raid5: new bh at blk 0x23d60c len 0x1000, existing blk 0x11eb060 len 0x1000 > raid5: multiple 1 requests for sector 19149312 > raid5: new bh at blk 0x490c980 len 0x1000, existing blk 0x921930 len 0x1000 > raid5: multiple 1 requests for sector 19150464 > raid5: new bh at blk 0x921b50 len 0x1000, existing blk 0x490da80 len 0x1000 > raid5: multiple 1 requests for sector 17107808 > raid5: new bh at blk 0x82859c len 0x1000, existing blk 0x4142ce0 len 0x1000 > raid5: multiple 1 requests for sector 19156224 > raid5: new bh at blk 0x922680 len 0x1000, existing blk 0x4913400 len 0x1000 > raid5: multiple 1 requests for sector 8853376 > raid5: new bh at blk 0x438bf0 len 0x1000, existing blk 0x21c5f80 len 0x1000 > raid5: multiple 1 requests for sector 10771712 > raid5: new bh at blk 0x522ea0 len 0x1000, existing blk 0x2917500 len 0x1000 > raid5: multiple 1 requests for sector 14839424 > raid5: new bh at blk 0x713750 len 0x1000, existing blk 0x389ba80 len 0x1000 > raid5: multiple 1 requests for sector 13024128 > raid5: new bh at blk 0x635dc0 len 0x1000, existing blk 0x31aee00 len 0x1000 > raid5: multiple 1 requests for sector 4734848 > raid5: new bh at blk 0x241ff0 len 0x1000, existing blk 0x120ff80 len 0x1000 > raid5: multiple 1 requests for sector 19194240 > raid5: new bh at blk 0x9270e0 len 0x1000, existing blk 0x4938700 len 0x1000 > raid5: multiple 1 requests for sector 21320064 > raid5: new bh at blk 0xa2a8f0 len 0x1000, existing blk 0x5154780 len 0x1000 > raid5: multiple 1 requests for sector 8871912 > raid5: new bh at blk 0x43afed len 0x1000, existing blk 0x21d7f68 len 0x1000 > raid5: multiple 1 requests for sector 10790248 > raid5: new bh at blk 0x52529d len 0x1000, existing blk 0x29294e8 len 0x1000 > raid5: multiple 1 requests for sector 21338600 > raid5: new bh at blk 0xa2cced len 0x1000, existing blk 0x5166768 len 0x1000 > raid5: multiple 1 requests for sector 10818944 > raid5: new bh at blk 0x2945700 len 0x1000, existing blk 0x528ae0 len 0x1000 > raid5: multiple 1 requests for sector 10825088 > raid5: new bh at blk 0x5296f0 len 0x1000, existing blk 0x294b780 len 0x1000 > raid5: multiple 1 requests for sector 10825216 > raid5: new bh at blk 0x529730 len 0x1000, existing blk 0x294b980 len 0x1000 > raid5: multiple 1 requests for sector 10825984 > raid5: new bh at blk 0x294c580 len 0x1000, existing blk 0x5298b0 len 0x1000 > raid5: multiple 1 requests for sector 10827648 > raid5: new bh at blk 0x529bc0 len 0x1000, existing blk 0x294de00 len 0x1000 > raid5: multiple 1 requests for sector 10828800 > raid5: new bh at blk 0x529e30 len 0x1000, existing blk 0x294f180 len 0x1000 > raid5: multiple 1 requests for sector 10829184 > raid5: new bh at blk 0x529ec0 len 0x1000, existing blk 0x294f600 len 0x1000 > raid5: multiple 1 requests for sector 10832128 > raid5: new bh at blk 0x52a480 len 0x1000, existing blk 0x2952400 len 0x1000 > raid5: multiple 1 requests for sector 10833152 > raid5: new bh at blk 0x2953500 len 0x1000, existing blk 0x52a6a0 len 0x1000 > raid5: multiple 1 requests for sector 10833536 > raid5: new bh at blk 0x52a740 len 0x1000, existing blk 0x2953a00 len 0x1000 > raid5: multiple 1 requests for sector 10834432 > raid5: new bh at blk 0x52a930 len 0x1000, existing blk 0x2954980 len 0x1000 > raid5: multiple 1 requests for sector 19091584 > raid5: new bh at blk 0x91a840 len 0x1000, existing blk 0x48d4200 len 0x1000 > raid5: multiple 1 requests for sector 21256832 > raid5: new bh at blk 0xa22d50 len 0x1000, existing blk 0x5116a80 len 0x1000 > raid5: multiple 1 requests for sector 12925184 > raid5: new bh at blk 0x629c90 len 0x1000, existing blk 0x314e480 len 0x1000 > raid5: multiple 1 requests for sector 12940160 > raid5: new bh at blk 0x62b9e0 len 0x1000, existing blk 0x315cf00 len 0x1000 > raid5: multiple 1 requests for sector 10813056 > raid5: new bh at blk 0x527f40 len 0x1000, existing blk 0x293fa00 len 0x1000 > raid5: multiple 1 requests for sector 33782144 > raid5: new bh at blk 0x101bcc0 len 0x1000, existing blk 0x80de600 len 0x1000 > raid5: multiple 1 requests for sector 19097344 > raid5: new bh at blk 0x91b380 len 0x1000, existing blk 0x48d9c00 len 0x1000 > raid5: multiple 1 requests for sector 10709120 > raid5: new bh at blk 0x51b440 len 0x1000, existing blk 0x28da200 len 0x1000 > raid5: multiple 1 requests for sector 6622464 > raid5: new bh at blk 0x328680 len 0x1000, existing blk 0x1943400 len 0x1000 > raid5: multiple 1 requests for sector 12921344 > raid5: new bh at blk 0x629510 len 0x1000, existing blk 0x314a880 len 0x1000 > raid5: multiple 1 requests for sector 10710144 > raid5: new bh at blk 0x51b660 len 0x1000, existing blk 0x28db300 len 0x1000 From owner-linux-xfs@oss.sgi.com Wed Aug 29 00:01:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T71M115761 for linux-xfs-outgoing; Wed, 29 Aug 2001 00:01:22 -0700 Received: from aaa.com ([211.101.185.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7T71Ed15715 for ; Wed, 29 Aug 2001 00:01:14 -0700 Received: from coldice [211.101.185.79] by aaa.com [211.101.185.66] with SMTP (MDaemon.Standard.v4.0.5.R) for ; Wed, 29 Aug 2001 15:00:33 +0800 Message-ID: <004701c13058$66a2dfd0$4fb965d3@coldice> From: "Du Jun" To: Subject: kdb not compile Date: Wed, 29 Aug 2001 15:01:17 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C1309B.74A614B0" 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 X-MDRemoteIP: 211.101.185.79 X-Return-Path: dujun@aaafie.com X-MDaemon-Deliver-To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C1309B.74A614B0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 aGksIHNvcnJ5IGZvciBib3RoZXJpbmcuIEkgY2Fubm90IGNvbXBpbGUgdGhlIGtkYiB0aGF0IGNv bWVzIHdpdGggdGhlIHhmcy0wOC0yNiBzbmFwLXBhdGNoLiANCnRoZSBtZXNzYWdlcyBhcmU6DQpp Mzg2LWRpcy5jOiBJbiBmdW5jdGlvbiBgcHJpbnRfaW5zbl9pMzg2JzoNCmkzODYtZGlzLmM6MjE0 MzogYGJmZF9tYWNoX2kzODZfaTM4Nl9pbnRlbF9zeW50YXgnIHVuZGVjbGFyZWQgKGZpcnN0IHVz ZSBpbiB0aGlzIGZ1bmN0aW9uKQ0KaTM4Ni1kaXMuYzoyMTQzOiAoRWFjaCB1bmRlY2xhcmVkIGlk ZW50aWZpZXIgaXMgcmVwb3J0ZWQgb25seSBvbmNlDQppMzg2LWRpcy5jOjIxNDM6IGZvciBlYWNo IGZ1bmN0aW9uIGl0IGFwcGVhcnMgaW4uKQ0KaTM4Ni1kaXMuYzogSW4gZnVuY3Rpb24gYE9QX1NU JzoNCmkzODYtZGlzLmM6Mjc1NzogcGFyc2UgZXJyb3IgYmVmb3JlIGBBVFRSSUJVVEVfVU5VU0VE Jw0KaTM4Ni1kaXMuYzoyNzU4OiBwYXJzZSBlcnJvciBiZWZvcmUgYEFUVFJJQlVURV9VTlVTRUQn DQppMzg2LWRpcy5jOiBJbiBmdW5jdGlvbiBgT1BfU1RpJzoNCmkzODYtZGlzLmM6Mjc2NjogcGFy c2UgZXJyb3IgYmVmb3JlIGBBVFRSSUJVVEVfVU5VU0VEJw0KaTM4Ni1kaXMuYzoyNzY3OiBwYXJz ZSBlcnJvciBiZWZvcmUgYEFUVFJJQlVURV9VTlVTRUQnDQppMzg2LWRpcy5jOiBJbiBmdW5jdGlv biBgT1BfU0VHJzoNCmkzODYtZGlzLmM6MzQyMjogcGFyc2UgZXJyb3IgYmVmb3JlIGBBVFRSSUJV VEVfVU5VU0VEJw0KaTM4Ni1kaXMuYzozNDIzOiBwYXJzZSBlcnJvciBiZWZvcmUgYEFUVFJJQlVU RV9VTlVTRUQnDQppMzg2LWRpcy5jOiBJbiBmdW5jdGlvbiBgT1BfRElSJzoNCmkzODYtZGlzLmM6 MzQzNTogcGFyc2UgZXJyb3IgYmVmb3JlIGBBVFRSSUJVVEVfVU5VU0VEJw0KaTM4Ni1kaXMuYzog SW4gZnVuY3Rpb24gYE9QX09GRic6DQppMzg2LWRpcy5jOjM0NTg6IHBhcnNlIGVycm9yIGJlZm9y ZSBgQVRUUklCVVRFX1VOVVNFRCcNCmkzODYtZGlzLmM6IEluIGZ1bmN0aW9uIGBPUF9DJzoNCmkz ODYtZGlzLmM6MzUyNzogcGFyc2UgZXJyb3IgYmVmb3JlIGBBVFRSSUJVVEVfVU5VU0VEJw0KaTM4 Ni1kaXMuYzozNTI4OiBwYXJzZSBlcnJvciBiZWZvcmUgYEFUVFJJQlVURV9VTlVTRUQnDQppMzg2 LWRpcy5jOiBJbiBmdW5jdGlvbiBgT1BfRCc6DQppMzg2LWRpcy5jOjM1Mzc6IHBhcnNlIGVycm9y IGJlZm9yZSBgQVRUUklCVVRFX1VOVVNFRCcNCmkzODYtZGlzLmM6MzUzODogcGFyc2UgZXJyb3Ig YmVmb3JlIGBBVFRSSUJVVEVfVU5VU0VEJw0KaTM4Ni1kaXMuYzogSW4gZnVuY3Rpb24gYE9QX1Qn Og0KaTM4Ni1kaXMuYzozNTQ3OiBwYXJzZSBlcnJvciBiZWZvcmUgYEFUVFJJQlVURV9VTlVTRUQn DQppMzg2LWRpcy5jOjM1NDg6IHBhcnNlIGVycm9yIGJlZm9yZSBgQVRUUklCVVRFX1VOVVNFRCcN CmkzODYtZGlzLmM6IEluIGZ1bmN0aW9uIGBPUF9NTVgnOg0KaTM4Ni1kaXMuYzozNTY3OiBwYXJz ZSBlcnJvciBiZWZvcmUgYEFUVFJJQlVURV9VTlVTRUQnDQppMzg2LWRpcy5jOjM1Njg6IHBhcnNl IGVycm9yIGJlZm9yZSBgQVRUUklCVVRFX1VOVVNFRCcNCmkzODYtZGlzLmM6IEluIGZ1bmN0aW9u IGBPUF9YTU0nOg0KaTM4Ni1kaXMuYzozNTc2OiBwYXJzZSBlcnJvciBiZWZvcmUgYEFUVFJJQlVU RV9VTlVTRUQnDQppMzg2LWRpcy5jOjM1Nzc6IHBhcnNlIGVycm9yIGJlZm9yZSBgQVRUUklCVVRF X1VOVVNFRCcNCmkzODYtZGlzLmM6IEluIGZ1bmN0aW9uIGBPUF8zRE5vd1N1ZmZpeCc6DQppMzg2 LWRpcy5jOjM2OTU6IHBhcnNlIGVycm9yIGJlZm9yZSBgQVRUUklCVVRFX1VOVVNFRCcNCmkzODYt ZGlzLmM6MzY5NjogcGFyc2UgZXJyb3IgYmVmb3JlIGBBVFRSSUJVVEVfVU5VU0VEJw0KaTM4Ni1k aXMuYzogSW4gZnVuY3Rpb24gYE9QX1NJTURfU3VmZml4JzoNCmkzODYtZGlzLmM6MzczNDogcGFy c2UgZXJyb3IgYmVmb3JlIGBBVFRSSUJVVEVfVU5VU0VEJw0KaTM4Ni1kaXMuYzozNzM1OiBwYXJz ZSBlcnJvciBiZWZvcmUgYEFUVFJJQlVURV9VTlVTRUQnDQppMzg2LWRpcy5jOiBJbiBmdW5jdGlv biBgU0lNRF9GaXh1cCc6DQppMzg2LWRpcy5jOjM3NjI6IHBhcnNlIGVycm9yIGJlZm9yZSBgQVRU UklCVVRFX1VOVVNFRCcNCm1ha2VbMl06ICoqKiBbaTM4Ni1kaXMub10gRXJyb3IgMQ0KbWFrZVsy XTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL2xpbnV4LTIuNC45L2FyY2gvaTM4Ni9rZGIn DQptYWtlWzFdOiAqKiogW2ZpcnN0X3J1bGVdIEVycm9yIDINCm1ha2VbMV06IExlYXZpbmcgZGly ZWN0b3J5IGAvdXNyL3NyYy9saW51eC0yLjQuOS9hcmNoL2kzODYva2RiJw0KDQp0aHguIA0Kc2lu Y2VyZWx5LCANCkp1bg0K ------=_NextPart_000_0044_01C1309B.74A614B0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNS41MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5oaSwgc29ycnkg Zm9yIGJvdGhlcmluZy4gSSBjYW5ub3QgY29tcGlsZSB0aGUga2RiIHRoYXQgY29tZXMgDQp3aXRo IHRoZSB4ZnMtMDgtMjYgc25hcC1wYXRjaC4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+dGhlIG1lc3NhZ2VzIGFyZTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5pMzg2 LWRpcy5jOiBJbiBmdW5jdGlvbiBgcHJpbnRfaW5zbl9pMzg2Jzo8QlI+aTM4Ni1kaXMuYzoyMTQz OiANCmBiZmRfbWFjaF9pMzg2X2kzODZfaW50ZWxfc3ludGF4JyB1bmRlY2xhcmVkIChmaXJzdCB1 c2UgaW4gdGhpcyANCmZ1bmN0aW9uKTxCUj5pMzg2LWRpcy5jOjIxNDM6IChFYWNoIHVuZGVjbGFy ZWQgaWRlbnRpZmllciBpcyByZXBvcnRlZCBvbmx5IA0Kb25jZTxCUj5pMzg2LWRpcy5jOjIxNDM6 IGZvciBlYWNoIGZ1bmN0aW9uIGl0IGFwcGVhcnMgaW4uKTxCUj5pMzg2LWRpcy5jOiBJbiANCmZ1 bmN0aW9uIGBPUF9TVCc6PEJSPmkzODYtZGlzLmM6Mjc1NzogcGFyc2UgZXJyb3IgYmVmb3JlIA0K YEFUVFJJQlVURV9VTlVTRUQnPEJSPmkzODYtZGlzLmM6Mjc1ODogcGFyc2UgZXJyb3IgYmVmb3Jl IA0KYEFUVFJJQlVURV9VTlVTRUQnPEJSPmkzODYtZGlzLmM6IEluIGZ1bmN0aW9uIGBPUF9TVGkn OjxCUj5pMzg2LWRpcy5jOjI3NjY6IA0KcGFyc2UgZXJyb3IgYmVmb3JlIGBBVFRSSUJVVEVfVU5V U0VEJzxCUj5pMzg2LWRpcy5jOjI3Njc6IHBhcnNlIGVycm9yIGJlZm9yZSANCmBBVFRSSUJVVEVf VU5VU0VEJzxCUj5pMzg2LWRpcy5jOiBJbiBmdW5jdGlvbiBgT1BfU0VHJzo8QlI+aTM4Ni1kaXMu YzozNDIyOiANCnBhcnNlIGVycm9yIGJlZm9yZSBgQVRUUklCVVRFX1VOVVNFRCc8QlI+aTM4Ni1k aXMuYzozNDIzOiBwYXJzZSBlcnJvciBiZWZvcmUgDQpgQVRUUklCVVRFX1VOVVNFRCc8QlI+aTM4 Ni1kaXMuYzogSW4gZnVuY3Rpb24gYE9QX0RJUic6PEJSPmkzODYtZGlzLmM6MzQzNTogDQpwYXJz ZSBlcnJvciBiZWZvcmUgYEFUVFJJQlVURV9VTlVTRUQnPEJSPmkzODYtZGlzLmM6IEluIGZ1bmN0 aW9uIA0KYE9QX09GRic6PEJSPmkzODYtZGlzLmM6MzQ1ODogcGFyc2UgZXJyb3IgYmVmb3JlIA0K YEFUVFJJQlVURV9VTlVTRUQnPEJSPmkzODYtZGlzLmM6IEluIGZ1bmN0aW9uIGBPUF9DJzo8QlI+ aTM4Ni1kaXMuYzozNTI3OiBwYXJzZSANCmVycm9yIGJlZm9yZSBgQVRUUklCVVRFX1VOVVNFRCc8 QlI+aTM4Ni1kaXMuYzozNTI4OiBwYXJzZSBlcnJvciBiZWZvcmUgDQpgQVRUUklCVVRFX1VOVVNF RCc8QlI+aTM4Ni1kaXMuYzogSW4gZnVuY3Rpb24gYE9QX0QnOjxCUj5pMzg2LWRpcy5jOjM1Mzc6 IHBhcnNlIA0KZXJyb3IgYmVmb3JlIGBBVFRSSUJVVEVfVU5VU0VEJzxCUj5pMzg2LWRpcy5jOjM1 Mzg6IHBhcnNlIGVycm9yIGJlZm9yZSANCmBBVFRSSUJVVEVfVU5VU0VEJzxCUj5pMzg2LWRpcy5j OiBJbiBmdW5jdGlvbiBgT1BfVCc6PEJSPmkzODYtZGlzLmM6MzU0NzogcGFyc2UgDQplcnJvciBi ZWZvcmUgYEFUVFJJQlVURV9VTlVTRUQnPEJSPmkzODYtZGlzLmM6MzU0ODogcGFyc2UgZXJyb3Ig YmVmb3JlIA0KYEFUVFJJQlVURV9VTlVTRUQnPEJSPmkzODYtZGlzLmM6IEluIGZ1bmN0aW9uIGBP UF9NTVgnOjxCUj5pMzg2LWRpcy5jOjM1Njc6IA0KcGFyc2UgZXJyb3IgYmVmb3JlIGBBVFRSSUJV VEVfVU5VU0VEJzxCUj5pMzg2LWRpcy5jOjM1Njg6IHBhcnNlIGVycm9yIGJlZm9yZSANCmBBVFRS SUJVVEVfVU5VU0VEJzxCUj5pMzg2LWRpcy5jOiBJbiBmdW5jdGlvbiBgT1BfWE1NJzo8QlI+aTM4 Ni1kaXMuYzozNTc2OiANCnBhcnNlIGVycm9yIGJlZm9yZSBgQVRUUklCVVRFX1VOVVNFRCc8QlI+ aTM4Ni1kaXMuYzozNTc3OiBwYXJzZSBlcnJvciBiZWZvcmUgDQpgQVRUUklCVVRFX1VOVVNFRCc8 QlI+aTM4Ni1kaXMuYzogSW4gZnVuY3Rpb24gDQpgT1BfM0ROb3dTdWZmaXgnOjxCUj5pMzg2LWRp cy5jOjM2OTU6IHBhcnNlIGVycm9yIGJlZm9yZSANCmBBVFRSSUJVVEVfVU5VU0VEJzxCUj5pMzg2 LWRpcy5jOjM2OTY6IHBhcnNlIGVycm9yIGJlZm9yZSANCmBBVFRSSUJVVEVfVU5VU0VEJzxCUj5p Mzg2LWRpcy5jOiBJbiBmdW5jdGlvbiANCmBPUF9TSU1EX1N1ZmZpeCc6PEJSPmkzODYtZGlzLmM6 MzczNDogcGFyc2UgZXJyb3IgYmVmb3JlIA0KYEFUVFJJQlVURV9VTlVTRUQnPEJSPmkzODYtZGlz LmM6MzczNTogcGFyc2UgZXJyb3IgYmVmb3JlIA0KYEFUVFJJQlVURV9VTlVTRUQnPEJSPmkzODYt ZGlzLmM6IEluIGZ1bmN0aW9uIGBTSU1EX0ZpeHVwJzo8QlI+aTM4Ni1kaXMuYzozNzYyOiANCnBh cnNlIGVycm9yIGJlZm9yZSBgQVRUUklCVVRFX1VOVVNFRCc8QlI+bWFrZVsyXTogKioqIFtpMzg2 LWRpcy5vXSBFcnJvciANCjE8QlI+bWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3Jj L2xpbnV4LTIuNC45L2FyY2gvaTM4Ni9rZGInPEJSPm1ha2VbMV06IA0KKioqIFtmaXJzdF9ydWxl XSBFcnJvciAyPEJSPm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IA0KYC91c3Ivc3JjL2xpbnV4 LTIuNC45L2FyY2gvaTM4Ni9rZGInPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+dGh4LiA8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5zaW5jZXJlbHksIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPkp1bjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0044_01C1309B.74A614B0-- From owner-linux-xfs@oss.sgi.com Wed Aug 29 00:01:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T71Jh15754 for linux-xfs-outgoing; Wed, 29 Aug 2001 00:01:19 -0700 Received: from warp9.koschikode.com (pD9517C39.dip.t-dialin.net [217.81.124.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7T71Gd15734 for ; Wed, 29 Aug 2001 00:01:16 -0700 Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id 0512BCDED; Wed, 29 Aug 2001 09:01:14 +0200 (CEST) Message-ID: <3B8C9339.4D8A6BD3@koschikode.com> Date: Wed, 29 Aug 2001 09:01:13 +0200 From: Juri Haberland X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10-pre1-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: Lockup since 2.4.4 when switching from X to console References: <17766.999038162@ocs3.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Tue, 28 Aug 2001 21:40:57 +0200, > Juri Haberland wrote: > >Jani Jaakkola wrote: > > > >> There are lots of motherboards around which have somewhat broken APM > >> support or at least do not work correctly with Linux APM. Many of these > >> machines just hang, when console blanking or unblanking using APM is > >> attempted. This is not XFS spesific and is not even 2.4 kernel spesific. > > > >See, the point is that with a vanilla kernel it works without a problem > >but with the kdb patch applied it locks up. So somehow the kdb patch > >breaks the apm stuff and this should be investigated and, if possible, > >resolved. > > The kdb patch goes nowhere near apm. It sounds like apm has a bug that > is sensitive to the layout of the kernel or stack,particularly since > compiling without kdb configured on still has the problem. Ok. This and Jani Jaakkola's statement convinced me to leave that option alone... > Did you > compile the kernel with frame pointers on or with kallsyms and does > removing those options make a difference? I compiled the kernel without frame pointers and w/o kallsyms but I can do another test with these options on - just to see if it changes anything. Thanks, Juri From owner-linux-xfs@oss.sgi.com Wed Aug 29 01:02:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T82El17096 for linux-xfs-outgoing; Wed, 29 Aug 2001 01:02:14 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7T82Bd17077 for ; Wed, 29 Aug 2001 01:02:11 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA08979 for ; Wed, 29 Aug 2001 10:02:09 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id KAA12616 for linux-xfs@oss.sgi.com; Wed, 29 Aug 2001 10:02:08 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id D9DBC57306 for ; Wed, 29 Aug 2001 10:01:38 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 8F82625836 for ; Wed, 29 Aug 2001 10:01:38 +0200 (CEST) Message-ID: <3B8CA162.353AFFCE@ch.sauter-bc.com> Date: Wed, 29 Aug 2001 10:01:38 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: oops after rsync on XFS Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I was just syncing some files yesterday from my laptop the the server (Stock RH-7.1-XFS-1.0.1 with kernel 2.4.3-SGI_XFS_1.0.1) like everyday. But the server crashed and dropped into kdb. I was using rsync -av --delete ... and already had problems when syncing the laptop from the server at work. rsync just hung on the laptop and I was using cp to sync. But on the server at home rsync crashed it. On the rsync ml there was a message saying that removing the verbose options is the solution but nobody experienced an oops from rsync, just hanging. I'm now at work and tried to sync from a server to the laptop and removing -v does help. Will try it with the XFS server at home tonight. BTW: I'm doing the same syncing procedure almost everyday without any problem until now. I know its one new directory thats causing the hang/crash. -Simon From owner-linux-xfs@oss.sgi.com Wed Aug 29 01:19:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T8J1Y17477 for linux-xfs-outgoing; Wed, 29 Aug 2001 01:19:01 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7T8Iwd17439 for ; Wed, 29 Aug 2001 01:18:58 -0700 Received: (qmail 14677 invoked by uid 8); 29 Aug 2001 08:18:56 -0000 From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: Exim and XFS filesystem Date: Wed, 29 Aug 2001 09:57:06 +0200 Organization: spoiled dot org Lines: 27 Distribution: local Message-ID: References: <3B8BB7C7.4020808@omniti.com> <3B8BBB17.FD7AF0E5@sgi.com> Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.8-xfs (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > "Theo E. Schlossnagle" wrote: >> Exim v3.14,v3.22,v3.33 and Linux 2.4.2-xfs. The xfs parition in question is >> running atop a RAID-1 md device on two 9GB scsi drives. >> It looked as if the kernel had a thread stuck writing to or reading from the >> filesystem journal. If anyone knows a solution to this problem, I am all >> ears. Otherwise, steer clear of running you Exim spools on xfs. > My first suggestion would be to upgrade to XFS-1.0.1 if possible, > 2.4.2/XFS-1.0 is a bit old, and several fixes went into 1.0.1 1.0.1 is > available as a patch against vanilla 2.4.5, or coupled with Red Hat's > 2.4.3 kernel release for RH Linux 7.1. and if it still happens then i think it would be a good idea to setup a serial console and enable kdb - you should be able to break into the debugger then this happens and give more detailed information about the state ... other might describe what exactly to do then better ... t -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Wed Aug 29 01:19:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T8J2p17478 for linux-xfs-outgoing; Wed, 29 Aug 2001 01:19:02 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7T8Iwd17438 for ; Wed, 29 Aug 2001 01:18:58 -0700 Received: (qmail 23178 invoked by uid 8); 29 Aug 2001 08:18:56 -0000 From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: Data destruction Date: Wed, 29 Aug 2001 10:03:45 +0200 Organization: spoiled dot org Lines: 27 Distribution: local Message-ID: References: Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.8-xfs (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ivan Ivanov wrote: > Hi, > I spent two days to hack Slackware 8 installer and to add support for XFS > root filesystem and xfsprogs.tgz package. > Kernel is 2.4.6 patched for XFS. > I have the following problems: > 1. When XFS is root filesystem it can't be checked for errors. > Wnen I go to runlevel 1 and remount / readonly all xfs repair tools say > that filesystem is mounted. The only way is to make two boot disks with kernel > and static linked repair tools on ramdisk. some possible way around this is my miniroot framework (which is quite handy in other situations too) ... you may find it at http://people.spoiled.org/tgr/unix/miniroot/ maybe it helps someone ... t -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Wed Aug 29 01:25:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7T8PNF17775 for linux-xfs-outgoing; Wed, 29 Aug 2001 01:25:23 -0700 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 f7T8PJd17756 for ; Wed, 29 Aug 2001 01:25:19 -0700 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 f7T8Vra17839 for ; Wed, 29 Aug 2001 01:31:53 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA02945; Wed, 29 Aug 2001 19:23:56 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA50012; Wed, 29 Aug 2001 19:23:56 +1100 (AEDT) Date: Wed, 29 Aug 2001 19:23:55 +1100 From: Nathan Scott To: ivandi@vamo.orbitel.bg Cc: linux-xfs@oss.sgi.com Subject: Re: Data destruction Message-ID: <20010829192355.J323889@wobbly.melbourne.sgi.com> References: <20010829182949.I323889@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: ; from ivandi@vamo.orbitel.bg on Wed, Aug 29, 2001 at 11:05:02AM +0300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Aug 29, 2001 at 11:05:02AM +0300, ivandi@vamo.orbitel.bg wrote: > > On Wed, 29 Aug 2001, Nathan Scott wrote: > > > On Wed, Aug 29, 2001 at 10:17:40AM +0300, Ivan Ivanov wrote: > > > ... > > > I have downloded the latest versions last night so I will try. > > > The problem with xfs_check is that it trys to make a temporary file and if > > > the filesystem is readonly it fails - why ! > > > > I wasn't aware that xfs_check (xfs_db) would attempt to create > > a temporary file ... thats news to me, not sure where that is > > happening but sounds like it shouldn't be. > > ...[snip]... > > It outputs a message about trying to create tmpfile. > I can't send the exact text because I am not on my test machine. > This hapens only when xfs_check is checking root filesystem, when other > readonly filesystem is checked everything is OK. > Ah - I see where this is coming from now... looks like its cmd/xfsprogs/db/init.c, around line 65. So, it looks like xfs_check wont be able to run on root without a bit of work to make it so. It currently seems to set up a tmpfile for all of the commands coming in via the xfs_db "-c" option (xfs_check == xfs_db), so that it can batch multiple -c options up and run them all at once. [creating a tmp file seems like a bit of overkill.. hmm] Anyway, "xfs_repair -n" should be able to check the root filesystem though (I used xfs_repair for testing the libxfs readonly root changes, IIRC). Or, you can run xfs_db directly, and just type the commands in by hand rather than using xfs_check (xfs_check is just a shell script - see what it does and feed the commands in by hand). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 29 03:00:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TA0Md19492 for linux-xfs-outgoing; Wed, 29 Aug 2001 03:00:22 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TA0Hd19473 for ; Wed, 29 Aug 2001 03:00:17 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 78526C00FA6 for ; Wed, 29 Aug 2001 18:00:27 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.local [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0111BC00AC1 for ; Wed, 29 Aug 2001 18:00:25 +0800 (PHT) Date: Wed, 29 Aug 2001 18:00:25 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Interviews with developers of JFS, ReiserFS and XFS 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 fellow XFS users, I just thought I'd point to an article in OSNews with interviews done with Steve Best of IBM (JFS), Hans Reiser of Namesys (ReiserFS), and our very own Nathan Scott for XFS. I'm pretty happy with all three interviews, but am most pleased by the fact that instead of bashing each other like what we see with some other evil empires out there, these three "competitors" are helping each other out, sharing knowledge, and inevitably leading to infinitely more robust filesystems with Linux 2.4 now, and 2.6 in the near future, and beyond. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Wed Aug 29 03:31:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TAVpi20004 for linux-xfs-outgoing; Wed, 29 Aug 2001 03:31:51 -0700 Received: from atrey.karlin.mff.cuni.cz (root@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TAVld19985 for ; Wed, 29 Aug 2001 03:31:47 -0700 Received: (from jack@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id MAA15299; Wed, 29 Aug 2001 12:30:42 +0200 Date: Wed, 29 Aug 2001 12:30:42 +0200 From: Jan Kara To: Nathan Scott Cc: machack , linux-xfs@oss.sgi.com Subject: Re: Kernel Dump on quotaon Message-ID: <20010829123042.H8775@atrey.karlin.mff.cuni.cz> References: <20010828224031.JZQZ25401.femail45.sdc1.sfba.home.com@there> <20010829103155.G323889@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010829103155.G323889@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Aug 29, 2001 at 10:31:55AM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, > On Tue, Aug 28, 2001 at 06:21:59PM -0400, machack wrote: > > rc.sysinit cuases the kernel to dump when it hits quotaon. this problem only > > happens on kernels newer then 2.4.6 on these later kernels I have no > > problems when I pass devfs=nomount on boot. Am I the only one to have this > > problem or is it documented. my root partion is xfs. > > > > I'd be interested in seeing a kdb or ksymoops backtrace if you > can provide one. quotaon at startup is always ignored by XFS - > enabling quota is a mount time operation for XFS filesystems, so > this is likely to be a problem in the interaction between the > quotactl system call (takes a device special file as its second > argument) with Q_QUOTAON and devfs; and unrelated to XFS. > > If you only have XFS filesystems using quota (and no ext2/other > filesystems using quota), you can safely remove the "quotaon -a" > from your startup scripts (thats really not a very nice solution > though...) > > Jan, any chance you've come across this one before? I don't > remember there being anything new/changed in 2.4.6 in the quota > subsystem, so seems odd that this would suddenly start to fail. Hmm.. There were two minor changes in quota code in 2.4.6. The first one was just that remove_dquot_refs() gets super_block and not device. The second one was that we allow initialization of quotas on other inodes, than just symlinks, regular files and directories. The second one probably causes the problem but I can't see how... I'll look into it but the trace would be very helpful. Honza -- Jan Kara SuSE Labs From owner-linux-xfs@oss.sgi.com Wed Aug 29 04:41:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TBfdv21422 for linux-xfs-outgoing; Wed, 29 Aug 2001 04:41:39 -0700 Received: from smtp2.home.se (smtp2.home.se [195.66.35.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TBfZd21403 for ; Wed, 29 Aug 2001 04:41:35 -0700 Received: from home.se [217.215.31.238] by smtp2.home.se with Novonyx SMTP Server $Revision: 2.74 $; Wed, 29 Aug 2001 13:37:43 +0200 (ECTD) Message-ID: <3B8CD462.5090302@home.se> Date: Wed, 29 Aug 2001 13:39:14 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux XFS Mailing List Subject: Re: Interviews with developers of JFS, ReiserFS and XFS References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. > I just thought I'd point to an article in OSNews with interviews done with > Steve Best of IBM (JFS), Hans Reiser of Namesys (ReiserFS), and our very > own Nathan Scott for XFS. > > > > I'm pretty happy with all three interviews, but am most pleased by the > fact that instead of bashing each other like what we see with some other > evil empires out there, these three "competitors" are helping each other > out, sharing knowledge, and inevitably leading to infinitely more robust > filesystems with Linux 2.4 now, and 2.6 in the near future, and beyond. Well, what I read was sorta good except one line that I didn't like. How old is XFS and how old is ReiserFS? And now read this: quote Hans Reiser: " If you want the most widely tested journaling file system for use with "typical" file sizes, then use ReiserFS. If you want to stream multi-media data for Hollywood style applications, or use ACLs now rather than wait for Reiser4, you might want to use XFS." Is it only me or is that below the belt? "Hollywood style applications" ? // Stefan From owner-linux-xfs@oss.sgi.com Wed Aug 29 05:05:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TC5nE22054 for linux-xfs-outgoing; Wed, 29 Aug 2001 05:05:49 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TC5kd22035 for ; Wed, 29 Aug 2001 05:05:47 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.31 #1) id 15c46K-00037F-00; Wed, 29 Aug 2001 14:05:45 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f7TC5cA12817; Wed, 29 Aug 2001 08:05:38 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Du Jun" Cc: Subject: Re: umount lvm snapshot panic References: <003201c1303a$77d46850$4fb965d3@coldice> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 29 Aug 2001 08:05:38 -0400 In-Reply-To: <003201c1303a$77d46850$4fb965d3@coldice> Message-ID: Lines: 10 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 >>>>> "Du" == Du Jun writes: [LVM snapshot hang] Yes, we're aware of this. -- I'm working on it. -- 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 Wed Aug 29 05:11:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TCBFB22283 for linux-xfs-outgoing; Wed, 29 Aug 2001 05:11:15 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TCBCd22264 for ; Wed, 29 Aug 2001 05:11:12 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.31 #1) id 15c4Bb-00037k-00; Wed, 29 Aug 2001 14:11:12 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f7TCB7512822; Wed, 29 Aug 2001 08:11:07 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: linux-xfs@oss.sgi.com Subject: Re: Data destruction References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 29 Aug 2001 08:11:07 -0400 In-Reply-To: Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > 1. When XFS is root filesystem it can't be checked for errors. > Wnen I go to runlevel 1 and remount / readonly all xfs repair tools > say that filesystem is mounted. The only way is to make two boot > disks with kernel and static linked repair tools on ramdisk. I'd like to point out that we have a beta out of the Linuxcare Bootable Toolbox (formerly known as the BBC) which supports XFS. http://lbt.linuxcare.com/ -- 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 Wed Aug 29 06:17:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TDHV623542 for linux-xfs-outgoing; Wed, 29 Aug 2001 06:17:31 -0700 Received: from mplspop3.mpls.uswest.net (mplspop3.mpls.uswest.net [204.147.80.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TDHTd23523 for ; Wed, 29 Aug 2001 06:17:29 -0700 Received: (qmail 51531 invoked from network); 29 Aug 2001 13:17:27 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop3.mpls.uswest.net with SMTP; 29 Aug 2001 13:17:27 -0000 Date: Wed, 29 Aug 2001 08:13:38 -0500 Message-ID: <3B8CEA82.38A5FE74@sgi.com> From: "Eric Sandeen" To: "Simon Matter" Cc: "linux-xfs" 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 Subject: Re: oops after rsync on XFS References: <3B8CA162.353AFFCE@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > > Hello, > > I was just syncing some files yesterday from my laptop the the server > (Stock RH-7.1-XFS-1.0.1 with kernel 2.4.3-SGI_XFS_1.0.1) like everyday. > But the server crashed and dropped into kdb. Did kdb provide any useful information? Can you do a backtrace (bt) and see where things were going when it crashed? -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 Aug 29 06:22:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TDMZa23745 for linux-xfs-outgoing; Wed, 29 Aug 2001 06:22:35 -0700 Received: from mplspop3.mpls.uswest.net (mplspop3.mpls.uswest.net [204.147.80.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TDMWd23726 for ; Wed, 29 Aug 2001 06:22:32 -0700 Received: (qmail 57576 invoked from network); 29 Aug 2001 13:22:31 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop3.mpls.uswest.net with SMTP; 29 Aug 2001 13:22:31 -0000 Date: Wed, 29 Aug 2001 08:18:42 -0500 Message-ID: <3B8CEBB2.9ADF95E1@sgi.com> From: "Eric Sandeen" To: "Stefan Smietanowski" Cc: "Linux XFS Mailing List" 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 Subject: Re: Interviews with developers of JFS, ReiserFS and XFS References: <3B8CD462.5090302@home.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stefan Smietanowski wrote: > "Hollywood style applications" ? I assume he means video streaming and editing... Just snip his quote down: > quote Hans Reiser: > > " ...you might want to use XFS." ;-) -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 Aug 29 07:27:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TER7N24966 for linux-xfs-outgoing; Wed, 29 Aug 2001 07:27:07 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TER5d24946 for ; Wed, 29 Aug 2001 07:27:05 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 6408E1AB12 for ; Wed, 29 Aug 2001 10:27:04 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 1F7B3650; Wed, 29 Aug 2001 10:27:02 -0400 (EDT) Date: Wed, 29 Aug 2001 10:27:02 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Problems with DAT tape.... Message-ID: <20010829102702.B7083@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <002501c12fea$b1091620$50824e40@iboats.com> <20010829103705.H114864@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010829103705.H114864@boing.melbourne.sgi.com> User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 29, 2001 at 10:37:05AM +1100, Timothy Shimmin wrote: > I would recommend just putting the scsi tape driver into > variable block sized mode. > > # mt -f /dev/st0 setblk 0 We've found that doing this on certain tape drives - especially when you're trying to read the data back - can lead to pretty significant slowdowns. So you might want to do a little testing in your particular environment before you go ahead and do this... Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Aug 29 09:53:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TGrpr28060 for linux-xfs-outgoing; Wed, 29 Aug 2001 09:53:51 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TGrld28040 for ; Wed, 29 Aug 2001 09:53:48 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 4F8011AB11 for ; Wed, 29 Aug 2001 12:53:47 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id B96DE652; Wed, 29 Aug 2001 12:53:46 -0400 (EDT) Date: Wed, 29 Aug 2001 12:53:46 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Patches, again... Message-ID: <20010829125345.E7083@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, all. I've been searching through the archives, trying to figure out what the README in oss.sgi.com/projects/xfs/download/patches/ means, and haven't been able to nail it down. Quote: patch-2.4.x-xfs-cvs-.bz2 ...Do not use this patch unless you are willing stay up-to-date with "current". As I understand it from reading earlier mail on the subject, the -cvs- patches are just snapshots of the CVS tree taken every once in a while, with no testing, etc. I _do_ want to stay up to date with "current" XFS code, for the most part - I want the fixes since 1.0.1 - but as I understand it, I _don't_ want this patch, since it's probably not stable and may not even compile. patch-2.4.x-xfs-.bz2 ...Patches to take a vanilla linux 2.4.x tree to an xfs capable kernel. But what does "an xfs capable kernel" mean in this case? Do the patches produce a kernel with XFS-1.0.1? Or do they incorporate fixes that have occured since then (which is what I want)? Thanks. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Aug 29 10:46:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7THkVR29093 for linux-xfs-outgoing; Wed, 29 Aug 2001 10:46:31 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7THkPd29074 for ; Wed, 29 Aug 2001 10:46:26 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA06488 for ; Wed, 29 Aug 2001 10:46:24 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2844922; Wed, 29 Aug 2001 12:45:02 -0500 (CDT) Received: from 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 MAA46030; Wed, 29 Aug 2001 12:45:01 -0500 (CDT) Message-ID: <3B8D29F8.6A3F88C5@sgi.com> Date: Wed, 29 Aug 2001 12:44:24 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Klaassen CC: linux-xfs@oss.sgi.com Subject: Re: Patches, again... References: <20010829125345.E7083@dkp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Klaassen wrote: > patch-2.4.x-xfs-cvs-.bz2 > ...Do not use this patch unless you are willing stay > up-to-date with "current". Ok, I should change that. You _can_ use it, but the only reason you might want to use it is to seed a CVS tree. > As I understand it from reading earlier mail on the subject, the > -cvs- patches are just snapshots of the CVS tree taken every > once in a while, with no testing, etc. Any patch not under a Release-*/ directory should be considered an untested snapshot. In reality, we test things before we check them in, but nowhere near the testing a release is subjected to. > patch-2.4.x-xfs-.bz2 > ...Patches to take a vanilla linux 2.4.x tree to an xfs > capable kernel. > > But what does "an xfs capable kernel" mean in this case? It means a kernel which contains code in fs/xfs... > Do the > patches produce a kernel with XFS-1.0.1? No... > Or do they incorporate > fixes that have occured since then (which is what I want)? Yes, XFS fixes as well as base kernel updates. To back up a bit, kernel code in patch-2.4.x-xfs-cvs-.bz2 and patch-2.4.x-xfs-.bz2 is identical - the -cvs- version has all the cvs version information, as well as command source tree. -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 Aug 29 10:46:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7THkc229127 for linux-xfs-outgoing; Wed, 29 Aug 2001 10:46:38 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7THkYd29108 for ; Wed, 29 Aug 2001 10:46:34 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id TAA28198; Wed, 29 Aug 2001 19:46:32 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA18487; Wed, 29 Aug 2001 19:46:32 +0200 (CEST) Date: Wed, 29 Aug 2001 19:46:31 +0200 (CEST) From: Seth Mos To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: Patches, again... In-Reply-To: <20010829125345.E7083@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 Wed, 29 Aug 2001, Andrew Klaassen wrote: > Hi, all. > > I've been searching through the archives, trying to figure out > what the README in oss.sgi.com/projects/xfs/download/patches/ > means, and haven't been able to nail it down. Quote: > > patch-2.4.x-xfs-cvs-.bz2 > ...Do not use this patch unless you are willing stay > up-to-date with "current". > > As I understand it from reading earlier mail on the subject, the > -cvs- patches are just snapshots of the CVS tree taken every > once in a while, with no testing, etc. I _do_ want to stay up > to date with "current" XFS code, for the most part - I want the > fixes since 1.0.1 - but as I understand it, I _don't_ want this > patch, since it's probably not stable and may not even compile. > > patch-2.4.x-xfs-.bz2 > ...Patches to take a vanilla linux 2.4.x tree to an xfs > capable kernel. > > But what does "an xfs capable kernel" mean in this case? Do the > patches produce a kernel with XFS-1.0.1? Or do they incorporate > fixes that have occured since then (which is what I want)? This patch contains fixes that also are in the CVS tree. The only 1.0.1 is the 2.4.3 or 2.4.5 kernel that come on the CD. The cvs patch is for setting up a local CVS tree without doing it completely with cvs which is rather bandwidth inefficient. If you want to have a linus kernel with XFS the latter patch is what you want. The CVS tree tracks the linux -pre series which might be a bit to new for you. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Aug 29 11:25:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TIPsj30093 for linux-xfs-outgoing; Wed, 29 Aug 2001 11:25:54 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TIPpd30074 for ; Wed, 29 Aug 2001 11:25:51 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 22B161AB11 for ; Wed, 29 Aug 2001 14:25:50 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 96591652; Wed, 29 Aug 2001 14:25:49 -0400 (EDT) Date: Wed, 29 Aug 2001 14:25:49 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Patches, again... Message-ID: <20010829142548.F7083@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010829125345.E7083@dkp.com> <3B8D29F8.6A3F88C5@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B8D29F8.6A3F88C5@sgi.com> User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 29, 2001 at 12:44:24PM -0500, Eric Sandeen wrote: > To back up a bit, kernel code in > patch-2.4.x-xfs-cvs-.bz2 and patch-2.4.x-xfs-.bz2 > is identical - the -cvs- version has all the cvs version > information, as well as command source tree. Ah. So they'd both track the pre- kernels and the like, then, the way that the CVS tree does? Or are they both created only when the CVS tree is exactly in line with a virgin 2.4.x kernel, not following the CVS tree as it tracks 2.4.x-pre-N kernels? Thanks. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Aug 29 11:47:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TIlkc30571 for linux-xfs-outgoing; Wed, 29 Aug 2001 11:47:46 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TIlhd30550 for ; Wed, 29 Aug 2001 11:47:43 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA15029 for ; Wed, 29 Aug 2001 11:47:24 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2803502; Wed, 29 Aug 2001 13:46:26 -0500 (CDT) Received: from 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 NAA15398; Wed, 29 Aug 2001 13:46:25 -0500 (CDT) Message-ID: <3B8D385B.541CCF4A@sgi.com> Date: Wed, 29 Aug 2001 13:45:47 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Klaassen CC: linux-xfs@oss.sgi.com Subject: Re: Patches, again... References: <20010829125345.E7083@dkp.com> <3B8D29F8.6A3F88C5@sgi.com> <20010829142548.F7083@dkp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Klaassen wrote: > So they'd both track the pre- kernels and the like, then, the > way that the CVS tree does? > > Or are they both created only when the CVS tree is exactly in > line with a virgin 2.4.x kernel, not following the CVS tree as > it tracks 2.4.x-pre-N kernels? The patches/ directory is updated by a cron job every... Saturday(?) night, but I also sometimes do it manually to get a 2.4.x (not -preX) snapshot before we bump up to a -preX release. So the patches/ dir should never be more than a week old, and hopefully also has patches for past "point" releases of Linus' kernel. In short, it's a mix, and it may have -pre patches in there as well as point-release patches. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Aug 29 13:06:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TK6b432369 for linux-xfs-outgoing; Wed, 29 Aug 2001 13:06:37 -0700 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 f7TK6Nd32349 for ; Wed, 29 Aug 2001 13:06:23 -0700 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 f7TKCxa31169 for ; Wed, 29 Aug 2001 13:12:59 -0700 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 PAA2836899 for ; Wed, 29 Aug 2001 15:05:02 -0500 (CDT) 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 PAA66389 for ; Wed, 29 Aug 2001 15:05:01 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7TK4MF31555; Wed, 29 Aug 2001 15:04:22 -0500 Message-Id: <200108292004.f7TK4MF31555@stout.americas.sgi.com> Date: Wed, 29 Aug 2001 15:04:22 -0500 From: Eric Sandeen Subject: TAKE - Merge up to 2.4.10-pre2 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Aug 29 12:58:40 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101848a linux/arch/ppc/mm/4xx_mmu.c - 1.1 linux/drivers/usb/usbnet.c - 1.1 linux/arch/ppc/mm/cachemap.c - 1.1 linux/arch/ppc/mm/mmu_context.c - 1.1 linux/arch/ppc/kernel/temp.c - 1.1 linux/arch/ppc/mm/mmu_decl.h - 1.1 linux/arch/ppc/mm/pgtable.c - 1.1 linux/arch/ppc/mm/ppc_mmu.c - 1.1 linux/arch/ppc/mm/tlb.c - 1.1 linux/include/asm-ppc/btext.h - 1.1 linux/arch/ppc/kernel/pmac_smp.c - 1.1 linux/include/asm-ppc/cputable.h - 1.1 linux/arch/ppc/boot/common/ofcommon.c - 1.1 linux/arch/ppc/kernel/l2cr.S - 1.1 linux/arch/ppc/kernel/cputable.c - 1.1 linux/arch/ppc/kernel/chrp_smp.c - 1.1 linux/arch/ppc/kernel/btext.c - 1.1 linux/net/socket.c - 1.24 linux/net/ipv4/tcp.c - 1.29 linux/net/ipv4/sysctl_net_ipv4.c - 1.12 linux/net/ipv4/icmp.c - 1.21 linux/net/appletalk/ddp.c - 1.18 linux/mm/page_alloc.c - 1.52 linux/mm/filemap.c - 1.83 linux/lib/Makefile - 1.7 linux/kernel/sysctl.c - 1.39 linux/kernel/ksyms.c - 1.102 linux/include/linux/vt_kern.h - 1.5 linux/include/linux/sysctl.h - 1.34 linux/include/linux/slab.h - 1.16 linux/include/linux/ntfs_fs_sb.h - 1.9 linux/include/linux/ntfs_fs_i.h - 1.7 linux/include/linux/ntfs_fs.h - 1.4 linux/include/linux/mm.h - 1.60 linux/include/linux/kernel.h - 1.23 linux/include/linux/fs.h - 1.112 linux/include/asm-sparc64/vaddrs.h - 1.3 linux/include/asm-sparc64/pgtable.h - 1.21 linux/include/asm-sparc64/mmu_context.h - 1.13 linux/include/asm-sparc64/keyboard.h - 1.4 linux/include/asm-sparc64/floppy.h - 1.13 linux/include/asm-sparc/keyboard.h - 1.5 linux/include/asm-ppc/timex.h - 1.6 linux/include/asm-ppc/system.h - 1.19 linux/include/asm-ppc/spinlock.h - 1.11 linux/include/asm-ppc/smp.h - 1.13 linux/include/asm-ppc/residual.h - 1.5 linux/include/asm-ppc/prom.h - 1.13 linux/include/asm-ppc/processor.h - 1.27 linux/include/asm-ppc/param.h - 1.5 linux/include/asm-ppc/page.h - 1.13 linux/include/asm-ppc/mmu_context.h - 1.11 linux/include/asm-ppc/mbx.h - 1.7 linux/include/asm-ppc/machdep.h - 1.17 linux/include/asm-ppc/keyboard.h - 1.9 linux/include/asm-ppc/io.h - 1.14 linux/include/asm-ppc/ide.h - 1.12 linux/include/asm-ppc/feature.h - 1.11 linux/include/asm-ppc/fads.h - 1.4 linux/include/asm-ppc/elf.h - 1.10 linux/include/asm-ppc/bootinfo.h - 1.8 linux/include/asm-ppc/atomic.h - 1.8 linux/include/asm-i386/keyboard.h - 1.9 linux/include/asm-alpha/keyboard.h - 1.6 linux/fs/umsdos/rdir.c - 1.12 linux/fs/umsdos/ioctl.c - 1.8 linux/fs/umsdos/dir.c - 1.16 linux/fs/super.c - 1.51 linux/fs/pipe.c - 1.22 linux/fs/ntfs/support.c - 1.9 linux/fs/ntfs/super.h - 1.6 linux/fs/ntfs/super.c - 1.10 linux/fs/ntfs/struct.h - 1.6 linux/fs/ntfs/inode.c - 1.11 linux/fs/ntfs/fs.c - 1.29 linux/fs/ntfs/dir.c - 1.7 linux/fs/ntfs/attr.c - 1.6 linux/fs/ntfs/Makefile - 1.10 linux/fs/msdos/namei.c - 1.19 linux/fs/dquot.c - 1.33 linux/fs/buffer.c - 1.80 linux/fs/block_dev.c - 1.24 linux/fs/affs/super.c - 1.11 linux/fs/affs/namei.c - 1.13 linux/fs/affs/inode.c - 1.14 linux/fs/affs/amigaffs.c - 1.7 linux/fs/affs/Changes - 1.6 linux/drivers/usb/usb.c - 1.54 linux/drivers/usb/Makefile - 1.40 linux/drivers/usb/Config.in - 1.44 linux/drivers/scsi/sr.c - 1.27 linux/drivers/sbus/char/pcikbd.c - 1.21 linux/drivers/char/vt.c - 1.20 linux/drivers/char/pc_keyb.c - 1.24 linux/arch/sparc64/mm/modutil.c - 1.9 linux/arch/sparc64/mm/init.c - 1.29 linux/arch/sparc64/mm/fault.c - 1.17 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.31 linux/arch/sparc64/kernel/smp.c - 1.27 linux/arch/sparc64/kernel/itlb_base.S - 1.6 linux/arch/sparc64/kernel/entry.S - 1.15 linux/arch/sparc64/kernel/dtlb_base.S - 1.8 linux/arch/sparc64/kernel/dtlb_backend.S - 1.7 linux/arch/sparc64/defconfig - 1.46 linux/arch/sparc/boot/btfixupprep.c - 1.3 linux/arch/ppc/vmlinux.lds - 1.10 linux/arch/ppc/mm/init.c - 1.36 linux/arch/ppc/mm/Makefile - 1.7 linux/arch/ppc/lib/locks.c - 1.8 linux/arch/ppc/lib/checksum.S - 1.6 linux/arch/ppc/kernel/traps.c - 1.21 linux/arch/ppc/kernel/time.c - 1.15 linux/arch/ppc/kernel/smp.c - 1.26 linux/arch/ppc/kernel/setup.c - 1.34 linux/arch/ppc/kernel/prom.c - 1.25 linux/arch/ppc/kernel/process.c - 1.30 linux/arch/ppc/kernel/prep_setup.c - 1.22 linux/arch/ppc/kernel/prep_pci.c - 1.12 linux/arch/ppc/kernel/ppc_ksyms.c - 1.34 linux/arch/ppc/kernel/ppc_htab.c - 1.14 linux/arch/ppc/kernel/pmac_time.c - 1.13 linux/arch/ppc/kernel/pmac_setup.c - 1.23 linux/arch/ppc/kernel/pmac_pic.h - 1.5 linux/arch/ppc/kernel/pmac_pic.c - 1.19 linux/arch/ppc/kernel/pmac_pci.c - 1.17 linux/arch/ppc/kernel/open_pic.h - 1.9 linux/arch/ppc/kernel/open_pic.c - 1.19 linux/arch/ppc/kernel/mk_defs.c - 1.13 linux/arch/ppc/kernel/misc.S - 1.31 linux/arch/ppc/kernel/irq.c - 1.31 linux/arch/ppc/kernel/idle.c - 1.17 linux/arch/ppc/kernel/head.S - 1.28 linux/arch/ppc/kernel/feature.c - 1.14 linux/arch/ppc/kernel/chrp_setup.c - 1.24 linux/arch/ppc/kernel/apus_setup.c - 1.17 linux/arch/ppc/kernel/Makefile - 1.24 linux/arch/ppc/defconfig - 1.33 linux/arch/ppc/config.in - 1.39 linux/arch/ppc/boot/Makefile - 1.16 linux/arch/ppc/Makefile - 1.20 linux/Makefile - 1.116 linux/Documentation/filesystems/ntfs.txt - 1.8 linux/Documentation/Configure.help - 1.95 linux/drivers/usb/printer.c - 1.38 linux/drivers/i2o/i2o_block.c - 1.26 linux/arch/ppc/xmon/start.c - 1.16 linux/arch/ppc/kernel/ppc_asm.h - 1.8 linux/arch/ppc/kernel/head_8xx.S - 1.12 linux/arch/ppc/kernel/gemini_setup.c - 1.18 linux/arch/ppc/kernel/entry.S - 1.22 linux/arch/sparc64/kernel/pci_sabre.c - 1.24 linux/arch/sparc64/kernel/pci_psycho.c - 1.21 linux/arch/sparc64/kernel/pci_iommu.c - 1.11 linux/arch/ppc/kernel/sleep.S - 1.5 linux/arch/ppc/kernel/m8xx_setup.c - 1.15 linux/include/asm-ppc/rpxlite.h - 1.4 linux/include/asm-ppc/bseip.h - 1.3 linux/include/asm-ppc/rpxclassic.h - 1.6 linux/mm/highmem.c - 1.25 linux/fs/proc/proc_misc.c - 1.20 linux/drivers/usb/dc2xx.c - 1.20 linux/arch/ppc/kernel/pmac_nvram.c - 1.9 linux/arch/ppc/kernel/oak_setup.c - 1.7 linux/arch/ppc/configs/walnut_defconfig - 1.13 linux/arch/ppc/configs/oak_defconfig - 1.13 linux/arch/ppc/configs/mbx_defconfig - 1.8 linux/arch/ppc/configs/gemini_defconfig - 1.15 linux/arch/ppc/configs/common_defconfig - 1.21 linux/arch/ppc/configs/apus_defconfig - 1.9 linux/drivers/pcmcia/yenta.c - 1.26 linux/arch/sparc64/kernel/sbus.c - 1.11 linux/arch/sparc64/kernel/iommu_common.h - 1.2 linux/arch/sparc64/kernel/iommu_common.c - 1.5 linux/include/asm-sparc64/pgalloc.h - 1.12 linux/drivers/usb/inode.c - 1.15 linux/drivers/usb/usb-uhci.h - 1.9 linux/drivers/usb/usb-uhci.c - 1.24 linux/drivers/usb/rio500.c - 1.13 linux/drivers/usb/pegasus.c - 1.20 linux/drivers/ide/via82cxxx.c - 1.16 linux/drivers/usb/mdc800.c - 1.12 linux/drivers/usb/serial/ftdi_sio.c - 1.20 linux/drivers/usb/serial/usbserial.c - 1.19 linux/drivers/usb/serial/whiteheat.c - 1.16 linux/drivers/usb/serial/visor.h - 1.5 linux/drivers/usb/serial/visor.c - 1.19 linux/fs/partitions/ibm.c - 1.7 linux/drivers/usb/serial/digi_acceleport.c - 1.14 linux/arch/ppc/kernel/m8260_setup.c - 1.10 linux/drivers/s390/block/dasd.c - 1.10 linux/fs/pagebuf/page_buf_io.c - 1.95 linux/include/asm-ppc/time.h - 1.7 linux/drivers/usb/serial/keyspan.c - 1.12 linux/drivers/usb/bluetooth.c - 1.14 linux/lib/dec_and_lock.c - 1.2 linux/arch/ppc/configs/rpxlite_defconfig - 1.8 linux/arch/ppc/configs/rpxcllf_defconfig - 1.9 linux/arch/ppc/configs/est8260_defconfig - 1.9 linux/arch/ppc/configs/bseip_defconfig - 1.8 linux/drivers/media/video/videodev.c - 1.7 linux/drivers/md/lvm.c - 1.16 linux/drivers/usb/net1080.c - 1.7 linux/include/asm-ppc/keylargo.h - 1.4 linux/include/asm-ppc/uninorth.h - 1.4 linux/drivers/usb/serial/belkin_sa.c - 1.9 linux/drivers/usb/serial/mct_u232.c - 1.8 linux/drivers/usb/serial/empeg.c - 1.10 linux/drivers/usb/serial/Config.in - 1.7 linux/mm/shmem.c - 1.12 linux/arch/sparc64/kernel/pci_schizo.c - 1.9 linux/arch/ppc/kernel/open_pic_defs.h - 1.4 linux/arch/ppc/configs/power3_defconfig - 1.6 linux/arch/ppc/configs/ibmchrp_defconfig - 1.6 linux/drivers/s390/block/xpram.c - 1.4 linux/include/asm-ppc/tqm8xx.h - 1.4 linux/include/asm-ppc/ivms8.h - 1.3 linux/drivers/usb/serial/io_edgeport.h - 1.2 linux/drivers/usb/serial/io_edgeport.c - 1.7 linux/arch/ppc/configs/TQM860L_defconfig - 1.6 linux/arch/ppc/configs/TQM850L_defconfig - 1.6 linux/arch/ppc/configs/TQM823L_defconfig - 1.6 linux/arch/ppc/configs/SPD823TS_defconfig - 1.6 linux/arch/ppc/configs/SM850_defconfig - 1.6 linux/arch/ppc/configs/IVMS8_defconfig - 1.6 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.2 linux/arch/ppc/boot/prep/vreset.c - 1.2 linux/arch/ppc/boot/prep/misc.c - 1.4 linux/arch/ppc/boot/prep/head.S - 1.2 linux/arch/ppc/boot/prep/Makefile - 1.4 linux/arch/ppc/boot/pmac/start.c - 1.2 linux/arch/ppc/boot/pmac/coffmain.c - 1.3 linux/arch/ppc/boot/pmac/chrpmain.c - 1.3 linux/arch/ppc/boot/pmac/Makefile - 1.4 linux/arch/ppc/boot/mbx/misc.c - 1.3 linux/arch/ppc/boot/include/nonstdio.h - 1.2 linux/arch/ppc/boot/common/ns16550.c - 1.2 linux/arch/ppc/boot/common/misc-simple.c - 1.2 linux/arch/ppc/boot/common/misc-common.c - 1.5 linux/arch/ppc/boot/common/crt0.S - 1.2 linux/arch/ppc/boot/chrp/start.c - 1.2 linux/arch/ppc/boot/chrp/main.c - 1.3 linux/arch/ppc/boot/chrp/Makefile - 1.3 linux/drivers/usb/serial/cyberjack.c - 1.2 linux/arch/ppc/mm/hashtable.S - 1.2 linux/drivers/usb/usb-skeleton.c - 1.2 linux/fs/ntfs/unistr.c - 1.4 linux/fs/ntfs/unistr.h - 1.2 linux/drivers/usb/kaweth.c - 1.3 - merge up to 2.4.10-pre2 From owner-linux-xfs@oss.sgi.com Wed Aug 29 15:52:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TMqG403651 for linux-xfs-outgoing; Wed, 29 Aug 2001 15:52:16 -0700 Received: from finn.cns.montana.edu (finn.cns.montana.edu [153.90.178.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TMq9d03628 for ; Wed, 29 Aug 2001 15:52:09 -0700 Received: from case.cns.montana.edu (case.cns.montana.edu [153.90.178.21]) by finn.cns.montana.edu (8.9.3/8.9.3) with ESMTP id QAA21929; Wed, 29 Aug 2001 16:51:48 -0600 (MDT) Date: Wed, 29 Aug 2001 16:51:48 -0600 From: Gary Orser To: Tad Dolphay cc: linux-xfs@oss.sgi.com Subject: Re: nfs3 problems w/xfs? In-Reply-To: <200108290145.UAA79114@fsgi158.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 Tad, Hmm, It looks like nfs3 wasn't working. I upgraded to 4.5.9, with the 4.5.9-xfs patches and now nfs3 works ok, however: (must have been the version of nfs-utils) I just copied a large file from the sgi server to this linux box (512m 1.4g Athlon) and the box got buried. Over a 100mb switched line a 3G file took 26 minutes, ok not spectacular. Load average was over 7, system cpu % was over 85%. The single processor on the origin 2000 (r10000) running nfsd was barely turning over. Terminal response was just barely usable on the linux box. (e.g. it took 4 min. to get top running in another console window) This was an ide drive but still... Adding to this a little later on... I did a little further stress testing dd if=/dev/zero of=./test bs=1M count=3000 xfs=23 mins ext2=22 mins eliminating nfs and xfs same buried processor. It must be a kernel thing. kswapd and kupdated were the big cpu hogs, although there was never any swap used. Any ideas? Cheers, Gary ------------------------------------------------------ Gary Orser , (406) 994-6451, orser@nervana.montana.edu Montana State University Center for Computational Biology 1 Lewis Hall, Bozeman MT, 59717 On Tue, 28 Aug 2001, Tad Dolphay wrote: > > > > Tad, > > > > xfs-linux was the client, Irix the server. > > > Gary, > > Assuming you can use 4g files locally on the xfs-linux machine without > problems and can use 4g files locally on the Irix machine without problems > then I think a snoop from the Irix machine would still be useful. > > Thanks, > Tad > > Cheers, Gary > > ------------------------------------------------------ > > Gary Orser , (406) 994-6451, orser@nervana.montana.edu > > Montana State University > > Center for Computational Biology > > 1 Lewis Hall, Bozeman MT, 59717 > > > > On Tue, 28 Aug 2001, Tad Dolphay wrote: > > > > > > > > > > Hi, > > > > > > > > I've installed linux 2.4.5, with xfs on a Suse 7.1 base install. > > > > > > > > Got xfs working as well as nfs3 between an Irix 6.5.13m system. > > > > > > > > > > Gary, > > > > > > I assume xfs-linux is NFS server and Irix is NFS client? I've used 10g > > > files without problems. Maybe a snoop from the Irix side would tell us > > > something. > > > > > > Thanks, > > > Tad > > > > > > > I can copy files < 2g, but get errors on large files > 4g. > > > > cannot stat 'somelargefile' Input/output error > > > > > > > > I've searched through the faq and group lists but can't > > > > find anything related. > > > > > > > > The only thing I haven't been able to try is kgcc and/or > > > > the egcs compiler. I can't find these for the Suse distro. > > > > > > > > Cheers, Gary > > > > ------------------------------------------------------ > > > > Gary Orser , (406) 994-6451, orser@nervana.montana.edu > > > > Montana State University > > > > Center for Computational Biology > > > > 1 Lewis Hall, Bozeman MT, 59717 > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Wed Aug 29 16:23:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TNNYb04416 for linux-xfs-outgoing; Wed, 29 Aug 2001 16:23:34 -0700 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 f7TNNRd04397 for ; Wed, 29 Aug 2001 16:23:27 -0700 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 f7TNT2810206 for ; Wed, 29 Aug 2001 16:29:02 -0700 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 SAA2847629; Wed, 29 Aug 2001 18:22:06 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA95313; Wed, 29 Aug 2001 18:22:05 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7TNKt621071; Wed, 29 Aug 2001 18:20:55 -0500 Message-Id: <200108292320.f7TNKt621071@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Gary Orser cc: Tad Dolphay , linux-xfs@oss.sgi.com Subject: Re: nfs3 problems w/xfs? In-Reply-To: Message from Gary Orser of "Wed, 29 Aug 2001 16:51:48 MDT." Date: Wed, 29 Aug 2001 18:20:55 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is starting to look more like question for the linux kernel mailing list, or possibly the linux-mm mailing list. Looks like another virtual memory system issue. Steve > Tad, > > Hmm, It looks like nfs3 wasn't working. > > I upgraded to 4.5.9, with the 4.5.9-xfs patches > and now nfs3 works ok, however: > (must have been the version of nfs-utils) > > I just copied a large file from the sgi server to this linux box > (512m 1.4g Athlon) and the box got buried. > > Over a 100mb switched line a 3G file took 26 minutes, ok not spectacular. > > Load average was over 7, system cpu % was over 85%. > > The single processor on the origin 2000 (r10000) running nfsd was barely > turning over. > > Terminal response was just barely usable on the linux box. > (e.g. it took 4 min. to get top running in another console window) > > This was an ide drive but still... > > Adding to this a little later on... > I did a little further stress testing > > dd if=/dev/zero of=./test bs=1M count=3000 > xfs=23 mins > ext2=22 mins > eliminating nfs and xfs > same buried processor. It must be a kernel thing. > > kswapd and kupdated were the big cpu hogs, although > there was never any swap used. > > Any ideas? > > Cheers, Gary > ------------------------------------------------------ > Gary Orser , (406) 994-6451, orser@nervana.montana.edu > Montana State University > Center for Computational Biology > 1 Lewis Hall, Bozeman MT, 59717 > > On Tue, 28 Aug 2001, Tad Dolphay wrote: > > > > > > > Tad, > > > > > > xfs-linux was the client, Irix the server. > > > > > Gary, > > > > Assuming you can use 4g files locally on the xfs-linux machine without > > problems and can use 4g files locally on the Irix machine without problems > > then I think a snoop from the Irix machine would still be useful. > > > > Thanks, > > Tad > > > Cheers, Gary > > > ------------------------------------------------------ > > > Gary Orser , (406) 994-6451, orser@nervana.montana.edu > > > Montana State University > > > Center for Computational Biology > > > 1 Lewis Hall, Bozeman MT, 59717 > > > > > > On Tue, 28 Aug 2001, Tad Dolphay wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > I've installed linux 2.4.5, with xfs on a Suse 7.1 base install. > > > > > > > > > > Got xfs working as well as nfs3 between an Irix 6.5.13m system. > > > > > > > > > > > > > Gary, > > > > > > > > I assume xfs-linux is NFS server and Irix is NFS client? I've used 10g > > > > files without problems. Maybe a snoop from the Irix side would tell us > > > > something. > > > > > > > > Thanks, > > > > Tad > > > > > > > > > I can copy files < 2g, but get errors on large files > 4g. > > > > > cannot stat 'somelargefile' Input/output error > > > > > > > > > > I've searched through the faq and group lists but can't > > > > > find anything related. > > > > > > > > > > The only thing I haven't been able to try is kgcc and/or > > > > > the egcs compiler. I can't find these for the Suse distro. > > > > > > > > > > Cheers, Gary > > > > > ------------------------------------------------------ > > > > > Gary Orser , (406) 994-6451, orser@nervana.montana.edu > > > > > Montana State University > > > > > Center for Computational Biology > > > > > 1 Lewis Hall, Bozeman MT, 59717 > > > > > > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Wed Aug 29 16:53:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TNrmT05054 for linux-xfs-outgoing; Wed, 29 Aug 2001 16:53:48 -0700 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 f7TNrkd05035 for ; Wed, 29 Aug 2001 16:53:46 -0700 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 f7U00Ka08196 for ; Wed, 29 Aug 2001 17:00:20 -0700 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05168; Thu, 30 Aug 2001 10:52:18 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Du Jun" cc: linux-xfs@oss.sgi.com Subject: Re: kdb not compile In-reply-to: Your message of "Wed, 29 Aug 2001 15:01:17 +0800." <004701c13058$66a2dfd0$4fb965d3@coldice> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Aug 2001 09:52:18 +1000 Message-ID: <29971.999129138@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Please do not send mail to this list using MIME. Your mail had both text and HTML and the text was base64 encoded. Use just plain text. On Wed, 29 Aug 2001 15:01:17 +0800, "Du Jun" wrote: >i386-dis.c: In function `print_insn_i386': >i386-dis.c:2143: `bfd_mach_i386_i386_intel_syntax' undeclared (first use in this function) Upgrade your binutils. kdb needs at least binutils-2.9.5.0.22. From owner-linux-xfs@oss.sgi.com Wed Aug 29 20:18:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7U3Ikj08282 for linux-xfs-outgoing; Wed, 29 Aug 2001 20:18:46 -0700 Received: from femail16.sdc1.sfba.home.com (femail16.sdc1.sfba.home.com [24.0.95.143]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7U3Ifd08262 for ; Wed, 29 Aug 2001 20:18:41 -0700 Received: from there ([24.10.81.118]) by femail16.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010830031841.BKSU1331.femail16.sdc1.sfba.home.com@there>; Wed, 29 Aug 2001 20:18:41 -0700 Content-Type: text/plain; charset="iso-8859-1" From: machack Reply-To: machack@sscsonline.org Organization: SSCS To: Jan Kara , Nathan Scott Subject: Re: Kernel Dump on quotaon Date: Wed, 29 Aug 2001 23:00:42 -0400 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <20010828224031.JZQZ25401.femail45.sdc1.sfba.home.com@there> <20010829103155.G323889@wobbly.melbourne.sgi.com> <20010829123042.H8775@atrey.karlin.mff.cuni.cz> In-Reply-To: <20010829123042.H8775@atrey.karlin.mff.cuni.cz> MIME-Version: 1.0 Message-Id: <20010830031841.BKSU1331.femail16.sdc1.sfba.home.com@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7U3Ifd08263 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I havn't copyed down a oops yet but after the crash I would get an error updating superblock and have to boot off of anouther disk and recover. the recovery goes well and everything works fine afterwords. On Wednesday 29 August 2001 06:30 am, Jan Kara wrote: > Hello, > > > On Tue, Aug 28, 2001 at 06:21:59PM -0400, machack wrote: > > > rc.sysinit cuases the kernel to dump when it hits quotaon. this > > > problem only happens on kernels newer then 2.4.6 on these later > > > kernels I have no problems when I pass devfs=nomount on boot. Am I > > > the only one to have this problem or is it documented. my root partion > > > is xfs. > > > > I'd be interested in seeing a kdb or ksymoops backtrace if you > > can provide one. quotaon at startup is always ignored by XFS - > > enabling quota is a mount time operation for XFS filesystems, so > > this is likely to be a problem in the interaction between the > > quotactl system call (takes a device special file as its second > > argument) with Q_QUOTAON and devfs; and unrelated to XFS. > > > > If you only have XFS filesystems using quota (and no ext2/other > > filesystems using quota), you can safely remove the "quotaon -a" > > from your startup scripts (thats really not a very nice solution > > though...) > > > > Jan, any chance you've come across this one before? I don't > > remember there being anything new/changed in 2.4.6 in the quota > > subsystem, so seems odd that this would suddenly start to fail. > > Hmm.. There were two minor changes in quota code in 2.4.6. > The first one was just that remove_dquot_refs() gets super_block > and not device. The second one was that we allow initialization > of quotas on other inodes, than just symlinks, regular files and > directories. The second one probably causes the problem but I can't > see how... I'll look into it but the trace would be very helpful. > > Honza From owner-linux-xfs@oss.sgi.com Wed Aug 29 22:28:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7U5Smj10239 for linux-xfs-outgoing; Wed, 29 Aug 2001 22:28:48 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7U5Sid10220 for ; Wed, 29 Aug 2001 22:28:44 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA13265; Thu, 30 Aug 2001 07:28:12 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA24941; Thu, 30 Aug 2001 07:28:11 +0200 (CEST) Date: Thu, 30 Aug 2001 07:28:11 +0200 (CEST) From: Seth Mos To: Gary Orser cc: Tad Dolphay , linux-xfs@oss.sgi.com Subject: Re: nfs3 problems w/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 Wed, 29 Aug 2001, Gary Orser wrote: > Tad, > > Hmm, It looks like nfs3 wasn't working. > > I upgraded to 4.5.9, with the 4.5.9-xfs patches > and now nfs3 works ok, however: > (must have been the version of nfs-utils) > > I just copied a large file from the sgi server to this linux box > (512m 1.4g Athlon) and the box got buried. > > Over a 100mb switched line a 3G file took 26 minutes, ok not spectacular. > > Load average was over 7, system cpu % was over 85%. > > The single processor on the origin 2000 (r10000) running nfsd was barely > turning over. > > Terminal response was just barely usable on the linux box. > (e.g. it took 4 min. to get top running in another console window) > > This was an ide drive but still... I think you will need to switch on DMA to get respons back from the box. This is very critical when using IDE drives. In PIO modes your CPU wll have to work harder. > Adding to this a little later on... > I did a little further stress testing > > dd if=/dev/zero of=./test bs=1M count=3000 > xfs=23 mins > ext2=22 mins > eliminating nfs and xfs > same buried processor. It must be a kernel thing. > > kswapd and kupdated were the big cpu hogs, although > there was never any swap used. Sounds like your isn't using DMA. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Aug 29 22:53:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7U5ros10750 for linux-xfs-outgoing; Wed, 29 Aug 2001 22:53:50 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7U5rjd10730 for ; Wed, 29 Aug 2001 22:53:46 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id HAA09604; Thu, 30 Aug 2001 07:53:24 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id HAA10686; Thu, 30 Aug 2001 07:53:23 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 8C92257306; Thu, 30 Aug 2001 07:53:08 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 53B3F25835; Thu, 30 Aug 2001 07:53:08 +0200 (CEST) Message-ID: <3B8DD4C4.881314AE@ch.sauter-bc.com> Date: Thu, 30 Aug 2001 07:53:08 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs Subject: Re: oops after rsync on XFS References: <3B8CA162.353AFFCE@ch.sauter-bc.com> <3B8CEA82.38A5FE74@sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > Simon Matter wrote: > > > > Hello, > > > > I was just syncing some files yesterday from my laptop the the server > > (Stock RH-7.1-XFS-1.0.1 with kernel 2.4.3-SGI_XFS_1.0.1) like everyday. > > But the server crashed and dropped into kdb. > > Did kdb provide any useful information? Can you do a backtrace (bt) and > see where things were going when it crashed? (Un)fortunately I was not able to reproduce the crash. Simon > > -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 Aug 29 23:45:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7U6jtt11621 for linux-xfs-outgoing; Wed, 29 Aug 2001 23:45:55 -0700 Received: from oss.sgi.com ([211.219.153.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7U6jXd11590 for ; Wed, 29 Aug 2001 23:45:33 -0700 Message-Id: <200108300645.f7U6jXd11590@oss.sgi.com> From: To: Subject: [±€°íÁŠÈÞ] ±¹³» ÃÖŽë ŒºÀιæŒÛ±¹ œßŒî¿¡Œ­ ÇÑ°¡Áö ÁŠŸÈÀ» µåž³ŽÏŽÙ. Date: Thu, 30 Aug 2001 14:43:42 +0900 MIME-Version: 1.0 X-Mailer: INFOMailer Ver 2.5 Reply-To: join@sshow.co.kr Content-Type: text/html; charset=euc-kr Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk mail


 
     


ŸÈ³çÇÏŒŒ¿ä. ±¹³» ÃÖ°íÀÇ ŒºÀιæŒÛ±¹ œßŒî ¿Â¶óÀÎ ÁŠÈÞ ŽãŽçÀÚ ÀÔŽÏŽÙ.

œßŒîŽÂ ±Í»çÀÇ »çÀÌÆ®žŠ ÅëÇÑ ¿Â¶óÀÎ ±€°í Win-Win ÇÁ·ÎÁ§Æ®žŠ ÁøÇàÇÏ°í œÍœÀŽÏŽÙ.

±Í»çÀÇ »çÀÌÆ®¿¡Œ­ ±¹³» ÃÖ°íÀÇ ŒºÀιæŒÛ±¹ œßŒîÀÇ º£³ÊžŠ ¿¬°áÇØ ÁÖœÃ°í º£³ÊžŠ ÅëÇØ ŸòŸî

ÁöŽÂ ŒöÀÍÀÇ 30%žŠ µåž®°ÚœÀŽÏŽÙ. ¶ÇÇÑ žÅÃâ »óœÂ¿¡ µûž¥ ºŒ·ý Ä¿¹ÌŒÇµµ ÀÖœÀŽÏŽÙ.

Á€È®ÇÑ ŒöÀͱÝÀ» žÅÀÏžÅÀÏ œÇœÃ°£Àž·Î Á÷Á¢ È®ÀÎÇÏœÇ Œö ÀÖµµ·Ï ÁŠÀÛÀÌ µÇŸî ÀÖœÀŽÏŽÙ.

±Í»çÀÇ »çÀÌÆ®¿¡Œ­ œßŒî º£³ÊžŠ Ŭž¯ÇÑ Èž¿øÀÌ 30ÀÏ°£ÀÇ Å¬ž¯ À¯È¿±â°£À» Œ³Á€ÇØ µÎ°í

ÀÖœÀŽÏŽÙ. Áï œßŒî º£³ÊžŠ Ŭž¯ÇÏžé 30ÀÏ µ¿ŸÈÀº ±Í»çÀÇ ŒöÀÍÀž·Î ÁøÇàµËŽÏŽÙ.

¡Ø Çѹø »çÀÌÆ®žŠ µÑ·¯ºžœÃ°í ±ÍÇÏÀÇ ÇöžíÇÑ ÆÇŽÜÀ» ºÎŹµåž³ŽÏŽÙ.

[ ¿Â¶óÀÎ ÁŠÈÞ»ç °¡ÀÔ ]

 

œßŒî±€°í ÁøÇàÀýÂ÷


ÁŠÈÞœÅû ÆÄÆ®³Ê ÀÚµ¿µî·Ï ¹è³ÊŽÞ±â




 ±€°íÄ¿¹ÌŒÇ Áö±ÞŸÈ³»

œßŒî ¿ùº° °¡ÀÔ±ÝŸ× ¹× ¿ùº° ŒöÀÍ±Ý ³»¿ª

œßŒî °¡ÀÔ°³¿ù œßŒî °¡ÀÔ±ÝŸ× 30% Ä¿¹ÌŒÇ 33% Ä¿¹ÌŒÇ 35% Ä¿¹ÌŒÇ
    700žž¿ø ÀÌÇÏ 700žž¿ø ÀÌ»ó 1500žž¿ø ÀÌ»ó
1 °³¿ù 13,200¿ø 3,960¿ø 4,356¿ø 4,620¿ø
2 °³¿ù 22,000¿ø 6,600¿ø 7,260¿ø 7,700¿ø
3 °³¿ù 33,000¿ø 9,900¿ø 10,890¿ø 11,550¿ø
6 °³¿ù 66,000¿ø 19,800¿ø 21,780¿ø 23,100¿ø
12°³¿ù 110,000¿ø 33,000¿ø 36,300¿ø 38,500¿ø

¡Ø žÅ¿ù ÆÄÆ®³Ê Èž¿øÀÇ žÅÃâ¿¡ µûž¥ Ä¿¹ÌŒÇ Â÷µî Áö±ÞÀ» ÇÏ°í ÀÖœÀŽÏŽÙ. ÂüÁ¶ ¹Ù¶øŽÏŽÙ.



°í Ç°°ÝÀ» ÀÚ¶ûÇÏŽÂ œßŒî

±¹³» ŒºÀιæŒÛ±¹ Áß ÃÖ°íÀÇ ±âŒúÁø°ú œºÅǵéÀÌ œßŒîžŠ ÀÌ·ž°Ô žžµé°í ÀÖœÀŽÏŽÙ.

 ¹ÌžðÀÇ IJ¿Í ÇÔ²² žÅÀϹ㠜ß~¶óÀ̺ê·Î Áñ±âŽÂ ŒºÀιæŒÛ±¹ÀÔŽÏŽÙ.

 

ŒºÀιæŒÛ »çÀÌÆ®¶ó°í ±€°íÁøÇàÀ» ¹Ì·çœÊŽÏ±î?
ÀÎÅͳÝÀ̶õ ÁÁÀº žÅÃŒÀÔŽÏŽÙ. ÇÏÁöžž ÀüŒŒ°èÀÇ ³×ÆŒÁðµéÀÌŒºÀÎ °ü·Ã ÄÁÅÙÃ÷žŠ
ãŸÆ ŽÙŽÏŽÂ ÇÏ·ç œÃ°£Àº Ÿóž¶³ª µÉ±î¿ä?
ŽëºÎºÐÀÇ ³×ÆŒÁðÀº ŒºÀλçÀÌÆ®ÀÇ URLÀ» žÓž®¿¡ ±âŸïÇÏÁö ŸÊœÀŽÏŽÙ.
 È®œÇÇÑ ŒºÀιæŒÛÀ» À̲øŸî °¡ŽÂ œßŒî¿Í ÇÔ²² ÇÏœÃžé ž¹Àº ±€°íŒöÀÍÀ» ¿Ãž®œÇ Œö ÀÖœÀŽÏŽÙ.
Âü°í·Î œßŒîŽÂ ÀÎÅÍ³Ý ŒºÀιæŒÛ ÇùÈž¿¡ µî·ÏÀ» ÇÏ°í œÉÀÇ ¹× ±¹³» Çã°¡ ŒöÁØ¿¡Œ­ ¿­œÉÈ÷
ÇÏ°í ÀÖœÀŽÏŽÙ. œßŒîÀÇ ÆÄÆ®³Êµé Áß °³ÀÎÀÌ ¿î¿µÇÏŽÂ ž¹Àº »çÀÌÆ®¿¡Œ­µµ žÅ¿ù ³ôÀº ±€°í
ÁýÇàºñ¿ëÀ» ¹ÞŸÆ°¡°í ÀÖœÀŽÏŽÙ.
œßŒîÀÇ CPS±€°í°¡ ±Í»çÀÇ ¿î¿µ¿¡ ž¹Àº µµ¿òÀÌ µÇŸúÀžžé ÇÕŽÏŽÙ.
±€°íÁŠŸÈ žÞÀÏÀ» ¹Þ°í œÍÁö ŸÊÀžœÅ ºÐÀº "žÞÀÏ ŒöœÅ°ÅºÎ" ¹öÆ°À» Ŭž¯ÇØ ÁÖŒŒ¿ä.

[ žÞÀÏŒöœÅ°ÅºÎ ] [ °èŸàŒ­ ŽÙ¿î¹Þ±â ]

œßŒîŽÂ œÅ¿ëÀ» ŒÒÁßÈ÷ ¿©±éŽÏŽÙ. œÅ¿ë°ú ºê·£µåÆÄ¿ö°¡ ÀÖŽÂ œßŒî¿Í ±€°íÁŠÈÞžŠ žÎÀžŒŒ¿ä.
ºžŽÙ ÀÚŒŒÇÑ ¹®ÀÇ »çÇ×ÀºJoin@sshow.co.kr
Copyright 2001šÏ Dream Contents Corp, All rights reserved.
From owner-linux-xfs@oss.sgi.com Thu Aug 30 00:12:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7U7CFx12217 for linux-xfs-outgoing; Thu, 30 Aug 2001 00:12:15 -0700 Received: from sgisrv1.teleworld.at (mail.teleworld.at [212.152.248.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7U7CBd12197 for ; Thu, 30 Aug 2001 00:12:11 -0700 Received: from teleworld.at (twagw [10.53.77.20]) by sgisrv1.teleworld.at (8.9.3/8.9.3) with ESMTP id JAA15070; Thu, 30 Aug 2001 09:10:20 +0200 (CEST) Message-ID: <3B8DE727.5F82911E@teleworld.at> Date: Thu, 30 Aug 2001 09:11:35 +0200 From: Gerald Weber Reply-To: gerald.weber@teleworld.at X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: oops with 2.4.9-xfs References: <3B8B50A6.D0D11A3A@teleworld.at> <3B8BA3A6.14B75B08@sgi.com> <3B8BA7FB.2D1E8568@teleworld.at> <3B8BAC24.1A825217@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk i tried to reproduce this several times running tar directly on the console...tar completes without any errors. i think it has something to do with xfs+nfs3... Eric Sandeen wrote: > > Gerald Weber wrote: > > > > hi, > > > > KDB...type bt... > > thats the prob,i can't type anything on the keyboard..screen stays dark.. > > If the machine is in X, or if the console has blanked, this will be the > case... if you start your tar command from a text console, do you see > the kdb prompt when it hangs? > > -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 Aug 30 04:11:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UBBZH17727 for linux-xfs-outgoing; Thu, 30 Aug 2001 04:11:35 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UBBWd17704 for ; Thu, 30 Aug 2001 04:11:32 -0700 Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) 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 EAA09796 for ; Thu, 30 Aug 2001 04:11:29 -0700 (PDT) mail_from (keith_m@sweeney.demon.co.uk) Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15cPeQ-00042g-0Y for linux-xfs@oss.sgi.com; Thu, 30 Aug 2001 12:06:23 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 70D3327EF for ; Thu, 30 Aug 2001 12:05:58 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id 20C61125E6; Thu, 30 Aug 2001 12:05:58 +0100 (BST) Date: Thu, 30 Aug 2001 12:05:58 +0100 (BST) From: Keith Matthews Subject: OT - HTML posts was Re[2]: kdb not compile To: linux-xfs@oss.sgi.com In-Reply-To: <29971.999129138@kao2.melbourne.sgi.com> References: <29971.999129138@kao2.melbourne.sgi.com> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010830110558.20C61125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f7UBBWd17705 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 30 Aug 2001 09:52:18 +1000 Keith Owens > wrote: > Please do not send mail to this list using MIME. Your mail had both > text and HTML and the text was base64 encoded. Use just plain text. > On Wed, 29 Aug 2001 15:01:17 +0800, > "Du Jun" wrote: > >i386-dis.c: In function `print_insn_i386': > >i386-dis.c:2143: `bfd_mach_i386_i386_intel_syntax' undeclared (first use in this function) > Upgrade your binutils. kdb needs at least binutils-2.9.5.0.22. Steve, when you get back to your desk would you consider prevailing on the list administrators to set uo a reject for posts containing HTML? -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Thu Aug 30 08:38:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UFcTP22566 for linux-xfs-outgoing; Thu, 30 Aug 2001 08:38:29 -0700 Received: from finn.cns.montana.edu (finn.cns.montana.edu [153.90.178.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UFcOd22540 for ; Thu, 30 Aug 2001 08:38:24 -0700 Received: from case.cns.montana.edu (case.cns.montana.edu [153.90.178.21]) by finn.cns.montana.edu (8.9.3/8.9.3) with ESMTP id JAA25336; Thu, 30 Aug 2001 09:36:37 -0600 (MDT) Date: Thu, 30 Aug 2001 09:36:36 -0600 From: Gary Orser To: Seth Mos cc: Tad Dolphay , linux-xfs@oss.sgi.com Subject: Re: nfs3 problems w/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 Seth, HeeHaw, that's it. Thanks much! hdparm -d1 -X23 /dev/hda Same dd test to xfs was 3 min instead of 22! System cpu% single figures, response normal. The over the wire test went from 26 min to 5, achieving about 70mb through put. Cheers, Gary ------------------------------------------------------ Gary Orser , (406) 994-6451, orser@nervana.montana.edu Montana State University Center for Computational Biology 1 Lewis Hall, Bozeman MT, 59717 On Thu, 30 Aug 2001, Seth Mos wrote: > On Wed, 29 Aug 2001, Gary Orser wrote: > > > Tad, > > > > Hmm, It looks like nfs3 wasn't working. > > > > I upgraded to 4.5.9, with the 4.5.9-xfs patches > > and now nfs3 works ok, however: > > (must have been the version of nfs-utils) > > > > I just copied a large file from the sgi server to this linux box > > (512m 1.4g Athlon) and the box got buried. > > > > Over a 100mb switched line a 3G file took 26 minutes, ok not spectacular. > > > > Load average was over 7, system cpu % was over 85%. > > > > The single processor on the origin 2000 (r10000) running nfsd was barely > > turning over. > > > > Terminal response was just barely usable on the linux box. > > (e.g. it took 4 min. to get top running in another console window) > > > > This was an ide drive but still... > > I think you will need to switch on DMA to get respons back from the box. > This is very critical when using IDE drives. In PIO modes your CPU wll > have to work harder. > > > Adding to this a little later on... > > I did a little further stress testing > > > > dd if=/dev/zero of=./test bs=1M count=3000 > > xfs=23 mins > > ext2=22 mins > > eliminating nfs and xfs > > same buried processor. It must be a kernel thing. > > > > kswapd and kupdated were the big cpu hogs, although > > there was never any swap used. > > Sounds like your isn't using DMA. > > Cheers > Seth > From owner-linux-xfs@oss.sgi.com Thu Aug 30 09:49:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UGndh23776 for linux-xfs-outgoing; Thu, 30 Aug 2001 09:49:39 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UGnUd23744 for ; Thu, 30 Aug 2001 09:49:31 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15cV0J-0006u1-00 for linux-xfs@oss.sgi.com; Thu, 30 Aug 2001 18:49:19 +0200 Message-ID: <3B8E6E8E.D2082F15@it.up.ac.za> Date: Thu, 30 Aug 2001 18:49:18 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: XFS mailing list Subject: Kernel hangs with mongo.pl benchmark. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15cV0J-0006u1-00*1blZfbaaEAo* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I found a problem while doing benchmarks with mongo.pl The sympthom is that the machine just hangs. No error messages. I ran "vmstat 1" in a window while doing the benchmark. I noticed that the "bo" becomes 0 for a while before it completely locks up. I can force an immediate lockup by doing a "sync". I also noticed (by doing 'watch df -k') in another term that the used space increased as the files are created. The used space then starts decreasing. At this point you can start walking to the server room ... When running reiserfs on the partitions, it went through without a problem. (I would have been amused if their own benchmark failed) With ext2 I got "Out of disk space" errors. Ext2 actually ran out of inodes on this test and not space. With that in mind I played with the various inode options in mkfs.xfs. I tried maxpct=0 and then maxpct=90 in combinations with size=2048. None of these resolved the problem. I ran the test on 4 different machines with the same result on 3 of the machines. I use debian 2.2r3 (stable) on all the machines. I compiled the kernels with egcs-1.1.2 which I installed spesificly for compiling kernels. I also tried kernels compiled with gcc 2.95.4 and gcc version 3.0.2 20010825 (Debian prerelease) I tried kernels 2.4.7,2.4.8-pre4,2.4.8,2.4.9,2.4.10-pre1,2.4.10-pre2 all with the same result. All these kernels are from the CVS tree. The machine that ran successfully was my home PC. Celeron 300A (run at 100MHz FSB thus 450MHz) 128M ram, 30G seagate baracuda IDE hard drive. Kernel 2.4.8 build with egcs-1.1.2. The machines that does'nt work: Dell PowerEdge 4400 1GHz Xeon,1G RAM, Seagate Cheetha 15k RPM on PERC 3/Di controller no RAID settings. Dell 1400C PIII 866MHz,128M RAM, 2x9G Fujitsu 10k RPM drives on Adaptec controller. Custom build 2x500MHz PIII, 768M RAM, 9G Seagate Cheetha on DPT 3755 controller no RAID settings. I tried to pin point the problem, but without success. Unfortunetly I can't get kdb to compile. It fails with error: /home/paul/test/linux-2.4-xfs/linux/include/linux/dis-asm.h:148: storage size of `display_endian' isn't known make[3]: *** [kdb_bt.o] Error 1 I think you will be able to reproduce the hanging problem. I ran ./mongo.pl xfs /dev/sdc1 /testfs xfs 6 from the mongo benchmark suite found at www.reiserfs.com When I do ./mongo.pl xfs /dev/sdc1 /testfs xfs 1 (single process), it works fine. I added a definition to mongo.pl for xfs: if ( $FILESYSTEM eq "xfs" ) { system("mkfs.xfs -f -l size=8192b $DEVICE") ; system("mount -t xfs -o logbufs=8 $DEVICE $TESTDIR") ; } Paul Schutte From owner-linux-xfs@oss.sgi.com Thu Aug 30 10:05:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UH5H624244 for linux-xfs-outgoing; Thu, 30 Aug 2001 10:05:17 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UH5Ad24224 for ; Thu, 30 Aug 2001 10:05:10 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id TAA10709; Thu, 30 Aug 2001 19:04:29 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA17008; Thu, 30 Aug 2001 19:04:29 +0200 (CEST) Date: Thu, 30 Aug 2001 19:04:29 +0200 (CEST) From: Seth Mos To: Paul Schutte cc: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. In-Reply-To: <3B8E6E8E.D2082F15@it.up.ac.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 30 Aug 2001, Paul Schutte wrote: > Hi, > > I found a problem while doing benchmarks with mongo.pl > > The sympthom is that the machine just hangs. No error messages. > > I ran "vmstat 1" in a window while doing the benchmark. I noticed that > the "bo" becomes 0 for a while before it > completely locks up. I can force an immediate lockup by doing a "sync". > > I also noticed (by doing 'watch df -k') in another term that the used > space increased as the files are created. > The used space then starts decreasing. At this point you can start > walking to the server room ... > > When running reiserfs on the partitions, it went through without a > problem. > (I would have been amused if their own benchmark failed) > > With ext2 I got "Out of disk space" errors. Ext2 actually ran out of > inodes on this test and not space. > > With that in mind I played with the various inode options in mkfs.xfs. > I tried maxpct=0 and then maxpct=90 in combinations with size=2048. > None of these resolved the problem. > > I ran the test on 4 different machines with the same result on 3 of the > machines. > > I use debian 2.2r3 (stable) on all the machines. > > I compiled the kernels with egcs-1.1.2 which I installed spesificly for > compiling kernels. > I also tried kernels compiled with gcc 2.95.4 and gcc version 3.0.2 > 20010825 (Debian prerelease) > I tried kernels 2.4.7,2.4.8-pre4,2.4.8,2.4.9,2.4.10-pre1,2.4.10-pre2 all > with the same result. > All these kernels are from the CVS tree. > > The machine that ran successfully was my home PC. > Celeron 300A (run at 100MHz FSB thus 450MHz) 128M ram, 30G seagate > baracuda IDE hard drive. > Kernel 2.4.8 build with egcs-1.1.2. > > The machines that does'nt work: > Dell PowerEdge 4400 1GHz Xeon,1G RAM, Seagate Cheetha 15k RPM on PERC > 3/Di controller no RAID settings. You mean scsi mode? Or a JBOD config. Did you need to use the patch for this raid controller. > Dell 1400C PIII 866MHz,128M RAM, 2x9G Fujitsu 10k RPM drives on > Adaptec controller. > Custom build 2x500MHz PIII, 768M RAM, 9G Seagate Cheetha on DPT 3755 > controller no RAID settings. The common factor seems to be adaptec hardware ;-) > I tried to pin point the problem, but without success. > > Unfortunetly I can't get kdb to compile. > It fails with error: > > /home/paul/test/linux-2.4-xfs/linux/include/linux/dis-asm.h:148: storage > size of `display_endian' isn't known > make[3]: *** [kdb_bt.o] Error 1 > > I think you will be able to reproduce the hanging problem. > > I ran ./mongo.pl xfs /dev/sdc1 /testfs xfs 6 from the mongo benchmark > suite found at www.reiserfs.com > > When I do ./mongo.pl xfs /dev/sdc1 /testfs xfs 1 (single process), it > works fine. > > I added a definition to mongo.pl for xfs: > > if ( $FILESYSTEM eq "xfs" ) { > system("mkfs.xfs -f -l size=8192b $DEVICE") ; > system("mount -t xfs -o logbufs=8 $DEVICE $TESTDIR") ; > } Have you tried using less logbufs, I can imagine that during deletion (which is slow) the buffering might become problematic. Can you try it with less buffering like 2(default) or 4? Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Aug 30 10:25:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UHPfA24596 for linux-xfs-outgoing; Thu, 30 Aug 2001 10:25:41 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UHPVd24577 for ; Thu, 30 Aug 2001 10:25:32 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15cVZC-0007cl-00 for linux-xfs@oss.sgi.com; Thu, 30 Aug 2001 19:25:22 +0200 Message-ID: <3B8E7702.4629F2EA@it.up.ac.za> Date: Thu, 30 Aug 2001 19:25:22 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: XFS mailing list Subject: [Fwd: Re: Kernel hangs with mongo.pl benchmark.] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15cVZC-0007cl-00*XfulV1BIy5o* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > On Thu, 30 Aug 2001, Paul Schutte wrote: > > > Hi, > > > > I found a problem while doing benchmarks with mongo.pl > > > > The sympthom is that the machine just hangs. No error messages. > > > > I ran "vmstat 1" in a window while doing the benchmark. I noticed that > > the "bo" becomes 0 for a while before it > > completely locks up. I can force an immediate lockup by doing a "sync". > > > > I also noticed (by doing 'watch df -k') in another term that the used > > space increased as the files are created. > > The used space then starts decreasing. At this point you can start > > walking to the server room ... > > > > When running reiserfs on the partitions, it went through without a > > problem. > > (I would have been amused if their own benchmark failed) > > > > With ext2 I got "Out of disk space" errors. Ext2 actually ran out of > > inodes on this test and not space. > > > > With that in mind I played with the various inode options in mkfs.xfs. > > I tried maxpct=0 and then maxpct=90 in combinations with size=2048. > > None of these resolved the problem. > > > > I ran the test on 4 different machines with the same result on 3 of the > > machines. > > > > I use debian 2.2r3 (stable) on all the machines. > > > > I compiled the kernels with egcs-1.1.2 which I installed spesificly for > > compiling kernels. > > I also tried kernels compiled with gcc 2.95.4 and gcc version 3.0.2 > > 20010825 (Debian prerelease) > > I tried kernels 2.4.7,2.4.8-pre4,2.4.8,2.4.9,2.4.10-pre1,2.4.10-pre2 all > > with the same result. > > All these kernels are from the CVS tree. > > > > The machine that ran successfully was my home PC. > > Celeron 300A (run at 100MHz FSB thus 450MHz) 128M ram, 30G seagate > > baracuda IDE hard drive. > > Kernel 2.4.8 build with egcs-1.1.2. > > > > The machines that does'nt work: > > Dell PowerEdge 4400 1GHz Xeon,1G RAM, Seagate Cheetha 15k RPM on PERC > > 3/Di controller no RAID settings. > > You mean scsi mode? Or a JBOD config. Did you need to use the patch for > this raid controller. > I did aplied the AACRAID patch. I don't use the onboard adaptec controller. No patch = no drives. > > > Dell 1400C PIII 866MHz,128M RAM, 2x9G Fujitsu 10k RPM drives on > > Adaptec controller. > > Custom build 2x500MHz PIII, 768M RAM, 9G Seagate Cheetha on DPT 3755 > > controller no RAID settings. > > The common factor seems to be adaptec hardware ;-) > > > I tried to pin point the problem, but without success. > > > > Unfortunetly I can't get kdb to compile. > > It fails with error: > > > > /home/paul/test/linux-2.4-xfs/linux/include/linux/dis-asm.h:148: storage > > size of `display_endian' isn't known > > make[3]: *** [kdb_bt.o] Error 1 > > > > I think you will be able to reproduce the hanging problem. > > > > I ran ./mongo.pl xfs /dev/sdc1 /testfs xfs 6 from the mongo benchmark > > suite found at www.reiserfs.com > > > > When I do ./mongo.pl xfs /dev/sdc1 /testfs xfs 1 (single process), it > > works fine. > > > > I added a definition to mongo.pl for xfs: > > > > if ( $FILESYSTEM eq "xfs" ) { > > system("mkfs.xfs -f -l size=8192b $DEVICE") ; > > system("mount -t xfs -o logbufs=8 $DEVICE $TESTDIR") ; > > } > > Have you tried using less logbufs, I can imagine that during deletion > (which is slow) the buffering might become problematic. > It is still in the creation phase. No deletes. I asume the decreasing in size is because there are some packing activity going on. The files are of 100 bytes avarage size. > > Can you try it with less buffering like 2(default) or 4? > I repeated the test on the 4400 with logbufs=2. It still gave up. > > Cheers > Seth Paul From owner-linux-xfs@oss.sgi.com Thu Aug 30 10:38:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UHcFN24898 for linux-xfs-outgoing; Thu, 30 Aug 2001 10:38:15 -0700 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 f7UHcCd24879 for ; Thu, 30 Aug 2001 10:38:12 -0700 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 f7UHipa02657 for ; Thu, 30 Aug 2001 10:44:51 -0700 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 MAA2839601; Thu, 30 Aug 2001 12:36:51 -0500 (CDT) Received: from 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 MAA63951; Thu, 30 Aug 2001 12:36:50 -0500 (CDT) Message-ID: <3B8E7981.B8124897@sgi.com> Date: Thu, 30 Aug 2001 12:36:01 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Schutte CC: XFS mailing list Subject: Re: [Fwd: Re: Kernel hangs with mongo.pl benchmark.] References: <3B8E7702.4629F2EA@it.up.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Paul Schutte wrote: > It is still in the creation phase. No deletes. I asume the decreasing in > size > is because there are some > packing activity going on. The files are of 100 bytes avarage size. The decreasing size is probably pre-allocated space being made available... I'll try the benchmark over here (I also have adaptec hardware, FWIW) and see what I can see... -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 Aug 30 10:41:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UHfZA25040 for linux-xfs-outgoing; Thu, 30 Aug 2001 10:41:35 -0700 Received: from wiley.ceo.com (66-2-81-28.customer.algx.net [66.2.81.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UHfUd25021 for ; Thu, 30 Aug 2001 10:41:30 -0700 Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1]) by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id OAA12336 for ; Thu, 30 Aug 2001 14:02:37 -0400 Message-ID: <3B8E7FBC.99ABB5A3@mindspring.com> Date: Thu, 30 Aug 2001 14:02:36 -0400 From: Danny Cox Reply-To: DCox@SnapServer.com Organization: Snap X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS Subject: Small Patch, Probably Aesthetic Only Content-Type: multipart/mixed; boundary="------------F89A908322C5E8B0070A9C40" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------F89A908322C5E8B0070A9C40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, My compiler was giving me the following warning: xfs_fsops.c: In function `xfs_fs_log_dummy': xfs_fsops.c:526: warning: suggest parentheses around assignment used as truth value in looking at the function, I determined that 'int error' is no longer used, so this patch removes it, and thus, the compile warning also. Since this seems to be in the chain of a fs shutdown or unmount, it's not used that often, so the only reason to apply it is to shut gcc up ;-). Patch attached. -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill Danny --------------F89A908322C5E8B0070A9C40 Content-Type: text/plain; charset=us-ascii; name="small_patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="small_patch" --- fs/xfs/xfs_fsops.c.orig Thu Aug 30 13:45:45 2001 +++ fs/xfs/xfs_fsops.c Thu Aug 30 13:46:25 2001 @@ -516,14 +516,11 @@ { xfs_trans_t *tp; xfs_inode_t *ip; - int error; tp = _xfs_trans_alloc(mp, XFS_TRANS_DUMMY1); atomic_inc(&mp->m_active_trans); - if (error = xfs_trans_reserve(tp, 0, - XFS_ICHANGE_LOG_RES(mp), - 0, 0, 0)) { + if (xfs_trans_reserve(tp, 0, XFS_ICHANGE_LOG_RES(mp), 0, 0, 0)) { xfs_trans_cancel(tp, 0); return; } @@ -534,7 +531,7 @@ xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); xfs_trans_ihold(tp, ip); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - error = xfs_trans_commit(tp, XFS_TRANS_SYNC, NULL); + xfs_trans_commit(tp, XFS_TRANS_SYNC, NULL); xfs_iunlock(ip, XFS_ILOCK_EXCL); } --------------F89A908322C5E8B0070A9C40-- From owner-linux-xfs@oss.sgi.com Thu Aug 30 11:53:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UIrjD26460 for linux-xfs-outgoing; Thu, 30 Aug 2001 11:53:45 -0700 Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UIred26441 for ; Thu, 30 Aug 2001 11:53:41 -0700 Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id UAA27929 for ; Thu, 30 Aug 2001 20:53:36 +0200 (MEST) Message-ID: <3B8E8BCB.5060709@dumballah.tvnet.hu> Date: Thu, 30 Aug 2001 20:54:03 +0200 From: Sipos Ferenc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: gcc 3.01 compilatoin problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I know, that the current kernel is not for gcc 3.01, but my compiler complains about the xfs code. The message is the following: gcc ... xfs_super.c {standard input}:Assembler messages: {standard input}:1116: Error: suffix or operands invalid for 'bsf' the kernel has compiled with gcc 3.0, but the current version, which is gcc 3.01 08.30. netwinder rpm not. I'd like to use gcc 3.01 because of better athlon optimisations, so please help me. By the way, I have tried with the newest binutils, which is 2.11.90 and with the 2.9 series. I don't think it's a gcc issue, because gcc 3.01 has fewer bugs than gcc 3.0, as the tests show. thx Paco From owner-linux-xfs@oss.sgi.com Thu Aug 30 11:54:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UIsYF26582 for linux-xfs-outgoing; Thu, 30 Aug 2001 11:54:34 -0700 Received: from smtp1.home.se (smtp1.home.se [195.66.35.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UIsWd26562 for ; Thu, 30 Aug 2001 11:54:32 -0700 Received: from home.se [217.215.31.238] by smtp1.home.se with Novonyx SMTP Server $Revision: 2.74 $; Thu, 30 Aug 2001 20:50:39 +0200 (ECTD) Message-ID: <3B8E8B5E.3070706@home.se> Date: Thu, 30 Aug 2001 20:52:14 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Kernel hangs with mongo.pl benchmark. References: <3B8E6E8E.D2082F15@it.up.ac.za> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. > I compiled the kernels with egcs-1.1.2 which I installed spesificly for > compiling kernels. > I also tried kernels compiled with gcc 2.95.4 and gcc version 3.0.2 > 20010825 (Debian prerelease) > I tried kernels 2.4.7,2.4.8-pre4,2.4.8,2.4.9,2.4.10-pre1,2.4.10-pre2 all Umm. Just a question. That must be a CVS based gcc, cause 3.0.1 is latest out. 3.0.2 is due out in october. Am I correct? // Stefan From owner-linux-xfs@oss.sgi.com Thu Aug 30 12:00:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UJ0AO26820 for linux-xfs-outgoing; Thu, 30 Aug 2001 12:00:10 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UIxsd26762 for ; Thu, 30 Aug 2001 11:59:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA09262 for ; Thu, 30 Aug 2001 11:59:35 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2854964; Thu, 30 Aug 2001 13:58:11 -0500 (CDT) Received: from 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 NAA42305; Thu, 30 Aug 2001 13:58:10 -0500 (CDT) Message-ID: <3B8E8C91.F6F8D6D0@sgi.com> Date: Thu, 30 Aug 2001 13:57:21 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: DCox@SnapServer.com CC: Linux-XFS Subject: Re: Small Patch, Probably Aesthetic Only References: <3B8E7FBC.99ABB5A3@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Danny Cox wrote: > Patch attached. Thanks, I'll put it in. -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 Aug 30 12:07:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UJ7ZF27035 for linux-xfs-outgoing; Thu, 30 Aug 2001 12:07:35 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UJ7Td27015 for ; Thu, 30 Aug 2001 12:07:30 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id EDBF3C001F3; Fri, 31 Aug 2001 03:07:26 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 8F5FEC001F2; Fri, 31 Aug 2001 03:07:25 +0800 (PHT) Date: Fri, 31 Aug 2001 03:07:25 +0800 (PHT) From: Federico Sevilla III To: "Philippine Linux Users' Group Mailing List" , Linux XFS Mailing List Subject: Playing around with NFS+XFS 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 everyone, By popular demand of some fellow members in the Philippine Linux Users' Group (PLUG), I decided to show up at work at midnight when everyone else was away, to mess around with the server's hard drives. The objective: stress-test NFS+XFS and show the world it's more than ready for primetime. ;> I'm using XFS (of course) with Linux kernel 2.4.9, with NFSv3 on both the client and server. I have four IBM hard drives (yes, the dreaded IBM GXPs) hosted by a 3ware Escalade 6400 in hardware RAID5. I ran two tests. The first test was to see if I could transfer a 4GB file. I created a concatenated tarball that has a size 4891125760 bytes, which when I divide by 1024 thrice is about 4.56GB. I didn't exactly "transfer" it, though. On the client side I mounted the NFS exported volume, then did a "cat foo.tar > /dev/null". I think it did well to test the server's hard drives, NFS for reading, and the wire speed. I initially did a plain-old-copy, but the client's hard drive was limiting things and I wanted to push everything I could push on the server's side. Comments on my methodology as far as this is concerned are welcome. The second test was aimed at over-all stressing, using bonnie++. I ran bonnie++ with the following parameters: # bonnie++ -d /opt/test/bonnie++ -s 1G -n 5:1M:1M:256 -u root The mount options for NFS are "rsize=8192,wsize=8192". I think I can push things further by bumping this up to 32768 since I'm using NFSv3, but maybe I should sleep first. ;> Anyway here are the results: Version 1.01d ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP Gusi-NFS-XFS 1G 4200 82 5937 7 1988 4 4037 76 10512 9 120.3 1 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP Gusi-NFS-XFS 5:1:0 80 2 252 5 56 1 118 4 341 7 41 0 A more readable copy is in . I'm a definite newbie when it comes to this benchmarking business. I prefer to read everybody else's statistics. Maybe someone has some other decent stress tests to recommend? --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 30 12:48:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UJmD628200 for linux-xfs-outgoing; Thu, 30 Aug 2001 12:48:13 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UJm6d28177 for ; Thu, 30 Aug 2001 12:48:07 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 434CFC001F4; Fri, 31 Aug 2001 03:48:04 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id CCDBEC001F3; Fri, 31 Aug 2001 03:48:02 +0800 (PHT) Date: Fri, 31 Aug 2001 03:48:02 +0800 (PHT) From: Federico Sevilla III To: "Philippine Linux Users' Group Mailing List" , Linux XFS Mailing List Subject: Re: Playing around with NFS+XFS In-Reply-To: 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 Some follow-up stuff: I ran the sequential write tests using dd as in: # time dd if=/dev/zero of=/opt/test/test.img bs=1M count=3000 with three settings that aren't XFS-related but are NFS-specific. Namely, the wsize and rsize settings of NFSv3. - 8192 - - 32768 - - 65535 - real 8m23.713s 8m0.675s 8m39.662s user 0m0.010s 0m0.020s 0m0.040s sys 0m34.890s 0m35.350s 0m35.480s The differences don't seem to be that significant, but I'm going with 32768 since my system is using pure NFSv3 and not NFSv2. Besides, this is set in the client side so an NFSv2 client can always use 8192 for both rsize and wsize. Anyway, this is off-topic for the XFS list (sorry). An observation about disk activity: Disk activity is pretty continuous, which is good. However there are situations where disk activity will stop but network activity continuous. I presume this is filling up some buffer. Then disk activity will pick up and network activity will stop for awhile. I presume aggressive flushing of buffers is going on. This doesn't look quite like "streaming" to me. I'm not complaining, but just thought I'd relay the tidbit in the hopes of getting some enlightenment. Some notes on my system: o I'm using RAID5, and even if this is hardware RAID, RAID5 writes are not so good. I should have gone RAID10, but it's too late to shift now. o I created the filesystems using "-l size=32768b" in mkfs.xfs o I mount the filesystems using "rw,noatime,nodiratime,logbufs=8,biosize=16,osyncisdsync" :-) "Very happy with NFS+XFS" --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Thu Aug 30 13:24:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UKOWa29373 for linux-xfs-outgoing; Thu, 30 Aug 2001 13:24:32 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UKONd29354 for ; Thu, 30 Aug 2001 13:24:24 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id B38A167040 for ; Thu, 30 Aug 2001 22:24:16 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Problems compiling the xfs kernel MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Thu, 30 Aug 2001 22:24:15 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 30.08.2001 22:24:15, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 30.08.2001 22:24:15, Serialize complete at 30.08.2001 22:24:15, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 30.08.2001 22:24:16, S/MIME Sign complete at 30.08.2001 22:24:16, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 30.08.2001 22:24:17, Serialize complete at 30.08.2001 22:24:17 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z341_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z341_boundary_sign Content-Type: text/plain; charset="us-ascii" Hi, I checked out today the xfs kernel from cvs (cvs -z3 checkout linux-2.4-xfs). When I try to compile the kernel I get some errors........ It seems there are problems compiling ext2 :-| I hope someone can help me! so here are the last lines from 'make bzlilo': make[3]: Entering directory `/usr/src/linux/fs/ext2' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -c -o ialloc.o ialloc.c ialloc.c:308: unterminated macro call ialloc.c:527: warning: preprocessing directive not recognized within macro arg ialloc.c: In function `ext2_new_inode': ialloc.c:308: missing white space after number `16' ialloc.c:308: parse error before `_t16_t16_t16_t16_t16_t16_t16_t16_t16_t16_t16_t16_t' ialloc.c:311: warning: statement with no effect ialloc.c:311: parse error before `)' ialloc.c: In function `ext2_count_free_inodes': ialloc.c:446: undefined or invalid # directive ialloc.c:448: syntax error before `)' make[3]: *** [ialloc.o] Error 1 make[3]: Leaving directory `/usr/src/linux/fs/ext2' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/fs/ext2' make[1]: *** [_subdir_ext2] Error 2 make[1]: Leaving directory `/usr/src/linux/fs' make: *** [_dir_fs] Error 2 cu michael ---------z341_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDgzMDIwMjQxNlowIwYJKoZIhvcNAQkEMRYEFPS9e0G5gQtPW8N1 zoJnauxpgz7wMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGABvY9E5qKtqCbsrH4nZE2kk60di80PfnpMW76mTms/3a2hkj4RvG4 8Mp2JeudWXWhuFa0RxDKWcHIPVIACqydD8ZnJyjgWmPiUGTmRZ+yBwJI6ssa9ryk 6oWHlOfnzlX1vjsiQCtHaEx1vGtIKi/CS4FMNBQx9xipvaKiHtgFyrAAAAAAAAAA AA== ---------z341_boundary_sign-- From owner-linux-xfs@oss.sgi.com Thu Aug 30 13:28:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UKSDr29540 for linux-xfs-outgoing; Thu, 30 Aug 2001 13:28:13 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UKS4d29518 for ; Thu, 30 Aug 2001 13:28:05 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15cYPA-0002Wh-00; Thu, 30 Aug 2001 22:27:12 +0200 Message-ID: <3B8EA1A0.F3EC2326@it.up.ac.za> Date: Thu, 30 Aug 2001 22:27:12 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15cYPA-0002Wh-00*0aP2KzOgNbE* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > On Thu, 30 Aug 2001, Paul Schutte wrote: > > > Seth Mos wrote: > > > On Thu, 30 Aug 2001, Paul Schutte wrote: > > > > 3/Di controller no RAID settings. > > > > > > You mean scsi mode? Or a JBOD config. Did you need to use the patch for > > > this raid controller. > > > > > > > I did aplied the AACRAID patch. I don't use the onboard adaptec controller. > > No patch = no drives. > > If you toggle the mode in the bios to scsi mode it works as a normal scsi > controller. It is detected in this case by the normal adaptec driver. > It is operating in the RAID mode in the BIOS and not the SCSI mode. There is also a 36Gbx4 in a RAID 5 array which I did'nt use for the test. It not mounted at the moment. > > > > Dell 1400C PIII 866MHz,128M RAM, 2x9G Fujitsu 10k RPM drives on > > > > Adaptec controller. > > > > Custom build 2x500MHz PIII, 768M RAM, 9G Seagate Cheetha on DPT 3755 > > > > controller no RAID settings. > > > > Have you tried using less logbufs, I can imagine that during deletion > > > (which is slow) the buffering might become problematic. > > > > > > > It is still in the creation phase. No deletes. I asume the decreasing in size > > is because there are some > > packing activity going on. The files are of 100 bytes avarage size. > > Do you mean packing as in gzip or something similar? XFS uses delayed > allocation which means that it might allocate more space then it would > normally need to reduce fragmentation. So after a slight period XFS will > be returning the overallocated space. > No, there is no compression like gzip or anything. When the files are created the usage shoots up to about 2 Gb. It then starts dropping down to about 900Mb. It is probably the delayed allocation. I see this often on XFS when there's a lot of small files. > > > > Can you try it with less buffering like 2(default) or 4? > > > > > > > I repeated the test on the 4400 with logbufs=2. > > > > It still gave up. > > So that's not it. > > I don't have any excess diskspace (connected) here to test it on. I'll > scavenge my room for a disk to hook up to the machine. > > Cheers > Seth From owner-linux-xfs@oss.sgi.com Thu Aug 30 13:29:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UKTYc29738 for linux-xfs-outgoing; Thu, 30 Aug 2001 13:29:34 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UKTUd29718 for ; Thu, 30 Aug 2001 13:29:31 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15cYRB-0002Yk-00; Thu, 30 Aug 2001 22:29:17 +0200 Message-ID: <3B8EA21E.6EFAE6A0@it.up.ac.za> Date: Thu, 30 Aug 2001 22:29:18 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Smietanowski CC: linux-xfs@oss.sgi.com Subject: Re: Kernel hangs with mongo.pl benchmark. References: <3B8E6E8E.D2082F15@it.up.ac.za> <3B8E8B5E.3070706@home.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15cYRB-0002Yk-00*/G/s6yNcPNY* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. I installed a test machine with debian unstable (sid) and that was what I got. Paul Stefan Smietanowski wrote: > Hi. > > > > > I compiled the kernels with egcs-1.1.2 which I installed spesificly for > > compiling kernels. > > I also tried kernels compiled with gcc 2.95.4 and gcc version 3.0.2 > > 20010825 (Debian prerelease) > > I tried kernels 2.4.7,2.4.8-pre4,2.4.8,2.4.9,2.4.10-pre1,2.4.10-pre2 all > > Umm. Just a question. That must be a CVS based gcc, cause 3.0.1 is > latest out. 3.0.2 is due out in october. Am I correct? > > // Stefan From owner-linux-xfs@oss.sgi.com Thu Aug 30 13:37:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UKb9n29967 for linux-xfs-outgoing; Thu, 30 Aug 2001 13:37:09 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UKb4d29948 for ; Thu, 30 Aug 2001 13:37:04 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA13674; Thu, 30 Aug 2001 22:37:02 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA27896; Thu, 30 Aug 2001 22:37:01 +0200 (CEST) Date: Thu, 30 Aug 2001 22:37:01 +0200 (CEST) From: Seth Mos To: Federico Sevilla III cc: "Philippine Linux Users' Group Mailing List" , Linux XFS Mailing List Subject: Re: Playing around with NFS+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 Fri, 31 Aug 2001, Federico Sevilla III wrote: > Hi everyone, > > The mount options for NFS are "rsize=8192,wsize=8192". I think I can push > things further by bumping this up to 32768 since I'm using NFSv3, but > maybe I should sleep first. ;> I use 16384 for 100Mbit at work which seems to be a decent size vs reponse ratio. > Anyway here are the results: > > Version 1.01d ------Sequential Output------ --Sequential Input- --Random- > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP > Gusi-NFS-XFS 1G 4200 82 5937 7 1988 4 4037 76 10512 9 120.3 1 > ------Sequential Create------ --------Random Create-------- > -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > Gusi-NFS-XFS 5:1:0 80 2 252 5 56 1 118 4 341 7 41 0 > > A more readable copy is in . > > I'm a definite newbie when it comes to this benchmarking business. I > prefer to read everybody else's statistics. Maybe someone has some other > decent stress tests to recommend? I have a few standard bonnie results of linux -> linux tests on my homepage http://iserv.nl/ They are a few entries down and is in the following config. Server was a pIII 450 with 256MB of ram and a 2c905B NIC and a 40GB IDE disk in UDMA33 mode. I used 8 nfsd processes and enlarged the buffer size from 64KB to 256KB. echo 262144 > /proc/sys/net/core/rmem_default echo 262144 > /proc/sys/net/core/rmem_max Client was a Dual PIII 733 with 256MB ram and a Intel eepro100 NIC. The limiting factor was wire speed though. You may note that the speeds I was clocking on this desktop machine with 1 IDE harddisk in UDMA33 mode on a i440BX motherboard are higher then your scores for the server. However it seems Linux and XFS is a fast combo for large databases. We needed to do a dictionary update of our databases (6GB total) and since we have a testmachine (the PIII450 Desktop model from above) and Progress 9 we could simulate the entire process. The production server is a dual PII400 with 512MB of ram and 45GB of disk in raid5 under NCR MP-RAS (SVR4) and Veritas FS. The conversion was done on the sunday when there was nobody in the office and the machine was totally idle. The testmachine was during a workday and about 2 people were busy upsetting the printing system (including me Yay!). The conversion under linux took 35 minutes and the machine was responsive. The conversion under NCR MP-RAS took 6 Hours (!) and the machine was stuttering along :-( My manager urges me to make the migration from the NCR to Linux machine on a faster schedule. No more convincing left to do. The new machine will be much faster then the current desktop machine so he also took this oportunity to take a vacation. Hope you get some more info. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Aug 30 13:50:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UKodv30360 for linux-xfs-outgoing; Thu, 30 Aug 2001 13:50:39 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UKoZd30341 for ; Thu, 30 Aug 2001 13:50:35 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA17147; Thu, 30 Aug 2001 22:50:33 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA29147; Thu, 30 Aug 2001 22:50:33 +0200 (CEST) Date: Thu, 30 Aug 2001 22:50:33 +0200 (CEST) From: Seth Mos To: Paul Schutte cc: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. In-Reply-To: <3B8EA1A0.F3EC2326@it.up.ac.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 30 Aug 2001, Paul Schutte wrote: > Seth Mos wrote: > > On Thu, 30 Aug 2001, Paul Schutte wrote: > > If you toggle the mode in the bios to scsi mode it works as a normal scsi > > controller. It is detected in this case by the normal adaptec driver. > > > > It is operating in the RAID mode in the BIOS and not the SCSI mode. > There is also a 36Gbx4 in a RAID 5 array which I did'nt use for the test. It not > mounted at the moment. You have the latest driver I assume? Their performance was good but we decided to switch them for the AMI MegaRaid cards for compatibility reasons. > > Do you mean packing as in gzip or something similar? XFS uses delayed > > allocation which means that it might allocate more space then it would > > normally need to reduce fragmentation. So after a slight period XFS will > > be returning the overallocated space. > > > > No, there is no compression like gzip or anything. When the files are created the > usage shoots up to about 2 Gb. > It then starts dropping down to about 900Mb. It is probably the delayed > allocation. I see this often on XFS when > there's a lot of small files. Ok, I am running the tests here too on a spare 4.3GB disk that I had around. It's not screaming fast but it works. I have the mongo.pl running now on my home box with 6 processes for over an hour and the machine has not crashed yet. The home machine is a AMD Athlon 1.4Ghz with 256MB DDR ram and a AMD760 chipset with a VIA IDE UDMA100 controller. The disk is operating in UDMA33 mode. The process is still running but it looks like we need adaptec hardware to confirm. Eric was testing this IIRC. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Aug 30 14:05:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UL53A30821 for linux-xfs-outgoing; Thu, 30 Aug 2001 14:05:03 -0700 Received: from svr.profc.udec.cl (svr.profc.udec.cl [152.74.200.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UL4ld30798 for ; Thu, 30 Aug 2001 14:04:49 -0700 Received: (qmail 10889 invoked from network); 30 Aug 2001 21:07:09 -0000 Received: from enki.profc.udec.cl (152.74.200.3) by svr.profc.udec.cl with SMTP; 30 Aug 2001 21:07:09 -0000 Date: Thu, 30 Aug 2001 17:06:13 -0400 (CLT) From: Salvador Ramirez X-X-Sender: To: Subject: Mount options for quota support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I've read on the XFS's FAQ that one can use the package quota-tools for setting/using quota on a XFS filesystem, but there don't say how to mount a XFS filesystem with quota support.. how do I do that? the option usrquota on /etc/fstab seem to be ignored.. Thanks in advance, ---sram "Don't listen to what I say; listen to what I mean!" --Feynman Salvador Ramirez Flandes PROFC, Universidad de Concepcion, CHILE http://www.profc.udec.cl/~sram mailto:sram@profc.udec.cl From owner-linux-xfs@oss.sgi.com Thu Aug 30 14:36:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ULahJ31517 for linux-xfs-outgoing; Thu, 30 Aug 2001 14:36:43 -0700 Received: from mail.wearix.com (lorien.wearix.com [193.197.4.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ULaed31496 for ; Thu, 30 Aug 2001 14:36:41 -0700 Received: from wearix.com (elwe.wearix.com [193.197.4.108]) by mail.wearix.com (Postfix) with ESMTP id 7BD2B177CA3 for ; Thu, 30 Aug 2001 23:36:38 +0200 (MEST) Message-ID: <3B8EB1E6.F776E0E@wearix.com> Date: Thu, 30 Aug 2001 23:36:38 +0200 From: Lars Soltau Organization: Wearix GmbH X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Release 1.0.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have spend a lovely evening trying to compile XFS 1.0.1 on a SuSE 7.1 system. I downloaded and installed the compat-egcs- and compat-glibc21 rpms from readhat, and kgcc seems to compile my hello.c just fine. Then I downloaded a vanilla 2.4.5 kernel and applied the patches. Well, first thing I found was that numerous files were missing. The patches inserted #include's for e.g. include/linux/xfs-something.h but failed to create those files. Next thing I tried was to get the source rpm directly from your site, the one with the patches already applied. I installed it and tried to compile a kernel, but the compile failed with zillions of errors in floppy.c. So I can't help thinking that I am doing something very stupid here. But what? Greetings Lars Soltau From owner-linux-xfs@oss.sgi.com Thu Aug 30 14:57:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ULvJ631937 for linux-xfs-outgoing; Thu, 30 Aug 2001 14:57:19 -0700 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 f7ULvFd31918 for ; Thu, 30 Aug 2001 14:57:15 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7UM2q827857 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 30 Aug 2001 15:02:52 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA729611 for ; Thu, 30 Aug 2001 23:57:07 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2852827; Thu, 30 Aug 2001 16:53:19 -0500 (CDT) Received: from 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 QAA09637; Thu, 30 Aug 2001 16:53:19 -0500 (CDT) Message-ID: <3B8EB59F.1636E79@sgi.com> Date: Thu, 30 Aug 2001 16:52:31 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Lars Soltau CC: linux-xfs@oss.sgi.com Subject: Re: Release 1.0.1 References: <3B8EB1E6.F776E0E@wearix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Lars Soltau wrote: > I have spend a lovely evening trying to compile XFS 1.0.1 on a SuSE 7.1 > system. I downloaded and installed the compat-egcs- and compat-glibc21 > rpms from readhat, and kgcc seems to compile my hello.c just fine. Then > I downloaded a vanilla 2.4.5 kernel and applied the patches. Well, first > thing I found was that numerous files were missing. The patches inserted > #include's for e.g. include/linux/xfs-something.h but failed to create > those files. Which ones are you missing? I've compiled from these patches before, so I don't think the patch itelf is broken... > Next thing I tried was to get the source rpm directly from your site, > the one with the patches already applied. I installed it and tried to > compile a kernel, but the compile failed with zillions of errors in > floppy.c. This is probably the broken makefile problem; try a "make mrproper" first. Red Hat ships the kernel tree in a somewhat odd state; we inherit that. HTH, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Aug 30 15:05:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UM50B32184 for linux-xfs-outgoing; Thu, 30 Aug 2001 15:05:00 -0700 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 f7UM4wd32165 for ; Thu, 30 Aug 2001 15:04:58 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7UMAZ828292 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 30 Aug 2001 15:10:35 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA730472 for ; Fri, 31 Aug 2001 00:04:50 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2856347; Thu, 30 Aug 2001 17:01:02 -0500 (CDT) Received: from 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 RAA52332; Thu, 30 Aug 2001 17:01:02 -0500 (CDT) Message-ID: <3B8EB76E.84116CD7@sgi.com> Date: Thu, 30 Aug 2001 17:00:14 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Lars Soltau , linux-xfs@oss.sgi.com Subject: Re: Release 1.0.1 References: <3B8EB1E6.F776E0E@wearix.com> <3B8EB59F.1636E79@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: > > Lars Soltau wrote: > > > I have spend a lovely evening trying to compile XFS 1.0.1 on a SuSE 7.1 > > system. I downloaded and installed the compat-egcs- and compat-glibc21 > > rpms from readhat, and kgcc seems to compile my hello.c just fine. Then > > I downloaded a vanilla 2.4.5 kernel and applied the patches. Well, first > > thing I found was that numerous files were missing. The patches inserted > > #include's for e.g. include/linux/xfs-something.h but failed to create > > those files. > > Which ones are you missing? > > I've compiled from these patches before, so I don't think the patch > itelf is broken... Perhaps this is even simpler - did you apply patch-xfs-1.0.1-only? -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 Aug 30 15:25:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UMP1K32721 for linux-xfs-outgoing; Thu, 30 Aug 2001 15:25:01 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UMOrd32702 for ; Thu, 30 Aug 2001 15:24:54 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15caEN-0004FW-00; Fri, 31 Aug 2001 00:24:11 +0200 Message-ID: <3B8EBD0B.3ECF8150@it.up.ac.za> Date: Fri, 31 Aug 2001 00:24:11 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15caEN-0004FW-00*VWjFJ2tiT7A* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > On Thu, 30 Aug 2001, Paul Schutte wrote: > > > Seth Mos wrote: > > > On Thu, 30 Aug 2001, Paul Schutte wrote: > > > > If you toggle the mode in the bios to scsi mode it works as a normal scsi > > > controller. It is detected in this case by the normal adaptec driver. > > > > > > > It is operating in the RAID mode in the BIOS and not the SCSI mode. > > There is also a 36Gbx4 in a RAID 5 array which I did'nt use for the test. It not > > mounted at the moment. > > You have the latest driver I assume? Their performance was good but we > decided to switch them for the AMI MegaRaid cards for compatibility > reasons. > > > > Do you mean packing as in gzip or something similar? XFS uses delayed > > > allocation which means that it might allocate more space then it would > > > normally need to reduce fragmentation. So after a slight period XFS will > > > be returning the overallocated space. > > > > > > > No, there is no compression like gzip or anything. When the files are created the > > usage shoots up to about 2 Gb. > > It then starts dropping down to about 900Mb. It is probably the delayed > > allocation. I see this often on XFS when > > there's a lot of small files. > > Ok, I am running the tests here too on a spare 4.3GB disk that I had > around. It's not screaming fast but it works. > > I have the mongo.pl running now on my home box with 6 processes for over > an hour and the machine has not crashed yet. > > The home machine is a AMD Athlon 1.4Ghz with 256MB DDR ram and a AMD760 > chipset with a VIA IDE UDMA100 controller. The disk is operating in UDMA33 > mode. The process is still running but it looks like we need adaptec > hardware to confirm. Eric was testing this IIRC. > I have checked straight away and the driver that I am using is still the latest. I managed to complete the creation part on the 4400. It is still perculating away on the copy ... kernel-2.4.10-pre2 and egcs-1.1.2 is used here. 1) if I mount with logbufs=8 then it dies. 2) if I do mkfs.xfs with -i maxpct=90,size=2048 then it also dies irespective of the logbufs settings. 3) mkfs.xfs -f -l size=8192b -i maxpct=90,size=2048 and mount -o logbufs=8 is a lethal combo ;-) 4) mkfs.xfs -f -l size=8192b and mount -o logbufs=2 is stable. These observations holds true for the Dell 4400 in my test environment. The 1400C just died on me using the setting in 4) above. I am going to rebuild the kernel using the old style driver to see if it helps. When should one use logbufs=8 and when not. I messed around with the -i option because ext2 ran out of inodes on the same test. I have 4 mailservers running XFS, on Adaptec hardware ,in production, mounted with logbufs=8. (Butterflies are eating chunks out of my stomac as I am typing ...) They are running for 2 months now without any problems. I think I should remount them with logbufs=2 just in case. Will I lose anything by doing that ? For those interrested The backup speed of these servers increased from about 50Mb/min to about 85Mb/min on full backups when I switched from ext2 to XFS. I really like XFS and are very impressed with the quality and appreciate the effort put into making it happen. Cheers Paul From owner-linux-xfs@oss.sgi.com Thu Aug 30 15:32:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UMWDA00561 for linux-xfs-outgoing; Thu, 30 Aug 2001 15:32:13 -0700 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 f7UMWBd00540 for ; Thu, 30 Aug 2001 15:32:11 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7UMbm830383 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 30 Aug 2001 15:37:48 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA727892 for ; Fri, 31 Aug 2001 00:32:03 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2853180; Thu, 30 Aug 2001 17:29:31 -0500 (CDT) Received: from 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 RAA49845; Thu, 30 Aug 2001 17:29:31 -0500 (CDT) Message-ID: <3B8EBE1B.F8A8CB6D@sgi.com> Date: Thu, 30 Aug 2001 17:28:43 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Schutte CC: Seth Mos , XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: <3B8EBD0B.3ECF8150@it.up.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Paul Schutte wrote: > When should one use logbufs=8 and when not. Digging through the archives... o logbufs=4 or logbufs=8, this increases (from 2) the number of in memory log buffers. This means you can have more active transactions at once, and can still perform metadata changes while the log is being synced to disk. The flip side of this is that the amount of metadata changes which may be lost on crash is greater. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Aug 30 16:40:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UNeLr01874 for linux-xfs-outgoing; Thu, 30 Aug 2001 16:40:21 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7UNeHd01855 for ; Thu, 30 Aug 2001 16:40:18 -0700 Received: from scare ([63.231.179.33]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7UNeGXi047437; Thu, 30 Aug 2001 18:40:16 -0500 (CDT) Subject: Re: OT - HTML posts was Re[2]: kdb not compile From: Russell Cattelan To: Keith Matthews Cc: linux-xfs@oss.sgi.com In-Reply-To: <20010830110558.20C61125E6@rebutia.sweeney.demon.co.uk> References: <29971.999129138@kao2.melbourne.sgi.com> <20010830110558.20C61125E6@rebutia.sweeney.demon.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 30 Aug 2001 18:34:26 -0500 Message-Id: <999214467.2363.21.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 30 Aug 2001 12:05:58 +0100, Keith Matthews wrote: > On Thu, 30 Aug 2001 09:52:18 +1000 Keith Owens > wrote: > > > Please do not send mail to this list using MIME. Your mail had both > > text and HTML and the text was base64 encoded. Use just plain text. > > > On Wed, 29 Aug 2001 15:01:17 +0800, > > "Du Jun" wrote: > > >i386-dis.c: In function `print_insn_i386': > > >i386-dis.c:2143: `bfd_mach_i386_i386_intel_syntax' undeclared (first use in this function) > > > Upgrade your binutils. kdb needs at least binutils-2.9.5.0.22. > > Steve, > > when you get back to your desk would you consider prevailing on the > list administrators to set uo a reject for posts containing HTML? Hmmmm... No I don't that kind of filter is worth the effort or the extra cpu cycles to further body process each email. The current anti-spam body processing is already sucking down a few cycles. > > -- > Keith Matthews Spam trap - my real account at this > node is keith_m > Frequentous Consultants - Linux Services, > Oracle development & database administration > From owner-linux-xfs@oss.sgi.com Thu Aug 30 16:42:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7UNgnt02014 for linux-xfs-outgoing; Thu, 30 Aug 2001 16:42:49 -0700 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 f7UNgkd01995 for ; Thu, 30 Aug 2001 16:42:46 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7UNmN803721 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 30 Aug 2001 16:48:23 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id BAA731312 for ; Fri, 31 Aug 2001 01:42:38 +0200 (CEST) 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 KAA08948; Fri, 31 Aug 2001 10:40:05 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA53408; Fri, 31 Aug 2001 10:40:04 +1100 (AEDT) Date: Fri, 31 Aug 2001 10:40:04 +1100 From: Nathan Scott To: Salvador Ramirez Cc: linux-xfs@oss.sgi.com Subject: Re: Mount options for quota support Message-ID: <20010831104004.R323889@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sram@profc.udec.CL on Thu, Aug 30, 2001 at 05:06:13PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 30, 2001 at 05:06:13PM -0400, Salvador Ramirez wrote: > Hello, > > I've read on the XFS's FAQ that one can use the package > quota-tools for setting/using quota on a XFS filesystem, > but there don't say how to mount a XFS filesystem with > quota support.. how do I do that? the option usrquota on > /etc/fstab seem to be ignored.. > > Thanks in advance, > Refer to the quotaon(8) man page and the README.quota file in the xfsprogs package. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 30 17:34:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V0Y4l02895 for linux-xfs-outgoing; Thu, 30 Aug 2001 17:34:04 -0700 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 f7V0Y2d02876 for ; Thu, 30 Aug 2001 17:34:02 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7V0dc807025 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 30 Aug 2001 17:39:39 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id CAA720437 for ; Fri, 31 Aug 2001 02:33:53 +0200 (CEST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09148; Fri, 31 Aug 2001 11:31:17 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Paul Schutte cc: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. In-reply-to: Your message of "Thu, 30 Aug 2001 18:49:18 +0200." <3B8E6E8E.D2082F15@it.up.ac.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Aug 2001 10:31:17 +1000 Message-ID: <7317.999217877@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 30 Aug 2001 18:49:18 +0200, Paul Schutte wrote: >Unfortunetly I can't get kdb to compile. >It fails with error: > >/home/paul/test/linux-2.4-xfs/linux/include/linux/dis-asm.h:148: storage >size of `display_endian' isn't known >make[3]: *** [kdb_bt.o] Error 1 That field is defined in /usr/include/bfd.h. You need at least binutils-2.9.5.0.22 to compile kdb. From owner-linux-xfs@oss.sgi.com Thu Aug 30 17:39:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V0dYi03071 for linux-xfs-outgoing; Thu, 30 Aug 2001 17:39:34 -0700 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 f7V0dWd03052 for ; Thu, 30 Aug 2001 17:39:32 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7V0j8807348 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 30 Aug 2001 17:45:08 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id CAA734364 for ; Fri, 31 Aug 2001 02:39:23 +0200 (CEST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09176; Fri, 31 Aug 2001 11:38:04 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Michael Wahlbrink" cc: linux-xfs@oss.sgi.com Subject: Re: Problems compiling the xfs kernel In-reply-to: Your message of "Thu, 30 Aug 2001 22:24:15 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Aug 2001 10:38:04 +1000 Message-ID: <7359.999218284@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 30 Aug 2001 22:24:15 +0200, "Michael Wahlbrink" wrote: >I checked out today the xfs kernel from cvs (cvs -z3 checkout linux-2.4-xfs). When I try to compile the kernel I get some errors........ >make[3]: Entering directory `/usr/src/linux/fs/ext2' >gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes >-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer >-pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -c >-o ialloc.o ialloc.c >ialloc.c:308: unterminated macro call You have corrupt sources. rm -rf fs/ext2 and redo the CVS download. If you have the bandwidth, erase everything and get a clean copy. From owner-linux-xfs@oss.sgi.com Thu Aug 30 17:58:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V0w2703519 for linux-xfs-outgoing; Thu, 30 Aug 2001 17:58:02 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V0vwd03497 for ; Thu, 30 Aug 2001 17:57:58 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15cccN-00068X-00; Fri, 31 Aug 2001 02:57:07 +0200 Message-ID: <3B8EE0E3.63FD0BCC@it.up.ac.za> Date: Fri, 31 Aug 2001 02:57:07 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-pre1-xfs-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: <7317.999217877@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15cccN-00068X-00*dDhMn7B8pPc* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Debian stable comes with binutils-2.9.5.0.37-1. Unstable comes with binutils-2.11.90.0.27-2. It fails on both systems. According to the version number it should be fine. I checked on the kdb web pages for clues and saw that I needed a recent version of binutils. I then verified that my version was ok. "locate bfd.h" says there's no such file on any of the 2 systems. Guess I should install binutils from source ? Does anyone know whether these files are in another .deb package. It's really messy when you start mixing packages and installations from source. I am very gratefull that you provide XFS packages for most distributions. Paul Keith Owens wrote: > On Thu, 30 Aug 2001 18:49:18 +0200, > Paul Schutte wrote: > >Unfortunetly I can't get kdb to compile. > >It fails with error: > > > >/home/paul/test/linux-2.4-xfs/linux/include/linux/dis-asm.h:148: storage > >size of `display_endian' isn't known > >make[3]: *** [kdb_bt.o] Error 1 > > That field is defined in /usr/include/bfd.h. You need at least > binutils-2.9.5.0.22 to compile kdb. From owner-linux-xfs@oss.sgi.com Thu Aug 30 18:06:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V16ea03769 for linux-xfs-outgoing; Thu, 30 Aug 2001 18:06:40 -0700 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 f7V16bd03750 for ; Thu, 30 Aug 2001 18:06:37 -0700 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 f7V1CE808823 for ; Thu, 30 Aug 2001 18:12:14 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA09257; Fri, 31 Aug 2001 12:05:11 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA51300; Fri, 31 Aug 2001 12:05:10 +1100 (AEDT) Date: Fri, 31 Aug 2001 12:05:10 +1100 From: Nathan Scott To: Paul Schutte Cc: Keith Owens , XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. Message-ID: <20010831120510.T323889@wobbly.melbourne.sgi.com> References: <7317.999217877@kao2.melbourne.sgi.com> <3B8EE0E3.63FD0BCC@it.up.ac.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B8EE0E3.63FD0BCC@it.up.ac.za>; from paul@it.up.ac.za on Fri, Aug 31, 2001 at 02:57:07AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Fri, Aug 31, 2001 at 02:57:07AM +0200, Paul Schutte wrote: > Debian stable comes with binutils-2.9.5.0.37-1. > Unstable comes with binutils-2.11.90.0.27-2. > It fails on both systems. > > According to the version number it should be fine. > I checked on the kdb web pages for clues and saw that I needed a recent > version of binutils. > I then verified that my version was ok. > > "locate bfd.h" says there's no such file on any of the 2 systems. > > Guess I should install binutils from source ? > > Does anyone know whether these files are in another .deb package. Sorry, my brains switched off this morning - shoulda recognised this issue. Your problem is: # dpkg -S /usr/include/bfd.h binutils-dev: /usr/include/bfd.h # dpkg -s binutils-dev Package: binutils-dev Status: install ok installed Priority: extra Section: devel Installed-Size: 880 Maintainer: Christopher C. Chimelis Source: binutils Version: 2.11.90.0.25-1 ... So you most probably just need binutils-dev. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 30 18:21:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V1Lhf04150 for linux-xfs-outgoing; Thu, 30 Aug 2001 18:21:43 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V1Lbd04131 for ; Thu, 30 Aug 2001 18:21:38 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15cczL-0006LT-00; Fri, 31 Aug 2001 03:20:51 +0200 Message-ID: <3B8EE672.E5DE9608@it.up.ac.za> Date: Fri, 31 Aug 2001 03:20:51 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: Keith Owens , XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: <7317.999217877@kao2.melbourne.sgi.com> <3B8EE0E3.63FD0BCC@it.up.ac.za> <20010831120510.T323889@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15cczL-0006LT-00*hneP8qoGqiA* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanx. My eyes and your brains join forces against us :-> I looked for excactly binutils-dev and could'nt find it. It's almost 4 am in South Africa now, that's hopefully why I am so useless. I will do 'n kdb dump tomorow so that we can seek out the culprit. Paul Nathan Scott wrote: > hi, > > On Fri, Aug 31, 2001 at 02:57:07AM +0200, Paul Schutte wrote: > > Debian stable comes with binutils-2.9.5.0.37-1. > > Unstable comes with binutils-2.11.90.0.27-2. > > It fails on both systems. > > > > According to the version number it should be fine. > > I checked on the kdb web pages for clues and saw that I needed a recent > > version of binutils. > > I then verified that my version was ok. > > > > "locate bfd.h" says there's no such file on any of the 2 systems. > > > > Guess I should install binutils from source ? > > > > Does anyone know whether these files are in another .deb package. > > Sorry, my brains switched off this morning - shoulda recognised > this issue. Your problem is: > > # dpkg -S /usr/include/bfd.h > binutils-dev: /usr/include/bfd.h > # dpkg -s binutils-dev > Package: binutils-dev > Status: install ok installed > Priority: extra > Section: devel > Installed-Size: 880 > Maintainer: Christopher C. Chimelis > Source: binutils > Version: 2.11.90.0.25-1 > ... > > So you most probably just need binutils-dev. > > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 30 18:40:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V1eGg04723 for linux-xfs-outgoing; Thu, 30 Aug 2001 18:40:17 -0700 Received: from jeprox.qsr.com.ph (IDENT:postfix@[202.8.248.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V1eAd04704 for ; Thu, 30 Aug 2001 18:40:11 -0700 Received: from localhost (localhost [127.0.0.1]) by jeprox.qsr.com.ph (Postfix) with ESMTP id 81655AA45; Fri, 31 Aug 2001 09:37:11 +0800 (PHT) Received: by jeprox.qsr.com.ph (Postfix, from userid 511) id AD9FFA9F9; Fri, 31 Aug 2001 09:37:09 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by jeprox.qsr.com.ph (Postfix) with ESMTP id AB7877124; Fri, 31 Aug 2001 09:37:09 +0800 (PHT) Date: Fri, 31 Aug 2001 09:37:09 +0800 (PHT) From: "Ian C. Sison" To: "Philippine Linux Users' Group Mailing List" Cc: Linux XFS Mailing List Subject: Re: [plug] Re: Playing around with NFS+XFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Jijo, did you try bonnie in these tests? Bonnie is a much better stress tester. On Fri, 31 Aug 2001, Federico Sevilla III wrote: > Some follow-up stuff: > > I ran the sequential write tests using dd as in: > > # time dd if=/dev/zero of=/opt/test/test.img bs=1M count=3000 > > with three settings that aren't XFS-related but are NFS-specific. Namely, > the wsize and rsize settings of NFSv3. > > - 8192 - - 32768 - - 65535 - > real 8m23.713s 8m0.675s 8m39.662s > user 0m0.010s 0m0.020s 0m0.040s > sys 0m34.890s 0m35.350s 0m35.480s > > The differences don't seem to be that significant, but I'm going with > 32768 since my system is using pure NFSv3 and not NFSv2. Besides, this is > set in the client side so an NFSv2 client can always use 8192 for both > rsize and wsize. Anyway, this is off-topic for the XFS list (sorry). > > > An observation about disk activity: > > Disk activity is pretty continuous, which is good. However there are > situations where disk activity will stop but network activity continuous. > I presume this is filling up some buffer. Then disk activity will pick up > and network activity will stop for awhile. I presume aggressive flushing > of buffers is going on. This doesn't look quite like "streaming" to me. > I'm not complaining, but just thought I'd relay the tidbit in the hopes of > getting some enlightenment. > > > Some notes on my system: > > o I'm using RAID5, and even if this is hardware RAID, RAID5 writes are > not so good. I should have gone RAID10, but it's too late to shift now. > > o I created the filesystems using "-l size=32768b" in mkfs.xfs > > o I mount the filesystems using "rw,noatime,nodiratime,logbufs=8,biosize=16,osyncisdsync" > > :-) > > "Very happy with NFS+XFS" > --> Jijo > > -- > Federico Sevilla III :: jijo@leathercollection.ph > Network Administrator :: The Leather Collection, Inc. > GnuPG Key: > > _ > Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph > To leave: send "unsubscribe" in the body to plug-request@lists.q-linux.com > > To subscribe to the Linux Newbies' List: send "subscribe" in the body to ph-linux-newbie-request@lists.q-linux.com > From owner-linux-xfs@oss.sgi.com Thu Aug 30 18:41:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V1fwp04866 for linux-xfs-outgoing; Thu, 30 Aug 2001 18:41:58 -0700 Received: from jeprox.qsr.com.ph (IDENT:postfix@[202.8.248.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V1fqd04846 for ; Thu, 30 Aug 2001 18:41:55 -0700 Received: from localhost (localhost [127.0.0.1]) by jeprox.qsr.com.ph (Postfix) with ESMTP id A8123AA45; Fri, 31 Aug 2001 09:38:54 +0800 (PHT) Received: by jeprox.qsr.com.ph (Postfix, from userid 511) id D5D6CA9F9; Fri, 31 Aug 2001 09:38:52 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by jeprox.qsr.com.ph (Postfix) with ESMTP id D3C4F8796; Fri, 31 Aug 2001 09:38:52 +0800 (PHT) Date: Fri, 31 Aug 2001 09:38:52 +0800 (PHT) From: "Ian C. Sison" To: "Philippine Linux Users' Group Mailing List" Cc: Linux XFS Mailing List Subject: Re: [plug] Re: Playing around with NFS+XFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Whoops! missed your earlier post! Sorry! From owner-linux-xfs@oss.sgi.com Thu Aug 30 18:43:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V1hEq05015 for linux-xfs-outgoing; Thu, 30 Aug 2001 18:43:14 -0700 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 f7V1h7d04995 for ; Thu, 30 Aug 2001 18:43:07 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7V1mi810399 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 30 Aug 2001 18:48:45 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA741254 for ; Fri, 31 Aug 2001 03:42:59 +0200 (CEST) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA00688 for linux-xfs@oss.sgi.com; Fri, 31 Aug 2001 11:41:40 +1000 (EST) Date: Fri, 31 Aug 2001 11:41:40 +1000 (EST) From: Andrew Gildfind Message-Id: <200108310141.LAA00688@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 784355 - Improvement request for xfsdump/xfsrestore exit codes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Merge IRIX mods to Linux, the source has diverged a lot... we should plan on doing some reconciliation for the 6.5.15 timeframe... Andrew Date: Thu Aug 30 18:39:05 PDT 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101969a cmd/xfsdump/dump/content.c - 1.8 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Wrap returns with mlog_exit, sprinkle hints. cmd/xfsdump/common/types.h - 1.2 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Expand set of return codes. cmd/xfsdump/common/stream.h - 1.2 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Add new stream definitions. cmd/xfsdump/common/stream.c - 1.2 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Expand stream structure to include exit_code, return and hint fields, this provides a place to store per-stream exit status information. Change stream_register/stream_unregister to stream_register/stream_dead/stream_free, add explicit stream states S_FREE, S_RUNNING, S_ZOMBIE. Add stream_find/stream_find_all and change stream_getix to now lock the stream list. Add stream_set* functions - we don't want people holding pointers into this structure without locks. cmd/xfsdump/common/qlock.c - 1.2 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Add MLOG_BARE flag to all mlog calls. Calls to mlog will not attempt to acquire new locks, they will just print the bare text. cmd/xfsdump/common/mlog.h - 1.2 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Add mlog_exit, mlog_exit_hint macro wrappers that pass file/line to function call. cmd/xfsdump/common/mlog.c - 1.2 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Add mlog_main_exit_* variables - provide a place to put return codes from the main process (as opposed to the streams). Add _mlog_exit() and _mlog_exit_hint() functions, define rvs structure mapping return codes to textual error codes & descriptions. Add mlog_exit_flush that prints stream status and dump summary. - Fix structure initialisation for Linux, remove useless assert. - Make sure hint masks return value for all conditions. cmd/xfsdump/common/main.c - 1.7 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Wrap all return values with a call to mlog_exit() which records the exit code and return value. Group calls to lock initialisation functions. Add mlog_exit() call to usage() as we know that any call to usage precedes an exit. - Add RV_INCOMPLETE exit hint for incomplete dumps, unless some other hint has already been given. cmd/xfsdump/common/dlog.c - 1.2 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Add hints for keyboard interrupt. cmd/xfsdump/common/cldmgr.c - 1.2 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Replace stream_unregister() with stream_dead() cmd/xfsdump/restore/content.c - 1.12 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Wrap returns with mlog_exit, sprinkle hints. - Add hint to DEVICE_NONREMOVABLE in newmedia block, unless an error has been signalled elsewhere we don't really want to log a failure. cmd/xfsdump/man/man8/xfsdump.8 - 1.7 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Describe Dump Status message, and error codes. cmd/xfsdump/man/man8/xfsrestore.8 - 1.4 - merge of irix6.5f-melb:eoe:06291a, irix6.5f-melb:eoe:06307a, and irix6.5f-melb:eoe:06315a, see PV #784355 - Describe Restore Status message, and error codes. From owner-linux-xfs@oss.sgi.com Thu Aug 30 19:23:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V2NRP05829 for linux-xfs-outgoing; Thu, 30 Aug 2001 19:23:27 -0700 Received: from rebel.net.au (IDENT:root@news.tellurian.com.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V2NNd05807 for ; Thu, 30 Aug 2001 19:23:23 -0700 Received: from rebel.net.au (dialup-5.rebel.net.au [203.20.69.75]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id LAA32237 for ; Fri, 31 Aug 2001 11:53:17 +0930 Message-ID: <3B8EF68A.C3FC5FCA@rebel.net.au> Date: Fri, 31 Aug 2001 11:59:30 +0930 From: David Lloyd 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: Pingpong-Journaling? Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by rebel.net.au id LAA32237 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7V2NOd05808 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anyone got any comments on this with respect to XFS? DSL -------- Original Message -------- Subject: [reiserfs-list] Pingpong-Journaling in reiser4? Date: Thu, 30 Aug 2001 23:30:16 +0200 From: Xuan Baldauf Organization: Medium.net To: Hans Reiser CC: reiserfs-list@namesys.com Hello Hans, are you considering pingpong-journaling for reiser4? Ping-Pong journaling is that, in the case you are able to know that the blocks you are writing to will be overwritten due to outstanding requests|future transactions, you do not write the invalidation block of the old transaction until the affected blocks are overwritten by the new transaction. Doing journaling in that way, you are bringing the count of required writes for journaling to the count of required writes for non-journaling (1 changed block, 1 write instead of 1 changed block, 1 write to the journal and 1 write to the real location), and thus saving half the journal-related writes in the ideal case. The superblock is a good candidate for this feature. I think that heavily loaded servers with parallel disk writes will be able to see a considerable speedup. Xuân. From owner-linux-xfs@oss.sgi.com Thu Aug 30 20:10:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V3ASf06705 for linux-xfs-outgoing; Thu, 30 Aug 2001 20:10:28 -0700 Received: from oco.net (mail.oco.net [216.171.163.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V3AQd06686 for ; Thu, 30 Aug 2001 20:10:26 -0700 Received: from krum [64.111.33.44] by oco.net (SMTPD32-6.06) id A01389600F2; Thu, 30 Aug 2001 20:10:11 -0700 From: "Kevin Krumwiede" To: Subject: Naming of XFS patches Date: Thu, 30 Aug 2001 23:07:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I noticed the version naming has changed for the XFS patches. If there wasn't a particular reason for this, let me throw in my two copper: Instead of patch.2.4.8.xfs.2001-08-15.bz2, for example, it would be more conventional to call it linux-2.4.8.xfs-2001-08-15.patch.bz2. The name should start with the name of what it is you're patching, and end with .patch.bz2 because that's what kind of file it is. In a directory full of tarballs, it makes it easy to identify patches that apply to a given source. I don't know if this is officially recommended by anything, I just know that most every patch I've encountered follows this convention. From owner-linux-xfs@oss.sgi.com Thu Aug 30 20:14:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V3Egk06872 for linux-xfs-outgoing; Thu, 30 Aug 2001 20:14:42 -0700 Received: from mplspop6.mpls.uswest.net (mail.mpls.uswest.net [204.147.80.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V3Eed06853 for ; Thu, 30 Aug 2001 20:14:40 -0700 Received: (qmail 18953 invoked from network); 31 Aug 2001 03:14:42 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop6.mpls.uswest.net with SMTP; 31 Aug 2001 03:14:42 -0000 Date: Thu, 30 Aug 2001 22:10:49 -0500 Message-ID: <3B8F0039.C9CE8D2B@sgi.com> From: "Eric Sandeen" To: "Kevin Krumwiede" Cc: linux-xfs@oss.sgi.com 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 Subject: Re: Naming of XFS patches References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Kevin Krumwiede wrote: > Instead of patch.2.4.8.xfs.2001-08-15.bz2, for example, it would be more > conventional to call it linux-2.4.8.xfs-2001-08-15.patch.bz2. > > I don't know if this is officially recommended by anything, I just know that > most every patch I've encountered follows this convention. Who knows where it came from.... the weight of history is behind it. :-) Next time I look at the script that generates the patches, I could change it - your suggestion does seem more intuitive. -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 Aug 30 20:21:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V3L0M07069 for linux-xfs-outgoing; Thu, 30 Aug 2001 20:21:00 -0700 Received: from mplspop6.mpls.uswest.net (mail.mpls.uswest.net [204.147.80.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V3Kvd07050 for ; Thu, 30 Aug 2001 20:20:58 -0700 Received: (qmail 26850 invoked from network); 31 Aug 2001 03:20:59 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop6.mpls.uswest.net with SMTP; 31 Aug 2001 03:20:59 -0000 Date: Thu, 30 Aug 2001 22:17:06 -0500 Message-ID: <3B8F01B2.8EC7FF25@sgi.com> From: "Eric Sandeen" To: "Kevin Krumwiede" , linux-xfs@oss.sgi.com 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 Subject: Re: Naming of XFS patches References: <3B8F0039.C9CE8D2B@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Kevin Krumwiede wrote: > Instead of patch.2.4.8.xfs.2001-08-15.bz2, for example, On the other hand, see: http://www.kernel.org/pub/linux/kernel/v2.4/ for a whole bunch of "patch-2.4.X.bz2" examples, from some guy named "Linus." :) -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 Aug 30 21:09:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V49p608042 for linux-xfs-outgoing; Thu, 30 Aug 2001 21:09:51 -0700 Received: from web20204.mail.yahoo.com (web20204.mail.yahoo.com [216.136.226.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V49id07999 for ; Thu, 30 Aug 2001 21:09:44 -0700 Message-ID: <20010831040943.97281.qmail@web20204.mail.yahoo.com> Received: from [141.154.59.67] by web20204.mail.yahoo.com via HTTP; Thu, 30 Aug 2001 21:09:43 PDT Date: Thu, 30 Aug 2001 21:09:43 -0700 (PDT) From: Lee Go-Tze Subject: Resizing XFS partition and external journal To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear list, Can someone explain why it's not a good idea to use xfs_growfs on a mounted XFS file system? Is there a plan to make it work? Isn't this the preferred way to grow a XFS partition when the support is in place from LVM to integrate with file system? A separate question on external journal. I heard it is possible to use an external journal with XFS, can someone confirm this? And how can I do it? If the external journal is supported will it be possible to store it in a NVRAM disk (like ext3fs external journal)? Thanks for you reply. Gotze __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-linux-xfs@oss.sgi.com Thu Aug 30 21:09:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V49lZ08034 for linux-xfs-outgoing; Thu, 30 Aug 2001 21:09:47 -0700 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 f7V49hd07993 for ; Thu, 30 Aug 2001 21:09:44 -0700 Received: from fuzzy.melbourne.sgi.com (fuzzy.melbourne.sgi.com [134.14.55.199]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7V4GMa23030 for ; Thu, 30 Aug 2001 21:16:23 -0700 Received: (from fsgqa@localhost) by fuzzy.melbourne.sgi.com (8.9.3/8.9.3) id OAA26759 for linux-xfs@oss.sgi.com; Fri, 31 Aug 2001 14:36:40 +1000 Date: Fri, 31 Aug 2001 14:36:40 +1000 From: FSG QA Account Message-Id: <200108310436.OAA26759@fuzzy.melbourne.sgi.com> Subject: TAKE - xfstests/common.dump Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Change motivated by xfstests/024. Date: Thu Aug 30 21:06:45 PDT 2001 Workarea: fuzzy.melbourne.sgi.com:/home/fsgqa/isms/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101977a cmd/xfstests/common.dump - 1.13 - Use umount/mount to ensure stuff is written to disk so that bulkstat will be sure to have the latest attributes for dump/restore. From owner-linux-xfs@oss.sgi.com Thu Aug 30 21:48:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V4mjD08909 for linux-xfs-outgoing; Thu, 30 Aug 2001 21:48:45 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V4mfd08890 for ; Thu, 30 Aug 2001 21:48:41 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id VAA04936 for ; Thu, 30 Aug 2001 21:48:38 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA10031; Fri, 31 Aug 2001 15:46:42 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA86297; Fri, 31 Aug 2001 15:46:31 +1100 (AEDT) Date: Fri, 31 Aug 2001 15:46:30 +1100 From: Nathan Scott To: Lee Go-Tze Cc: linux-xfs@oss.sgi.com Subject: Re: Resizing XFS partition and external journal Message-ID: <20010831154630.Z323889@wobbly.melbourne.sgi.com> References: <20010831040943.97281.qmail@web20204.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010831040943.97281.qmail@web20204.mail.yahoo.com>; from leegotze@yahoo.com on Thu, Aug 30, 2001 at 09:09:43PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Aug 30, 2001 at 09:09:43PM -0700, Lee Go-Tze wrote: > Dear list, > > Can someone explain why it's not a good idea to > use xfs_growfs on a mounted XFS file system? It is _only_ possible to grow a mounted XFS filesystem. > Is there a plan to make it work? Isn't this the > preferred way to grow a XFS partition when the > support is in place from LVM to integrate with > file system? > There is an unresolved bug in either LVM or XFS here, no one knows which. growfs seems to work fine on a non-LVM partition and there are automated tests to check that case (it is less interesting than the LVM case of course, but without LVM in the picture it always seems to work). [Not passing-the-buck, just stating what we know so far] > A separate question on external journal. I heard > it is possible to use an external journal with XFS, > can someone confirm this? And how can I do it? Yes, use "-l logdev=/dev/XXX" to mkfs.xfs(8) and mount(8) with the "-o logdev=/dev/XXX" option. > If the external journal is supported will it > be possible to store it in a NVRAM disk (like > ext3fs external journal)? > Yes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 30 21:58:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V4wuL09146 for linux-xfs-outgoing; Thu, 30 Aug 2001 21:58:56 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V4wod09125 for ; Thu, 30 Aug 2001 21:58:50 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA01863 for ; Thu, 30 Aug 2001 21:57:08 -0700 (PDT) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA32568 for linux-xfs@oss.sgi.com; Fri, 31 Aug 2001 14:56:16 +1000 (EST) Date: Fri, 31 Aug 2001 14:56:16 +1000 (EST) From: Andrew Gildfind Message-Id: <200108310456.OAA32568@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 784355 - Improvement request for xfsdump/xfsrestore exit codes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Update qa... Date: Thu Aug 30 21:55:05 PDT 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101982a cmd/xfstests/051.out - 1.12 cmd/xfstests/026.noquota - 1.2 cmd/xfstests/027.noquota - 1.2 cmd/xfstests/046.noquota - 1.2 cmd/xfstests/056.noquota - 1.2 cmd/xfstests/046.ugquota - 1.2 cmd/xfstests/026.grpquota - 1.2 cmd/xfstests/026.ugquota - 1.2 cmd/xfstests/026.usrquota - 1.2 cmd/xfstests/027.grpquota - 1.2 cmd/xfstests/027.ugquota - 1.2 cmd/xfstests/027.usrquota - 1.2 cmd/xfstests/046.grpquota - 1.2 cmd/xfstests/056.usrquota - 1.2 cmd/xfstests/046.usrquota - 1.2 cmd/xfstests/056.grpquota - 1.3 cmd/xfstests/056.ugquota - 1.3 cmd/xfstests/028.usrquota - 1.2 cmd/xfstests/028.grpquota - 1.2 cmd/xfstests/028.noquota - 1.3 cmd/xfstests/047.usrquota - 1.2 cmd/xfstests/028.ugquota - 1.2 cmd/xfstests/047.noquota - 1.2 cmd/xfstests/047.ugquota - 1.2 cmd/xfstests/047.grpquota - 1.2 cmd/xfstests/022.grpquota - 1.2 cmd/xfstests/022.noquota - 1.2 cmd/xfstests/036.ugquota - 1.2 cmd/xfstests/022.ugquota - 1.2 cmd/xfstests/022.usrquota - 1.2 cmd/xfstests/023.grpquota - 1.2 cmd/xfstests/023.noquota - 1.2 cmd/xfstests/036.usrquota - 1.2 cmd/xfstests/023.ugquota - 1.2 cmd/xfstests/023.usrquota - 1.2 cmd/xfstests/024.grpquota - 1.2 cmd/xfstests/024.noquota - 1.2 cmd/xfstests/055.usrquota - 1.2 cmd/xfstests/024.ugquota - 1.2 cmd/xfstests/024.usrquota - 1.2 cmd/xfstests/025.grpquota - 1.2 cmd/xfstests/025.noquota - 1.2 cmd/xfstests/055.ugquota - 1.2 cmd/xfstests/025.ugquota - 1.2 cmd/xfstests/025.usrquota - 1.2 cmd/xfstests/035.grpquota - 1.2 cmd/xfstests/035.noquota - 1.2 cmd/xfstests/055.noquota - 1.2 cmd/xfstests/035.ugquota - 1.2 cmd/xfstests/035.usrquota - 1.2 cmd/xfstests/036.grpquota - 1.2 cmd/xfstests/036.noquota - 1.2 cmd/xfstests/055.grpquota - 1.2 cmd/xfstests/043.usrquota - 1.2 cmd/xfstests/043.ugquota - 1.2 cmd/xfstests/037.grpquota - 1.2 cmd/xfstests/037.noquota - 1.2 cmd/xfstests/043.noquota - 1.2 cmd/xfstests/037.ugquota - 1.2 cmd/xfstests/037.usrquota - 1.2 cmd/xfstests/038.grpquota - 1.2 cmd/xfstests/038.noquota - 1.2 cmd/xfstests/043.grpquota - 1.2 cmd/xfstests/038.ugquota - 1.2 cmd/xfstests/038.usrquota - 1.2 cmd/xfstests/039.grpquota - 1.2 cmd/xfstests/039.noquota - 1.2 cmd/xfstests/039.usrquota - 1.2 cmd/xfstests/039.ugquota - 1.2 - Update for expanded dump/restore status reporting see PV #784355 From owner-linux-xfs@oss.sgi.com Thu Aug 30 22:02:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V52ge09341 for linux-xfs-outgoing; Thu, 30 Aug 2001 22:02:42 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V52dd09322 for ; Thu, 30 Aug 2001 22:02:39 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA01994 for ; Thu, 30 Aug 2001 22:00:56 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA82533 for linux-xfs@oss.sgi.com; Fri, 31 Aug 2001 15:00:05 +1000 (EST) Date: Fri, 31 Aug 2001 15:00:05 +1000 (EST) From: Nathan Scott Message-Id: <200108310500.PAA82533@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This emulates more closely the way Alan, Jan and I have been recently discussing doing quotactl in the brave new world of Linux quota (_emulates_, its nothing like it really cos Linus' tree is a fair way behind wrt quota now - Jan's new VFS quota code is a 2.5 thing, as I understand it). cheers. Date: Thu Aug 30 20:53:05 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/base-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101974a linux/include/linux/fs.h - 1.113 linux/fs/dquot.c - 1.34 linux/fs/xfs/linux/xfs_super.c - 1.137 - rework things to use a s_qop vector instead of hanging a function pointer off the s_dquot field. subtle changes in the semantics are acomin', changing who does what level of integrity & security checking (we need to do more now, cos its going to become our responsibility). linux/fs/xfs/xfs_qm_syscalls.c - 1.54 linux/fs/xfs/xfs_qm.h - 1.19 linux/include/linux/xqm.h - 1.8 - fix up debugging and diagnostic messages. cmd/xfsprogs/include/xqm.h - 1.6 - benign changes for userspace, keep in sync with kernel. From owner-linux-xfs@oss.sgi.com Thu Aug 30 22:31:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V5VQd09797 for linux-xfs-outgoing; Thu, 30 Aug 2001 22:31:26 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V5VNd09778 for ; Thu, 30 Aug 2001 22:31:23 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA19613; Fri, 31 Aug 2001 07:31:22 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA28480; Fri, 31 Aug 2001 07:31:22 +0200 (CEST) Date: Fri, 31 Aug 2001 07:31:21 +0200 (CEST) From: Seth Mos To: Paul Schutte cc: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. In-Reply-To: <3B8EBD0B.3ECF8150@it.up.ac.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 31 Aug 2001, Paul Schutte wrote: > Seth Mos wrote: > > > On Thu, 30 Aug 2001, Paul Schutte wrote: My home box survived the nightly run of mongo.pl with 6 processes. Full reply later. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Aug 30 23:50:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V6oQf11084 for linux-xfs-outgoing; Thu, 30 Aug 2001 23:50:26 -0700 Received: from pipt.oz.cc.utah.edu (jdr1529@pipt.oz.cc.utah.edu [155.99.2.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V6oOd11065 for ; Thu, 30 Aug 2001 23:50:24 -0700 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id AAA22337 for ; Fri, 31 Aug 2001 00:50:22 -0600 (MDT) Date: Fri, 31 Aug 2001 00:50:22 -0600 (MDT) From: james rich To: linux-xfs@oss.sgi.com Subject: lost xfs filesystem on md0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi folks, I've got two old SCSI disks configured in a raid0 setup on /dev/md0. I had an unplanned power loss and now I get the following error message: scsi0: ERROR on channel 0, id 6, lun 0, CDB: Read (10) 00 00 00 00 38 00 00 08 00 Info fld=0x3f, Current sd08:21: sense key Medium Error I/O error: dev 08:21, sector 31 I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x30: xfs_trans_read_buf The filesystem completes the mount process but no files show up (/var/spool is gone now :( ). Does the above error indicate an error with hardware or with xfs? In either case, is there some way to recover the contents of /dev/md0? James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Fri Aug 31 00:04:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V74DL11384 for linux-xfs-outgoing; Fri, 31 Aug 2001 00:04:13 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V749d11365 for ; Fri, 31 Aug 2001 00:04:09 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA19130 for ; Fri, 31 Aug 2001 09:04:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA27795 for linux-xfs@oss.sgi.com; Fri, 31 Aug 2001 09:04:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id C83BE57306 for ; Fri, 31 Aug 2001 09:03:18 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 694CE25835 for ; Fri, 31 Aug 2001 09:03:18 +0200 (CEST) Message-ID: <3B8F36B6.B6FC8B75@ch.sauter-bc.com> Date: Fri, 31 Aug 2001 09:03:18 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Re: lost xfs filesystem on md0 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk james rich schrieb: > > Hi folks, > I've got two old SCSI disks configured in a raid0 setup on > /dev/md0. I had an unplanned power loss and now I get the following error > message: > > scsi0: ERROR on channel 0, id 6, lun 0, CDB: Read (10) 00 00 00 00 38 00 > 00 08 00 > Info fld=0x3f, Current sd08:21: sense key Medium Error > I/O error: dev 08:21, sector 31 This seems to be a hardware error. > I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x30: > xfs_trans_read_buf > > The filesystem completes the mount process but no files show up > (/var/spool is gone now :( ). Does the above error indicate an error with > hardware or with xfs? In either case, is there some way to recover the > contents of /dev/md0? Since raid0 is in fact not redundant, you can most likely not recover. What you could try is to dd the broken disk to a new one and then startup the raid. Usually when XFS finds a hardware problem it shuts down. With the new drive there may be some corrupt sectors which could not be read from the old drive but you can then try to repair the fs with xfs_repair. The problem will we to dd the old to the new disk because when dd reaches a bad sector it will most likely abort. If so you have to avoid that dd tries to read the bad sectors. It can be tricky... Simon > > James Rich > james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Fri Aug 31 00:11:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V7BmT11585 for linux-xfs-outgoing; Fri, 31 Aug 2001 00:11:48 -0700 Received: from maggie.one-2-one.net (maggie.one-2-one.net [195.94.80.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V7Bjd11566 for ; Fri, 31 Aug 2001 00:11:45 -0700 Received: from PowerBox.MysticWorld.de (p3E9E5F93.dip.t-dialin.net [62.158.95.147]) by maggie.one-2-one.net (8.11.0/8.11.0) with ESMTP id f7V7GxN00757 for ; Fri, 31 Aug 2001 09:17:00 +0200 Received: from there (PowerBox.MysticWorld.de [192.168.1.1]) by PowerBox.MysticWorld.de (8.12.0.Beta16/8.12.0.Beta16) with SMTP id f7V7BUW6003635 for ; Fri, 31 Aug 2001 09:11:30 +0200 Message-Id: <200108310711.f7V7BUW6003635@PowerBox.MysticWorld.de> Content-Type: text/plain; charset="iso-8859-15" From: Alexander Feigl To: linux-xfs@oss.sgi.com Subject: Complete lockups while nightly cronjob Date: Fri, 31 Aug 2001 09:11:30 +0200 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! >From time to time I get complete lockups during the nightly cron jobs at 04:00. As the machine is in X most of the time I was unable to record any OOPS data yet. As far as I remember I saw a "bug in slab" once I was in console. Is there an other way to record OOPS or do I have do write down the oops? (saving to hd would be great). Using kernel-2.4.9 with development patches gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release / Mandrake Linux 8.1) Alexander Feigl From owner-linux-xfs@oss.sgi.com Fri Aug 31 00:25:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V7P5r11880 for linux-xfs-outgoing; Fri, 31 Aug 2001 00:25:05 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V7P1d11861 for ; Fri, 31 Aug 2001 00:25:02 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f7V7KlR16870; Fri, 31 Aug 2001 09:20:47 +0200 Message-Id: <4.3.2.7.2.20010831091832.036853f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Aug 2001 09:20:06 +0200 To: Gary Orser From: Seth Mos Subject: Re: nfs3 problems w/xfs? Cc: Tad Dolphay , 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 09:36 30-8-2001 -0600, Gary Orser wrote: >Seth, > >HeeHaw, that's it. Thanks much! I'm a sysadmin so I have seen lot's of these things before. >hdparm -d1 -X23 /dev/hda > >Same dd test to xfs was 3 min instead of 22! > >System cpu% single figures, response normal. > >The over the wire test went from 26 min to 5, >achieving about 70mb through put. That's nice but you could also enlarge the network buffers but YMMV. See the other post about XFS + NFS that i had sent out. 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 Aug 31 02:00:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V90Zk13417 for linux-xfs-outgoing; Fri, 31 Aug 2001 02:00:35 -0700 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 f7V90Pd13398 for ; Fri, 31 Aug 2001 02:00:27 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id D0573C001FA for ; Fri, 31 Aug 2001 17:00:11 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 721E6C001F7 for ; Fri, 31 Aug 2001 17:00:10 +0800 (PHT) Date: Fri, 31 Aug 2001 17:00:10 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Playing around with NFS+XFS In-Reply-To: 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 Thu, 30 Aug 2001 at 22:37, Seth Mos wrote: > I use 16384 for 100Mbit at work which seems to be a decent size vs > reponse ratio. I'm too lazy to do yet more tests, so I'm taking your (Seth's) word for it. << changing /etc/fstab >> ;> > I have a few standard bonnie results of linux -> linux tests on my > homepage http://iserv.nl/ I just checked it out and it's _significantly_ better than my results, and my setup is supposed to pack more punch than yours in all aspects except tuning (where I'm slowly learning thanks to you). Hmm ... > Server was a pIII 450 with 256MB of ram and a 2c905B NIC and a 40GB > IDE disk in UDMA33 mode. Mine is a Pentium III 733MHz with 512MB RAM, a TLAN 10/100MBps NIC running 100Mbps full-duplex, and 4 x 36GB UDMA/66 hard drives in hardware RAID5. This is starting to get a little off-topic in that it's not XFS-specific anymore. I hope everyone else will pardon it: > I used 8 nfsd processes Just a note, Debian's nfs-kernel-server package has this as the default via the following in /etc/init.d/nfs-kernel-server: RPCNFSDCOUNT=8 > and enlarged the buffer size from 64KB to 256KB. > echo 262144 > /proc/sys/net/core/rmem_default > echo 262144 > /proc/sys/net/core/rmem_max I read somewhere that this can lead to some not-so-nice situations when left like this instead of the default. Would you be able to qualify this? I do remember reading somewhere that the recommended action will be to set buffer sizes to 256KB, then start the NFS server, then revert to 64KB. I was wondering if you'd have any information on that. Now for something that I _think_ is a little more on-topic (but still not quite XFS specific): I tweaked my /proc/sys/vm/bdflush a little, bringing down age_buffer to 100 jiffies (1 second) from 3000 jiffies (30 seconds). I did this in the hopes that idle systems would flush dirty buffers sooner. I left everything at their defaults, which are: nfract = 30 ndirty = 64 nrefill = 64 nref_dirt = 256 age_super = 60 o Did my bringing down age_buffer to 1 second make things too synchronous that writes were significantly affected? o Will bringing up nfract allow the system to perform better? Or will this simply chunk up disk writes and make the system less responsive during those buffer flushes? o How will increasing or decreasing ndirty affect disk-intensive operations like database updates or massive file transfers? Hopefully those (like Seth Mos, hehehe) with much more administrative experience than I can help out and recommend tuning parameters? I thank Seth for the NFS tuning tips. Maybe if he has some hidden bdflush (or even buffermem) secrets, he can share them with the list? ;> Thanks a lot in advance! --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Fri Aug 31 02:12:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7V9CTB13767 for linux-xfs-outgoing; Fri, 31 Aug 2001 02:12:29 -0700 Received: from rebel.net.au (IDENT:root@www.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7V9CQd13746 for ; Fri, 31 Aug 2001 02:12:26 -0700 Received: from rebel.net.au (dialup-5.rebel.net.au [203.20.69.75]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id SAA09578; Fri, 31 Aug 2001 18:41:22 +0930 Message-ID: <3B8F5633.EE17C61C@rebel.net.au> Date: Fri, 31 Aug 2001 18:47:39 +0930 From: David Lloyd 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: Federico Sevilla III CC: Linux XFS Mailing List Subject: Re: Playing around with NFS+XFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Heh! > > I have a few standard bonnie results of linux -> linux tests on my > > homepage http://iserv.nl/ > > I just checked it out and it's _significantly_ better than my results, and > my setup is supposed to pack more punch than yours in all aspects except > tuning (where I'm slowly learning thanks to you). I tweaked my NFS settings today and the difference is extremely noticable... DSL -- User: Is Windows a real operating system? MegaHal: It is a free operating system. - Quoting "megahal" (download: http://megahal.sourceforge.net/) From owner-linux-xfs@oss.sgi.com Fri Aug 31 03:30:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VAUiI15148 for linux-xfs-outgoing; Fri, 31 Aug 2001 03:30:44 -0700 Received: from electre.pasteur.fr (electre.pasteur.fr [157.99.64.120]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VAUcd15129 for ; Fri, 31 Aug 2001 03:30:39 -0700 Received: from pasteur.fr (xiii.bis.pasteur.fr [157.99.90.14]) by electre.pasteur.fr (8.11.6/8.11.6) with ESMTP id f7VAUZM346223; Fri, 31 Aug 2001 12:30:35 +0200 (CEST) Message-ID: <3B8F674A.43E8F325@pasteur.fr> Date: Fri, 31 Aug 2001 12:30:34 +0200 From: Tru Huynh Organization: Institut Pasteur X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux XFS Mailing List CC: "linux-ide-arrays@lists.math.uh.edu" Subject: OT (Re: Playing around with NFS+XFS) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk YMMV ;) Here is our current setup nfs server: with RPCNFSDCOUNT=16 /etc/init.d/nfs instead of the default 8 dual p3-866 2x256PC133 3com 3c905CX-TXM card 3ware 6800 in JBOD/8x IBM sofware raid 5 (7 disk + host spare) xfs with external log on a software raid 1 array (hda/hdc) kernel 2.4.10-pre2-xfs-30082001 (egcs-1.1.2 release) redhat 7.1 based /dev/md0 on /raid5 type xfs (rw,noatime,nodiratime,logbufs=8,logdev=/dev/md1) /dev/hda7 on /scratch type xfs (rw,noatime,nodiratime,logbufs=8) client: Athlon 10x100MHz 2x256 PC133 3com 3c905CX-TXM card plain SGI-1.0.1 xfs install [tru@xiii bonnie++-1.00g]$ mount <...> sheridan.bis.pasteur.fr:/raid5/home/Bis on /home/Bis type nfs (rw,nfsvers=3,addr=xxx.xxx.xxx.xxx) Version 1.00g ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP over xfs-nfs 1G 4112 30 4325 2 3487 3 10496 88 11030 4 629.1 3 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 817 3 4216 9 1004 3 980 2 4934 4 1021 4 over xfs-nfs,1G,4112,30,4325,2,3487,3,10496,88,11030,4,629.1,3,16,817,3,4216,9,1004,3,980,2,4934,4,1021,4 -- Dr Tru Huynh | Bioinformatique Structurale mailto:tru@pasteur.fr | tel/fax +33 1 45 68 87 37/19 Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France From owner-linux-xfs@oss.sgi.com Fri Aug 31 03:38:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VAcBh15332 for linux-xfs-outgoing; Fri, 31 Aug 2001 03:38:11 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VAc8d15313 for ; Fri, 31 Aug 2001 03:38:09 -0700 Received: (qmail 24101 invoked from network); 31 Aug 2001 10:38:03 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 31 Aug 2001 10:38:03 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Alexander Feigl cc: linux-xfs@oss.sgi.com Subject: Re: Complete lockups while nightly cronjob In-reply-to: Your message of "Fri, 31 Aug 2001 09:11:30 +0200." <200108310711.f7V7BUW6003635@PowerBox.MysticWorld.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Aug 2001 20:38:02 +1000 Message-ID: <14046.999254282@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 31 Aug 2001 09:11:30 +0200, Alexander Feigl wrote: >From time to time I get complete lockups during the nightly cron jobs at >04:00. As the machine is in X most of the time I was unable to record any >OOPS data yet. As far as I remember I saw a "bug in slab" once I was in >console. Is there an other way to record OOPS or do I have do write down the >oops? (saving to hd would be great). linux/Documentation/oops-tracing.txt From owner-linux-xfs@oss.sgi.com Fri Aug 31 04:00:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VB08F15774 for linux-xfs-outgoing; Fri, 31 Aug 2001 04:00:08 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VB00d15731 for ; Fri, 31 Aug 2001 04:00:00 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id MAA26692; Fri, 31 Aug 2001 12:59:53 +0200 (CEST) Message-Id: <4.3.2.7.2.20010831124708.03d1a8e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Aug 2001 12:58:56 +0200 To: Paul Schutte From: Seth Mos Subject: Re: Kernel hangs with mongo.pl benchmark. Cc: XFS mailing list In-Reply-To: <3B8EBD0B.3ECF8150@it.up.ac.za> 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:24 31-8-2001 +0200, Paul Schutte wrote: >Seth Mos wrote: > > > On Thu, 30 Aug 2001, Paul Schutte wrote: > > Ok, I am running the tests here too on a spare 4.3GB disk that I had > > around. It's not screaming fast but it works. > > > > I have the mongo.pl running now on my home box with 6 processes for over > > an hour and the machine has not crashed yet. > > > > The home machine is a AMD Athlon 1.4Ghz with 256MB DDR ram and a AMD760 > > chipset with a VIA IDE UDMA100 controller. The disk is operating in UDMA33 > > mode. The process is still running but it looks like we need adaptec > > hardware to confirm. Eric was testing this IIRC. > > > >I have checked straight away and the driver that I am using is still the >latest. > >I managed to complete the creation part on the 4400. It is still >perculating away on >the copy ... It takes quite some time. >kernel-2.4.10-pre2 and egcs-1.1.2 is used here. > >1) if I mount with logbufs=8 then it dies. This can happen if you have too little memory. I couldn't mount my disk with logbufs=8 on a 128MB machine. >2) if I do mkfs.xfs with -i maxpct=90,size=2048 then it also dies >irespective of the >logbufs settings. I don't know how large your raid array is but you only need larger inodes when passing the 1TB barrier and the maxpct option says how much percent of disk space can be used for inodes. I did not make a fs with more inodes and it survived normally. the default is 25% >3) mkfs.xfs -f -l size=8192b -i maxpct=90,size=2048 and mount -o logbufs=8 >is a lethal >combo ;-) It might be, maybe one of the crew an answer this one. >4) mkfs.xfs -f -l size=8192b and mount -o logbufs=2 is stable. Which are the defaults for making and mounting a xfs fs. If logbufs is not given 2 is used and the logsize of the fs is based on the amount of space. >These observations holds true for the Dell 4400 in my test environment. > >The 1400C just died on me using the setting in 4) above. That should not happen. >I am going to rebuild the kernel using the old style driver to see if it >helps. define "old style" >When should one use logbufs=8 and when not. If you have enough memory and a very busy filesystem you can use this to speed it up. But like the others said this will also make the amount of loss higher because more stuff is floating through the void at any given time. >I messed around with the -i option because ext2 ran out of inodes on the >same test. Unless you really need more then 25% of your disk converted to inodes you can use this. Can somebody comment on how to see if you are running out of inodes? Will a message be logged to syslog when you have reached this limit? >I have 4 mailservers running XFS, on Adaptec hardware ,in production, >mounted with >logbufs=8. >(Butterflies are eating chunks out of my stomac as I am typing ...) Better make var use 2 instead which reduces the amount of damage that can be done, and if you are paranoid mount it with wsync. >They are running for 2 months now without any problems. >I think I should remount them with logbufs=2 just in case. >Will I lose anything by doing that ? Only speed. But I guess that your mail is worth more. >For those interrested >The backup speed of these servers increased from about 50Mb/min to about >85Mb/min on >full backups when I switched from ext2 to XFS. I see similar behaviour in starting up machines which tends to be a tad faster. >I really like XFS and are very impressed with the quality and appreciate >the effort >put into making it happen. So do we :-) 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 Aug 31 04:24:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VBOjA16416 for linux-xfs-outgoing; Fri, 31 Aug 2001 04:24:45 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VBObd16397 for ; Fri, 31 Aug 2001 04:24:38 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id NAA00365; Fri, 31 Aug 2001 13:24:02 +0200 (CEST) Message-Id: <4.3.2.7.2.20010831125922.03d3aba0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Aug 2001 13:23:17 +0200 To: Federico Sevilla III From: Seth Mos Subject: Re: Playing around with NFS+XFS Cc: Linux XFS Mailing List 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 17:00 31-8-2001 +0800, you wrote: >On Thu, 30 Aug 2001 at 22:37, Seth Mos wrote: > > I use 16384 for 100Mbit at work which seems to be a decent size vs > > reponse ratio. > >I'm too lazy to do yet more tests, so I'm taking your (Seth's) word for >it. << changing /etc/fstab >> ;> :) > > I have a few standard bonnie results of linux -> linux tests on my > > homepage http://iserv.nl/ > >I just checked it out and it's _significantly_ better than my results, and >my setup is supposed to pack more punch than yours in all aspects except >tuning (where I'm slowly learning thanks to you). > >Hmm ... It's just a matter of time. > > Server was a pIII 450 with 256MB of ram and a 2c905B NIC and a 40GB > > IDE disk in UDMA33 mode. > >Mine is a Pentium III 733MHz with 512MB RAM, a TLAN 10/100MBps NIC running >100Mbps full-duplex, and 4 x 36GB UDMA/66 hard drives in hardware RAID5. Your write speeds will be lower but not more then a single disk if the card you are using is beefy enough. Raid5 involves a lot more overhead during writes, we once noted a windows NT sytem going faster when one of the harddisks in the raid5 failed. After that we converted it to raid10. >This is starting to get a little off-topic in that it's not XFS-specific >anymore. I hope everyone else will pardon it: > > > I used 8 nfsd processes > >Just a note, Debian's nfs-kernel-server package has this as the default >via the following in /etc/init.d/nfs-kernel-server: > >RPCNFSDCOUNT=8 This is the redhat default as well as specified in /etc/rc.d/init.d/nfs > > and enlarged the buffer size from 64KB to 256KB. > > echo 262144 > /proc/sys/net/core/rmem_default > > echo 262144 > /proc/sys/net/core/rmem_max Note: The amount of buffers are shared between the nfsd processes, this will results in 8KB buffer per deamon. If you run 16 deamons this will mean you get 4KB per process. Change acordingly. >I read somewhere that this can lead to some not-so-nice situations when >left like this instead of the default. Would you be able to qualify this? This is noted from the NFS HowTo but they do not state what adverse results and under what version of the linux kernel. 2.4.9 might have this fixed but I just don't know. I have not run into funny behaviour yet and I am thinking of changing this option on the internet server gateway as well since that one has 3 networkcards and simultaneous activity on all. >I do remember reading somewhere that the recommended action will be to set >buffer sizes to 256KB, then start the NFS server, then revert to 64KB. I >was wondering if you'd have any information on that. That is what they say yes, I am just taking that risk. I have not experienced anomelies in the other sytems yet. I can imagine that if you are routing or packetfiltering this might lead to problems. >Now for something that I _think_ is a little more on-topic (but still not >quite XFS specific): > >I tweaked my /proc/sys/vm/bdflush a little, bringing down age_buffer to >100 jiffies (1 second) from 3000 jiffies (30 seconds). I did this in the >hopes that idle systems would flush dirty buffers sooner. I left >everything at their defaults, which are: > >nfract = 30 >ndirty = 64 >nrefill = 64 >nref_dirt = 256 >age_super = 60 > > o Did my bringing down age_buffer to 1 second make things too synchronous > that writes were significantly affected? > > o Will bringing up nfract allow the system to perform better? Or will > this simply chunk up disk writes and make the system less responsive > during those buffer flushes? > > o How will increasing or decreasing ndirty affect disk-intensive > operations like database updates or massive file transfers? > >Hopefully those (like Seth Mos, hehehe) with much more administrative >experience than I can help out and recommend tuning parameters? I thank >Seth for the NFS tuning tips. Maybe if he has some hidden bdflush (or even >buffermem) secrets, he can share them with the list? ;> Nope, to deep for me. Never changed any of those defaults. 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 Aug 31 04:48:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VBmIi16946 for linux-xfs-outgoing; Fri, 31 Aug 2001 04:48:18 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VBmDd16927 for ; Fri, 31 Aug 2001 04:48:13 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f7VBPkp17493; Fri, 31 Aug 2001 13:25:46 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpd559BKG; Fri Aug 31 13:25:36 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f7VBkQ420441; Fri, 31 Aug 2001 13:46:26 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id f7VBkQe05412; Fri, 31 Aug 2001 13:46:26 +0200 Date: Fri, 31 Aug 2001 13:46:26 +0200 From: Utz Lehmann To: james rich Cc: linux-xfs@oss.sgi.com Subject: Re: lost xfs filesystem on md0 Message-ID: <20010831134625.B2946@de.tecosim.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from james.rich@m.cc.utah.edu on Fri, Aug 31, 2001 at 12:50:22AM -0600 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Some disks dont reallocate badblocks interally on reads by default. Could you check ARRE (Auto Read Reallocation Enbld) is enabled (1): donner:/root # scsiinfo -a /dev/sda | grep ARRE Scsiinfo version 1.7(eowmob) ARRE 1 If its disabled (0) try enable it with scsi-config (a tcl/tk gui for scsiinfo). And run xfs_check/xfs_repair on the filesystem. And look at the growndefect list with scsiinfo. If its huge, you should replace the drive asap. hope that helps utz james rich [james.rich@m.cc.utah.edu] wrote: > Hi folks, > I've got two old SCSI disks configured in a raid0 setup on > /dev/md0. I had an unplanned power loss and now I get the following error > message: > > scsi0: ERROR on channel 0, id 6, lun 0, CDB: Read (10) 00 00 00 00 38 00 > 00 08 00 > Info fld=0x3f, Current sd08:21: sense key Medium Error > I/O error: dev 08:21, sector 31 > I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x30: > xfs_trans_read_buf > > The filesystem completes the mount process but no files show up > (/var/spool is gone now :( ). Does the above error indicate an error with > hardware or with xfs? In either case, is there some way to recover the > contents of /dev/md0? > > James Rich > james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Fri Aug 31 05:19:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VCJGq17543 for linux-xfs-outgoing; Fri, 31 Aug 2001 05:19:16 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VCJ9d17523 for ; Fri, 31 Aug 2001 05:19:09 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 6B8AC67040 for ; Fri, 31 Aug 2001 14:19:02 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Re: Problems compiling the xfs kernel MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Fri, 31 Aug 2001 14:19:02 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 14:19:04, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 14:19:04, Serialize complete at 31.08.2001 14:19:04, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 14:19:04, S/MIME Sign complete at 31.08.2001 14:19:04, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 31.08.2001 14:19:03, Serialize complete at 31.08.2001 14:19:03 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z22535_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z22535_boundary_sign Content-Type: text/plain; charset="us-ascii" On 31.08.2001 02:38:04 Keith Owens wrote: >On Thu, 30 Aug 2001 22:24:15 +0200, >"Michael Wahlbrink" wrote: >>I checked out today the xfs kernel from cvs (cvs -z3 checkout >linux-2.4-xfs). When I try to compile the kernel I get some >errors........ >>make[3]: Entering directory `/usr/src/linux/fs/ext2' >>gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes >>-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common >-fomit-frame-pointer >>-pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 >-c >>-o ialloc.o ialloc.c >>ialloc.c:308: unterminated macro call > >You have corrupt sources. rm -rf fs/ext2 and redo the CVS download. >If you have the bandwidth, erase everything and get a clean copy. Thanks that was the problen, checked it out once again and now it compiles without problems ;-) thanks michael ---------z22535_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDgzMTEyMTkwNFowIwYJKoZIhvcNAQkEMRYEFL+aoIiA1j0d/4pK igVucijRkzQGMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAZJeL71SV+rjELZuHdEWeWH/BpG2yzovm0val1i6afanmw5SNW8vf N8E5gQ49ArWosB4d6I4LCY9MkQ5N5X9wVT0STeHBe1idtnMrJwd5gUe/KLWlM1bG QIZBIqIkQ5vvL21OVP5bfLUo1tu5Zbcxq20Lw0YJRDy/SuY8H3iKhVMAAAAAAAAA AA== ---------z22535_boundary_sign-- From owner-linux-xfs@oss.sgi.com Fri Aug 31 05:35:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VCZnC17885 for linux-xfs-outgoing; Fri, 31 Aug 2001 05:35:49 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VCZkd17866 for ; Fri, 31 Aug 2001 05:35:46 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 31B3FC00FA2 for ; Fri, 31 Aug 2001 20:35:43 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 8FB4BC00FA1 for ; Fri, 31 Aug 2001 20:35:40 +0800 (PHT) Date: Fri, 31 Aug 2001 20:35:40 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Error compiling xfsdump package 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 everyone, Using a snapshot of the CVS just updated. Tested with both gcc-3.0.2-pre and gcc-2.94.4 on Debian (sid). I get the following when running "debian/rules build" for xfsdump: gcc -O1 -g -DNDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.3"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c -o mlog.o mlog.c mlog.c: In function `mlog_exit_flush': mlog.c:685: `STREAM_MAX' undeclared (first use in this function) mlog.c:685: (Each undeclared identifier is reported only once mlog.c:685: for each function it appears in.) mlog.c:685: warning: unused variable `pids' make[2]: *** [mlog.o] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.10-pre2-xfs-20010831/cmd/xfsdump' make: *** [built] Error 2 Hmm? --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Fri Aug 31 06:19:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VDJW218821 for linux-xfs-outgoing; Fri, 31 Aug 2001 06:19:32 -0700 Received: from mplspop3.mpls.uswest.net (mplspop3.mpls.uswest.net [204.147.80.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VDJTd18802 for ; Fri, 31 Aug 2001 06:19:29 -0700 Received: (qmail 92570 invoked from network); 31 Aug 2001 13:19:28 -0000 Received: from mplsdslgw15poolb213.mpls.uswest.net (HELO sgi.com) (63.229.197.213) by mplspop3.mpls.uswest.net with SMTP; 31 Aug 2001 13:19:28 -0000 Date: Fri, 31 Aug 2001 08:15:33 -0500 Message-ID: <3B8F8DF5.E53A7F9C@sgi.com> From: "Eric Sandeen" To: "Seth Mos" Cc: "Paul Schutte" , "XFS mailing list" 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 Subject: Re: Kernel hangs with mongo.pl benchmark. References: <4.3.2.7.2.20010831124708.03d1a8e8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > >3) mkfs.xfs -f -l size=8192b -i maxpct=90,size=2048 and mount -o logbufs=8 > >is a lethal > >combo ;-) > > It might be, maybe one of the crew an answer this one. You didn't say in what way it was "lethal" - but you've essentially made inodes that are 8X the default size, and allowed them to take up 90% of your space - inode-heavy, if you ask me. :) If you're creating MANY files very small files, you'd just be wasting a lot of space, I think. (although making the inodes bigger allows more data to live within the inode...) -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 Aug 31 06:23:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VDNPM18989 for linux-xfs-outgoing; Fri, 31 Aug 2001 06:23:25 -0700 Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VDNMd18970 for ; Fri, 31 Aug 2001 06:23:23 -0700 Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id PAA28015 for ; Fri, 31 Aug 2001 15:23:21 +0200 (MEST) Message-ID: <3B8F8FE3.3090809@dumballah.tvnet.hu> Date: Fri, 31 Aug 2001 15:23:47 +0200 From: Sipos Ferenc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: still gcc 3.01 problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! However in the latest cvs xfs_super.c was updated, kernel compilation produces the following error: standard input: Assembler messages: 1224: Error: suffix or operands invalid for 'bsf' Sorry if I seems to be impatient, I'd like to say only, that the line number has changed. Thx Paco From owner-linux-xfs@oss.sgi.com Fri Aug 31 08:19:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VFJp021373 for linux-xfs-outgoing; Fri, 31 Aug 2001 08:19:51 -0700 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 f7VFJmd21354 for ; Fri, 31 Aug 2001 08:19:48 -0700 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 f7VFPS820638 for ; Fri, 31 Aug 2001 08:25:28 -0700 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 KAA2819676 for ; Fri, 31 Aug 2001 10:18:27 -0500 (CDT) 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 KAA78162 for ; Fri, 31 Aug 2001 10:18:27 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7VFHf606801; Fri, 31 Aug 2001 10:17:41 -0500 Message-Id: <200108311517.f7VFHf606801@stout.americas.sgi.com> Date: Fri, 31 Aug 2001 10:17:41 -0500 From: Eric Sandeen Subject: TAKE - Fix xfsdump build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Aug 30 10:12:05 CST 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101997a cmd/xfsdump/dump/content.c 1.8 - Fix build : s/STREAM_SIMMAX/STREAM_MAX/, fix comments after #endif cmd/xfsdump/common/stream.c 1.2 cmd/xfsdump/common/main.c 1.7 cmd/xfsdump/common/cldmgr.c 1.2 cmd/xfsdump/restore/content.c 1.12 - Fix build : s/STREAM_SIMMAX/STREAM_MAX/ From owner-linux-xfs@oss.sgi.com Fri Aug 31 08:26:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VFQKx21584 for linux-xfs-outgoing; Fri, 31 Aug 2001 08:26:20 -0700 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 f7VFQId21565 for ; Fri, 31 Aug 2001 08:26:18 -0700 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 f7VFX0a04547 for ; Fri, 31 Aug 2001 08:33:00 -0700 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 KAA2749147 for ; Fri, 31 Aug 2001 10:24:57 -0500 (CDT) 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 KAA14705 for ; Fri, 31 Aug 2001 10:24:57 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7VFOBf06951; Fri, 31 Aug 2001 10:24:11 -0500 Message-Id: <200108311524.f7VFOBf06951@stout.americas.sgi.com> Date: Fri, 31 Aug 2001 10:24:11 -0500 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:101976b Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Aug 31 08:23:27 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:101999a linux/fs/xfs/xfsidbg.c - 1.163 - Merge irix6.5f:irix:101976b Add xquiesce function to look for non quiesced inodes linux/fs/xfs/xfs_iget.c - 1.147 - Merge irix6.5f:irix:101976b Remove cxfs quiesce calls, this is all handled from within cxfs now. linux/fs/xfs/xfs_cxfs.h - 1.8 - Merge irix6.5f:irix:101976b Remove prototypes for dead functions From owner-linux-xfs@oss.sgi.com Fri Aug 31 09:03:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VG3hA22295 for linux-xfs-outgoing; Fri, 31 Aug 2001 09:03:43 -0700 Received: from monkeyiq.dnsalias.org (CPE-203-45-215-234.qld.bigpond.net.au [203.45.215.234]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VG3dd22276 for ; Fri, 31 Aug 2001 09:03:39 -0700 Received: by monkeyiq.dnsalias.org id f7VG3PH17015 ; Sat, 1 Sep 2001 02:03:25 +1000 Date: Sat, 1 Sep 2001 02:03:25 +1000 Message-Id: <200108311603.f7VG3PH17015@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com Cc: monkeyiq@users.sourceforge.net Subject: Access to XFS EA from C++ (ferris) From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I recently read a paper comparing xfs, jfs, and reiserfs and the fact that XFS supports EA cought my eye. I have included XFS writable EA support in ferris as a result. http://witme.sourceforge.net/libferris.web/ Note that it would seem that the web site is mozilla only because reports I have are that IE doesn't render the pngs properly. I dont (& cant) use IE so can't tell. Just thought that some ppl here might be interested in a C++ interface to the EA on XFS. Maybe a link to the ferris site could be placed somewhere (the FAQ on lang bindings?) I might add more support to ferris for some of the other funky XFS stuff in the future too. Enjoy. ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Fri Aug 31 09:13:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VGDQl22562 for linux-xfs-outgoing; Fri, 31 Aug 2001 09:13:26 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VGDNd22543 for ; Fri, 31 Aug 2001 09:13:23 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA15217; Fri, 31 Aug 2001 18:13:22 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA22358; Fri, 31 Aug 2001 18:13:21 +0200 (CEST) Date: Fri, 31 Aug 2001 18:13:21 +0200 (CEST) From: Seth Mos To: monkeyiq cc: linux-xfs@oss.sgi.com Subject: Re: Access to XFS EA from C++ (ferris) In-Reply-To: <200108311603.f7VG3PH17015@monkeyiq.dnsalias.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 1 Sep 2001, monkeyiq wrote: > Hi, > I recently read a paper comparing xfs, jfs, and reiserfs > and the fact that XFS supports EA cought my eye. I have > included XFS writable EA support in ferris as a result. > > http://witme.sourceforge.net/libferris.web/ > > Note that it would seem that the web site is mozilla only > because reports I have are that IE doesn't render the pngs > properly. I dont (& cant) use IE so can't tell. > > Just thought that some ppl here might be interested in a > C++ interface to the EA on XFS. Maybe a link to the > ferris site could be placed somewhere (the FAQ on lang > bindings?) Will do. > I might add more support to ferris for some of the other > funky XFS stuff in the future too. Cool, people like having examples to start working upon. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 31 09:29:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VGTOH22859 for linux-xfs-outgoing; Fri, 31 Aug 2001 09:29:24 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VGTGd22838 for ; Fri, 31 Aug 2001 09:29:16 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 2BA5467040 for ; Fri, 31 Aug 2001 18:29:10 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Fri, 31 Aug 2001 18:29:09 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 18:29:11, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 18:29:11, Serialize complete at 31.08.2001 18:29:11, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 18:29:11, S/MIME Sign complete at 31.08.2001 18:29:11, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 31.08.2001 18:29:11 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z28895_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z28895_boundary_sign Content-Type: text/plain; charset="us-ascii" Hi all, Now I have successfull compiled my kernel (linux-2.4-xfs from cvs checked out today),....... I've made an 70Gig xfs filesystem on /dev/sda8 (mirrored 75Gig ibm disks on an 3ware escalade) with the standard settings (just an 'mkfs.xfs /dev/sda8') . Then I started some comy and tar-jops to get some data on this partition ;-) . And then suddenly I realize that some data was corrupt on the filesystem , and when I try to delete that data I get an segfault :-(( Here are the lines from '/var/log/messages': Aug 31 19:15:04 swan -- MARK -- Aug 31 19:20:08 swan kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Aug 31 19:20:08 swan kernel: printing eip: Aug 31 19:20:08 swan kernel: c01a8305 Aug 31 19:20:08 swan kernel: *pde = 00000000 Aug 31 19:20:08 swan kernel: Oops: 0000 Aug 31 19:20:08 swan kernel: CPU: 0 Aug 31 19:20:08 swan kernel: EIP: 0010:[xfs_iget+229/304] Aug 31 19:20:08 swan kernel: EFLAGS: 00010246 Aug 31 19:20:08 swan kernel: eax: 00000000 ebx: ffffffe8 ecx: cba73788 edx: c02a9bc0 Aug 31 19:20:08 swan kernel: esi: c290024c edi: ced2fc00 ebp: 00000000 esp: cc74be44 Aug 31 19:20:08 swan kernel: ds: 0018 es: 0018 ss: 0018 Aug 31 19:20:08 swan kernel: Process rm (pid: 819, stackpage=cc74b000) Aug 31 19:20:08 swan kernel: Stack: 0000000f c4be0bf8 00000000 00000008 c01bdecc ced2fc00 00000000 0d059992 Aug 31 19:20:08 swan kernel: 00000000 00000000 cc74bed4 00000000 00000000 c4be0c10 c4be0bf8 00000008 Aug 31 19:20:08 swan kernel: ce9a5a40 00000000 00000004 00000288 00000008 c01c2427 00000000 c4be0c10 Aug 31 19:20:08 swan kernel: Call Trace: [xfs_dir_lookup_int+300/672] [xfs_lookup+151/272] [linvfs_lookup+101/192] [real_lookup+83/192] [path_walk+1329/1888] Aug 31 19:20:08 swan kernel: [getname+93/160] [__user_walk+60/96] [sys_lstat64+22/112] [system_call+51/56] Aug 31 19:20:08 swan kernel: Aug 31 19:20:08 swan kernel: Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 74 any ideas , suggestions or help?? cu micha ---------z28895_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDgzMTE2MjkxMVowIwYJKoZIhvcNAQkEMRYEFDtEnb52MvVrF3Hi tiA7IFKz6zAfMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGApcqrCKhM9wPG+3foH25dvexIbzcvLLl7a9MACbt4CCkktIGbFRl9 IplDJ+wU2BVTPuyorW6K9jpfZXfHA5HiHcEEHGJ6+cRoumpd83P/Oa2NaD9pqcEo WZDw2BKAEeIhxnqAAdH+p4RePvt6+ir34fPACq9LOCQ9wgwwMWGTgBEAAAAAAAAA AA== ---------z28895_boundary_sign-- From owner-linux-xfs@oss.sgi.com Fri Aug 31 09:32:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VGWxN23014 for linux-xfs-outgoing; Fri, 31 Aug 2001 09:32:59 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VGWsd22993 for ; Fri, 31 Aug 2001 09:32:55 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15crDX-0004IZ-00; Fri, 31 Aug 2001 18:32:27 +0200 Message-ID: <3B8FBC1B.4AB635C3@it.up.ac.za> Date: Fri, 31 Aug 2001 18:32:27 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: <7317.999217877@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15crDX-0004IZ-00*T5gtUd8UHio* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, The the Dell 4400 hung again, but this time there's a kdb available. I have not worked with kdb before. I scanned the mailing lists and FAQ on kdb. I am sorry if this was mentioned earlier, but I could'nt find a way to search the archives. I am in the debugger by pressing Pause. What info must I gather for you guys and how do I capture it ? Paul Keith Owens wrote: > On Thu, 30 Aug 2001 18:49:18 +0200, > Paul Schutte wrote: > >Unfortunetly I can't get kdb to compile. > >It fails with error: > > > >/home/paul/test/linux-2.4-xfs/linux/include/linux/dis-asm.h:148: storage > >size of `display_endian' isn't known > >make[3]: *** [kdb_bt.o] Error 1 > > That field is defined in /usr/include/bfd.h. You need at least > binutils-2.9.5.0.22 to compile kdb. From owner-linux-xfs@oss.sgi.com Fri Aug 31 09:41:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VGfBA23209 for linux-xfs-outgoing; Fri, 31 Aug 2001 09:41:11 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VGf0d23189 for ; Fri, 31 Aug 2001 09:41:00 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA01384 for ; Fri, 31 Aug 2001 09:39:18 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2846480; Fri, 31 Aug 2001 11:39:43 -0500 (CDT) Received: from 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 LAA10737; Fri, 31 Aug 2001 11:39:34 -0500 (CDT) Message-ID: <3B8FBD98.DFA2B271@sgi.com> Date: Fri, 31 Aug 2001 11:38:48 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Schutte CC: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: <7317.999217877@kao2.melbourne.sgi.com> <3B8FBC1B.4AB635C3@it.up.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Paul Schutte wrote: > I am sorry if this was mentioned earlier, but I could'nt find a way to > search the archives. There's a link on the mailing list page, I believe. > I am in the debugger by pressing Pause. > > What info must I gather for you guys and how do I capture it ? So your machine hasn't crashed, it's just hung? If you type "ps" you can see all of the current processes, typing "btp will backtrace that process to see where it's at. The only completely reliable way to capture the output is by using KDB over a serial cable, but if your machine is still significantly alive, you can "set LOGGING=1" in kdb to log the output to disk, via syslog. -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 Aug 31 09:41:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VGfZj23327 for linux-xfs-outgoing; Fri, 31 Aug 2001 09:41:35 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VGfFd23236 for ; Fri, 31 Aug 2001 09:41:21 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f7VGevL06945; Fri, 31 Aug 2001 18:40:57 +0200 Date: Fri, 31 Aug 2001 18:40:57 +0200 From: Krzysztof Rusocki To: Michael Wahlbrink Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... Message-ID: <20010831184057.A6811@main.braxis.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from miw@propack-data.com on Fri, Aug 31, 2001 at 06:29:09PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Michael, Filter this output through `ksymoops' since already THAT is helpful for linux-xfs developers. Cheers, Krzysztof On Fri, Aug 31, 2001 at 06:29:09PM +0200, Michael Wahlbrink wrote: > Hi all, > Now I have successfull compiled my kernel (linux-2.4-xfs from cvs checked out today),....... I've made an 70Gig xfs filesystem on > /dev/sda8 (mirrored 75Gig ibm disks on an 3ware escalade) with the > standard settings (just an 'mkfs.xfs /dev/sda8') . Then I started some > comy and tar-jops to get some data on this partition ;-) . And then > suddenly I realize that some data was corrupt on the filesystem , and when > I try to delete that data I get an segfault :-(( > Here are the lines from '/var/log/messages': > > Aug 31 19:15:04 swan -- MARK -- > Aug 31 19:20:08 swan kernel: Unable to handle kernel NULL pointer > dereference at virtual address 00000152 > Aug 31 19:20:08 swan kernel: printing eip: > Aug 31 19:20:08 swan kernel: c01a8305 > Aug 31 19:20:08 swan kernel: *pde = 00000000 > Aug 31 19:20:08 swan kernel: Oops: 0000 > Aug 31 19:20:08 swan kernel: CPU: 0 > Aug 31 19:20:08 swan kernel: EIP: 0010:[xfs_iget+229/304] > Aug 31 19:20:08 swan kernel: EFLAGS: 00010246 > Aug 31 19:20:08 swan kernel: eax: 00000000 ebx: ffffffe8 ecx: cba73788 > edx: c02a9bc0 > Aug 31 19:20:08 swan kernel: esi: c290024c edi: ced2fc00 ebp: 00000000 > esp: cc74be44 > Aug 31 19:20:08 swan kernel: ds: 0018 es: 0018 ss: 0018 > Aug 31 19:20:08 swan kernel: Process rm (pid: 819, stackpage=cc74b000) > Aug 31 19:20:08 swan kernel: Stack: 0000000f c4be0bf8 00000000 00000008 > c01bdecc ced2fc00 00000000 0d059992 > Aug 31 19:20:08 swan kernel: 00000000 00000000 cc74bed4 00000000 > 00000000 c4be0c10 c4be0bf8 00000008 > Aug 31 19:20:08 swan kernel: ce9a5a40 00000000 00000004 00000288 > 00000008 c01c2427 00000000 c4be0c10 > Aug 31 19:20:08 swan kernel: Call Trace: [xfs_dir_lookup_int+300/672] > [xfs_lookup+151/272] [linvfs_lookup+101/192] [real_lookup+83/192] > [path_walk+1329/1888] > Aug 31 19:20:08 swan kernel: [getname+93/160] [__user_walk+60/96] > [sys_lstat64+22/112] [system_call+51/56] > Aug 31 19:20:08 swan kernel: > Aug 31 19:20:08 swan kernel: Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 > 01 00 00 f7 53 e8 74 > > any ideas , suggestions or help?? > cu > micha From owner-linux-xfs@oss.sgi.com Fri Aug 31 09:47:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VGlOQ23514 for linux-xfs-outgoing; Fri, 31 Aug 2001 09:47:24 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VGlLd23494 for ; Fri, 31 Aug 2001 09:47:21 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA28568; Fri, 31 Aug 2001 18:47:20 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA24526; Fri, 31 Aug 2001 18:47:20 +0200 (CEST) Date: Fri, 31 Aug 2001 18:47:20 +0200 (CEST) From: Seth Mos To: Paul Schutte cc: Keith Owens , XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. In-Reply-To: <3B8FBC1B.4AB635C3@it.up.ac.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 31 Aug 2001, Paul Schutte wrote: > Hi, > > The the Dell 4400 hung again, but this time there's a kdb available. > > I have not worked with kdb before. I scanned the mailing lists and FAQ on > kdb. > I am sorry if this was mentioned earlier, but I could'nt find a way to > search the archives. > > I am in the debugger by pressing Pause. > > What info must I gather for you guys and how do I capture it ? bt for backtrace and there is a save command. But don't now what that command was. I'll look it up when I finished my dinner (im in the middle of it). Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 31 10:18:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VHIad24042 for linux-xfs-outgoing; Fri, 31 Aug 2001 10:18:36 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VHIQd24023 for ; Fri, 31 Aug 2001 10:18:26 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 6EAAD67040 for ; Fri, 31 Aug 2001 19:18:19 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Fri, 31 Aug 2001 19:18:18 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 19:18:20, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 19:18:20, Serialize complete at 31.08.2001 19:18:20, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 19:18:20, S/MIME Sign complete at 31.08.2001 19:18:20, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 31.08.2001 19:18:20 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z27567_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z27567_boundary_sign Content-Type: text/plain; charset="us-ascii" On 31.08.2001 18:40:57 Krzysztof Rusocki wrote: >Hi Michael, > >Filter this output through `ksymoops' since already THAT >is helpful for linux-xfs developers. > >Cheers, >Krzysztof > > Hi, It's done, I hope I've made it the right way it was my first time ;-) so here is the output: hth micha ksymoops 2.4.1 on i686 2.4.10-pre2-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.10-pre2-xfs/ (default) -m /boot/System.map-2.4.10-pre2-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Aug 31 19:20:08 swan kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Aug 31 19:20:08 swan kernel: c01a8305 Aug 31 19:20:08 swan kernel: *pde = 00000000 Aug 31 19:20:08 swan kernel: Oops: 0000 Aug 31 19:20:08 swan kernel: CPU: 0 Aug 31 19:20:08 swan kernel: EIP: 0010:[xfs_iget+229/304] Aug 31 19:20:08 swan kernel: EFLAGS: 00010246 Aug 31 19:20:08 swan kernel: eax: 00000000 ebx: ffffffe8 ecx: cba73788 edx: c02a9bc0 Aug 31 19:20:08 swan kernel: esi: c290024c edi: ced2fc00 ebp: 00000000 esp: cc74be44 Aug 31 19:20:08 swan kernel: ds: 0018 es: 0018 ss: 0018 Aug 31 19:20:08 swan kernel: Process rm (pid: 819, stackpage=cc74b000) Aug 31 19:20:08 swan kernel: Stack: 0000000f c4be0bf8 00000000 00000008 c01bdecc ced2fc00 00000000 0d059992 Aug 31 19:20:08 swan kernel: 00000000 00000000 cc74bed4 00000000 00000000 c4be0c10 c4be0bf8 00000008 Aug 31 19:20:08 swan kernel: ce9a5a40 00000000 00000004 00000288 00000008 c01c2427 00000000 c4be0c10 Aug 31 19:20:08 swan kernel: Call Trace: [xfs_dir_lookup_int+300/672] [xfs_lookup+151/272] [linvfs_lookup+101/192] [real_lookup+83/192] [path_walk+1329/1888] Aug 31 19:20:08 swan kernel: Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 74 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 66 83 bb 6a 01 00 00 cmpw $0x0,0x16a(%ebx) Code; 00000007 Before first symbol 7: 00 Code; 00000008 Before first symbol 8: 75 10 jne 1a <_EIP+0x1a> 0000001a Before first symbol Code; 0000000a Before first symbol a: 80 a3 50 01 00 00 f7 andb $0xf7,0x150(%ebx) Code; 00000011 Before first symbol 11: 53 push %ebx Code; 00000012 Before first symbol 12: e8 74 00 00 00 call 8b <_EIP+0x8b> 0000008b Before first symbol 2 warnings issued. Results may not be reliable. ---------z27567_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDgzMTE3MTgyMFowIwYJKoZIhvcNAQkEMRYEFPZTjQH7kjc5e6Xa Bv+jfx4zwL6AMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGATvJixQfBxMmvAaoCCoCNxcY51pKlZcls2aTHu2BGwVQZXRAQ6Ekr dxai1Z24fDe5QXHbjGaG9KMMLtZRJEYJ7VkEPxcwOXXOYPjpTykPdOGeqxqgF/f/ 20+Jpoj6K0+tmtSIagNbHZ05TMH2fRmtjJboalP9PL9yeB14/2tsw/UAAAAAAAAA AA== ---------z27567_boundary_sign-- From owner-linux-xfs@oss.sgi.com Fri Aug 31 10:39:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VHdFx24509 for linux-xfs-outgoing; Fri, 31 Aug 2001 10:39:15 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VHdCd24490 for ; Fri, 31 Aug 2001 10:39:12 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id TAA09537; Fri, 31 Aug 2001 19:39:11 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA26934; Fri, 31 Aug 2001 19:39:10 +0200 (CEST) Date: Fri, 31 Aug 2001 19:39:10 +0200 (CEST) From: Seth Mos To: Michael Wahlbrink cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 31 Aug 2001, Michael Wahlbrink wrote: > On 31.08.2001 18:40:57 Krzysztof Rusocki wrote: > >Hi Michael, > > > >Filter this output through `ksymoops' since already THAT > >is helpful for linux-xfs developers. > > > >Cheers, > >Krzysztof > > > > > Hi, > It's done, I hope I've made it the right way it was my first time ;-) > so here is the output: > hth > micha It seems to be incomplete, it can't find modules info. The function is not translated. did you try it like this? ksymoops < oops.txt > ksymoops.txt Doesn't your machine have module support of do you have no modules loaded? My machines have a /proc/modules file. Weird. From owner-linux-xfs@oss.sgi.com Fri Aug 31 10:59:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VHxSO24932 for linux-xfs-outgoing; Fri, 31 Aug 2001 10:59:28 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VHx1d24908 for ; Fri, 31 Aug 2001 10:59:01 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15csPe-0005V9-00; Fri, 31 Aug 2001 19:49:02 +0200 Message-ID: <3B8FCE0E.7D18AFFB@it.up.ac.za> Date: Fri, 31 Aug 2001 19:49:02 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: <7317.999217877@kao2.melbourne.sgi.com> <3B8FBC1B.4AB635C3@it.up.ac.za> <3B8FBD98.DFA2B271@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15csPe-0005V9-00*KlU1RORxcBI* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Paul Schutte wrote: > > > I am sorry if this was mentioned earlier, but I could'nt find a way to > > search the archives. > > There's a link on the mailing list page, I believe. > > > I am in the debugger by pressing Pause. > > > > What info must I gather for you guys and how do I capture it ? > > So your machine hasn't crashed, it's just hung? If you type "ps" you > can see all of the current processes, typing "btp will > backtrace that process to see where it's at. > > The only completely reliable way to capture the output is by using KDB > over a serial cable, but if your machine is still significantly alive, > you can "set LOGGING=1" in kdb to log the output to disk, via syslog. > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. Hi, I did manage to capture some output. It logged everything to syslog. I then resumed with go and looked at the syslog. I mailed the syslog to myself. Good thing, because after the reboot there was some binary characters in the log where these output must have been. I btp 'ed the reiser_fract_tree process which I asumed caused the hang in the first place and a sync that I did. 301 and 302 are reiser_fract_tree processes. 426 is a sync that I have done Here is what I managed to capture. Paul Aug 31 17:49:48 debian kernel: 4c 0xc0132630 Aug 31 17:49:48 debian kernel: 0xf35cffa8 0xc013137e filp_close+0xb2 (0xf5f795a0, 0xf64fd0a0, 0xf35ce000) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01312cc 0xc013138c Aug 31 17:49:48 debian kernel: [0]more> Aug 31 17:49:48 debian kernel: 0xf35cffbc 0xc01313eb sys_close+0x5f (0x3, 0x804b090, 0xbffff6d8, 0x40014d34, 0xbffff6a8) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc013138c 0xc0131404 Aug 31 17:49:48 debian kernel: 0xc010707b system_call+0x33 Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 Aug 31 17:49:48 debian kernel: [0]kdb> btp 301 Aug 31 17:49:48 debian kernel: EBP EIP Function(args) Aug 31 17:49:48 debian kernel: 0xf35bfb00 0xc0111756 schedule+0x482 (0xf17ee800, 0x1) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 17:49:48 debian kernel: 0xf35bfb2c 0xc0105d44 __down+0x78 Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0105ccc 0xc0105da4 Aug 31 17:49:48 debian kernel: 0xf35bfb40 0xc0105eff __down_failed+0xb (0xf35bfbf0, 0xc01ab63e, 0xf17ee800, 0x5b6e000, 0xf7d31ea0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0105ef4 0xc0105f08 Aug 31 17:49:48 debian kernel: 0xc02e63fd stext_lock+0x43dd Aug 31 17:49:48 debian kernel: kernel .text.lock 0xc02e2020 0xc02e2020 0xc02eb9e0 Aug 31 17:49:48 debian kernel: 0xf35bfb48 0xc01ab533 _pagebuf_grab_lock+0x13 (0xf17ee800, 0x5b6e000) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01ab520 0xc01ab538 Aug 31 17:49:48 debian kernel: 0xf35bfbf0 0xc01ab63e _pagebuf_find_lockable_buffer+0x106 (0xf7d31ea0, 0x5b6e000, 0x2, 0x2000, 0x2201) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01ab538 0xc01ab724 Aug 31 17:49:48 debian kernel: 0xf35bfc20 0xc01ab755 _pagebuf_get_lockable_buffer+0x31 (0xf7d31ea0, 0x5b6e000, 0x2, 0x2000, 0x2201) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01ab724 0xc01ab800 Aug 31 17:49:48 debian kernel: 0xf35bfc5c 0xc01a7c51 pagebuf_get+0x91 (0xf7d31ea0, 0x5b6e000, 0x2, 0x2000, 0x2201) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 17:49:48 debian kernel: 0xf35bfc8c 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf5ad6c00, 0x0, 0xf5ad6d64, 0x102db70, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 17:49:48 debian kernel: 0xf35bfce8 0xc01e01f3 xfs_itobp+0xfb (0xf5ad6c00, 0x0, 0xc2a8bb98, 0xf35bfd2c, 0xf35bfd30) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 17:49:48 debian kernel: 0xf35bfd34 0xc01e2f43 xfs_iflush+0xab (0xc2a8bb98, 0x5) Aug 31 17:49:48 debian kernel: [0]more> Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 17:49:48 debian kernel: 0xf35bfd48 0xc01e415a xfs_inode_item_push+0x12 (0xc6099520) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 17:49:48 debian kernel: 0xf35bfd90 0xc01f451a xfs_trans_push_ail+0x136 (0xf5ad6c00, 0x11de, 0x22) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 17:49:48 debian kernel: 0xf35bfde4 0xc01e713f xlog_grant_push_ail+0x167 (0xf5ad6c00, 0x2c5b8) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 17:49:48 debian kernel: 0xf35bfe00 0xc01e64ff xfs_log_reserve+0x3f (0xf5ad6c00, 0x2abb8, 0x2, 0xf3fc34d4, 0x69) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 17:49:48 debian kernel: 0xf35bfe2c 0xc01f3422 xfs_trans_reserve+0x7a (0xf3fc34a0, 0x0, 0x2abb8, 0x0, 0x4) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 17:49:48 debian kernel: 0xf35bfeb4 0xc01e1c31 xfs_itruncate_finish+0x2c1 (0xf35bff10, 0xf2f0c5bc, 0x14c, 0x0, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e1970 0xc01e1c90 Aug 31 17:49:48 debian kernel: 0xf35bff3c 0xc01f9446 xfs_inactive_free_eofblocks+0x20a (0xf5ad6c00, 0xf2f0c5bc) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f923c 0xc01f9488 Aug 31 17:49:48 debian kernel: 0xf35bff54 0xc01f9a17 xfs_release+0x7f (0xf2f0c5d4) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f9998 0xc01f9a4c Aug 31 17:49:48 debian kernel: 0xf35bff60 0xc01ffe6a linvfs_release+0x26 (0xc7b5f060, 0xf5c23e00) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01ffe44 0xc01ffe70 Aug 31 17:49:48 debian kernel: 0xf35bff80 0xc013258d fput+0x41 (0xf5c23e00, 0xf64fd240, 0x0, 0xf5c23e00, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc013254c 0xc0132630 Aug 31 17:49:48 debian kernel: 0xf35bffa8 0xc013137e filp_close+0xb2 (0xf5c23e00, 0xf64fd240, 0xf35be000) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01312cc 0xc013138c Aug 31 17:49:48 debian kernel: [0]more> Aug 31 17:49:48 debian kernel: 0xf35bffbc 0xc01313eb sys_close+0x5f (0x3, 0x804b090, 0xbffff6d8, 0x40014d34, 0xbffff6a8) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc013138c 0xc0131404 Aug 31 17:49:48 debian kernel: 0xc010707b system_call+0x33 Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 Aug 31 17:49:48 debian kernel: [0]kdb> btp 303 Aug 31 17:49:48 debian kernel: EBP EIP Function(args) Aug 31 17:49:48 debian kernel: 0xf35874f8 0xc0111756 schedule+0x482 (0xf17ee800, 0x1) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 17:49:48 debian kernel: 0xf3587524 0xc0105d44 __down+0x78 Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0105ccc 0xc0105da4 Aug 31 17:49:48 debian kernel: 0xf3587538 0xc0105eff __down_failed+0xb (0xf35875e8, 0xc01ab63e, 0xf17ee800, 0x5b6e000, 0xf7d31ea0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0105ef4 0xc0105f08 Aug 31 17:49:48 debian kernel: 0xc02e63fd stext_lock+0x43dd Aug 31 17:49:48 debian kernel: kernel .text.lock 0xc02e2020 0xc02e2020 0xc02eb9e0 Aug 31 17:49:48 debian kernel: 0xf3587540 0xc01ab533 _pagebuf_grab_lock+0x13 (0xf17ee800, 0x5b6e000) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01ab520 0xc01ab538 Aug 31 17:49:48 debian kernel: 0xf35875e8 0xc01ab63e _pagebuf_find_lockable_buffer+0x106 (0xf7d31ea0, 0x5b6e000, 0x2, 0x2000, 0x2201) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01ab538 0xc01ab724 Aug 31 17:49:48 debian kernel: 0xf3587618 0xc01ab755 _pagebuf_get_lockable_buffer+0x31 (0xf7d31ea0, 0x5b6e000, 0x2, 0x2000, 0x2201) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01ab724 0xc01ab800 Aug 31 17:49:48 debian kernel: 0xf3587654 0xc01a7c51 pagebuf_get+0x91 (0xf7d31ea0, 0x5b6e000, 0x2, 0x2000, 0x2201) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 17:49:48 debian kernel: 0xf3587684 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf5ad6c00, 0x0, 0xf5ad6d64, 0x102db70, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 17:49:48 debian kernel: 0xf35876e0 0xc01e01f3 xfs_itobp+0xfb (0xf5ad6c00, 0x0, 0xc210a294, 0xf3587724, 0xf3587728) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 17:49:48 debian kernel: 0xf358772c 0xc01e2f43 xfs_iflush+0xab (0xc210a294, 0x5) Aug 31 17:49:48 debian kernel: [0]more> Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 17:49:48 debian kernel: 0xf3587740 0xc01e415a xfs_inode_item_push+0x12 (0xc6099498) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 17:49:48 debian kernel: 0xf3587788 0xc01f451a xfs_trans_push_ail+0x136 (0xf5ad6c00, 0x125e, 0x22) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 17:49:48 debian kernel: 0xf35877dc 0xc01e713f xlog_grant_push_ail+0x167 (0xf5ad6c00, 0x37f70, 0xf70df060, 0x1adb8, 0x2) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 17:49:48 debian kernel: 0xf358780c 0xc01e6534 xfs_log_reserve+0x74 (0xf5ad6c00, 0x1adb8, 0x2, 0xefbe10b4, 0x69) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 17:49:48 debian kernel: 0xf3587838 0xc01f3422 xfs_trans_reserve+0x7a (0xefbe1080, 0x0, 0x1adb8, 0x0, 0x4) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 17:49:48 debian kernel: 0xf3587964 0xc0204a9e xfs_strategy+0x3c2 (0xf091d888, 0x0, 0x0, 0x1000, 0x10002) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc02046dc 0xc0204fe8 Aug 31 17:49:48 debian kernel: 0xf358799c 0xc02031c3 linvfs_pb_bmap+0x6f (0xf095f280, 0x0, 0x0, 0x1000, 0xf35879ec) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0203154 0xc0203208 Aug 31 17:49:48 debian kernel: 0xf3587a0c 0xc01aa6a8 __pb_block_prepare_write_async+0xac (0xf095f280, 0xc1ce69a4, 0x0, 0x1000, 0x1) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01aa5fc 0xc01aa824 Aug 31 17:49:48 debian kernel: 0xf3587a5c 0xc01aa360 pagebuf_write_full_page+0xe0 (0xc1ce69a4, 0xc0203154) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01aa280 0xc01aa470 Aug 31 17:49:48 debian kernel: 0xf3587a6c 0xc020334d linvfs_write_full_page+0x11 (0xc1ce69a4) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc020333c 0xc020335c Aug 31 17:49:48 debian kernel: 0xf3587a94 0xc012b4a2 page_launder+0x336 (0x1f0, 0x1) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc012b16c 0xc012b954 Aug 31 17:49:48 debian kernel: [0]more> Aug 31 17:49:48 debian kernel: 0xf3587ab4 0xc012bc3a do_try_to_free_pages+0x52 (0x1f0, 0x1, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc012bbe8 0xc012bcb4 Aug 31 17:49:48 debian kernel: 0xf3587ac8 0xc012bdb0 try_to_free_pages+0x24 (0x1f0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc012bd8c 0xc012bdbc Aug 31 17:49:48 debian kernel: 0xf3587af8 0xc012c9c3 __alloc_pages+0x1d3 Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc012c7f0 0xc012ca78 Aug 31 17:49:48 debian kernel: 0xf3587b04 0xc012c7e7 _alloc_pages+0x1b Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc012c7cc 0xc012c7f0 Aug 31 17:49:48 debian kernel: 0xf3587b4c 0xc01a77ea _pagebuf_lookup_pages+0x18e (0xf17ee800, 0xf7d31ea8, 0x2201) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01a765c 0xc01a79f4 Aug 31 17:49:48 debian kernel: 0xf3587b7c 0xc01a7c7a pagebuf_get+0xba (0xf7d31ea0, 0x5b6e000, 0x2, 0x2000, 0x2201) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 17:49:48 debian kernel: 0xf3587bac 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf5ad6c00, 0x0, 0xf5ad6d64, 0x102db70, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 17:49:48 debian kernel: 0xf3587c08 0xc01e01f3 xfs_itobp+0xfb (0xf5ad6c00, 0x0, 0xc210a0c0, 0xf3587c4c, 0xf3587c50) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 17:49:48 debian kernel: 0xf3587c54 0xc01e2f43 xfs_iflush+0xab (0xc210a0c0, 0x5) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 17:49:48 debian kernel: 0xf3587c68 0xc01e415a xfs_inode_item_push+0x12 (0xc6099410) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 17:49:48 debian kernel: 0xf3587cb0 0xc01f451a xfs_trans_push_ail+0x136 (0xf5ad6c00, 0x11de, 0x22) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 17:49:48 debian kernel: 0xf3587d04 0xc01e713f xlog_grant_push_ail+0x167 (0xf5ad6c00, 0x5f470, 0xf70df060, 0x2de38, 0x2) Aug 31 17:49:48 debian kernel: [0]more> Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 17:49:48 debian kernel: 0xf3587d34 0xc01e6534 xfs_log_reserve+0x74 (0xf5ad6c00, 0x2de38, 0x2, 0xefbe4754, 0x69) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 17:49:48 debian kernel: 0xf3587d60 0xc01f3422 xfs_trans_reserve+0x7a (0xefbe4720, 0x44, 0x2de38, 0x0, 0x4) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 17:49:48 debian kernel: 0xf3587e24 0xc01fa1dd xfs_create+0x23d (0xf0c9532c, 0xf290327c, 0xf3587e70, 0x0, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f9fa0 0xc01fa9cc Aug 31 17:49:48 debian kernel: 0xf3587ee0 0xc02025a5 linvfs_common_cr+0x99 (0xf0c944a0, 0xf2903220, 0x81ed, 0x1, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc020250c 0xc0202730 Aug 31 17:49:48 debian kernel: 0xf3587efc 0xc0202748 linvfs_create+0x18 (0xf0c944a0, 0xf2903220, 0x81ed) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0202730 0xc020274c Aug 31 17:49:48 debian kernel: 0xf3587f24 0xc013e0fb vfs_create+0xb3 (0xf0c944a0, 0xf2903220, 0x1ed) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc013e048 0xc013e164 Aug 31 17:49:48 debian kernel: 0xf3587f58 0xc013e2d5 open_namei+0x171 (0xef5ab000, 0xc3, 0x1ed, 0xf3587f7c) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc013e164 0xc013e6d8 Aug 31 17:49:48 debian kernel: 0xf3587f98 0xc0130ee6 filp_open+0x3a (0xef5ab000, 0xc2, 0x1ff) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0130eac 0xc0130f08 Aug 31 17:49:48 debian kernel: 0xf3587fbc 0xc01311fe sys_open+0x42 (0xbffff394, 0xc2, 0x1ff, 0x40014d34, 0xbffff518) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01311bc 0xc01312b0 Aug 31 17:49:48 debian kernel: 0xc010707b system_call+0x33 Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 Aug 31 17:49:48 debian kernel: [0]kdb> btp 426 Aug 31 17:49:48 debian kernel: EBP EIP Function(args) Aug 31 17:49:48 debian kernel: 0xf0543ba4 0xc0111756 schedule+0x482 (0xf5ad3708) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 17:49:48 debian kernel: 0xf0543be0 0xc02091a1 _sv_wait+0xd1 (0xf5ad3708, 0xf70df104, 0x282, 0x0, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc02090d0 0xc02091bc Aug 31 17:49:48 debian kernel: 0xf0543c0c 0xc01e8139 xlog_grant_log_space+0x135 (0xf70df060, 0xf5ad3708, 0xf5ad6c00, 0x37f70, 0xf70df060) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e8004 0xc01e8294 Aug 31 17:49:48 debian kernel: 0xf0543c44 0xc01e653b xfs_log_reserve+0x7b (0xf5ad6c00, 0x1adb8, 0x2, 0xd6dcf0f4, 0x69) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 17:49:48 debian kernel: 0xf0543c70 0xc01f3422 xfs_trans_reserve+0x7a (0xd6dcf0c0, 0x0, 0x1adb8, 0x0, 0x4) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 17:49:48 debian kernel: 0xf0543d9c 0xc0204a9e xfs_strategy+0x3c2 (0xf43268a8, 0x0, 0x0, 0x1000, 0x10002) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc02046dc 0xc0204fe8 Aug 31 17:49:48 debian kernel: 0xf0543dd4 0xc02031c3 linvfs_pb_bmap+0x6f (0xf43249a0, 0x0, 0x0, 0x1000, 0xf0543e24) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0203154 0xc0203208 Aug 31 17:49:48 debian kernel: 0xf0543e44 0xc01aa6a8 __pb_block_prepare_write_async+0xac (0xf43249a0, 0xc1ddd4d4, 0x0, 0x1000, 0x1) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01aa5fc 0xc01aa824 Aug 31 17:49:48 debian kernel: 0xf0543e94 0xc01aa360 pagebuf_write_full_page+0xe0 (0xc1ddd4d4, 0xc0203154) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01aa280 0xc01aa470 Aug 31 17:49:48 debian kernel: 0xf0543ea4 0xc020334d linvfs_write_full_page+0x11 (0xc1ddd4d4) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc020333c 0xc020335c Aug 31 17:49:48 debian kernel: 0xf0543ebc 0xc0132835 _write_buffer+0x75 (0xe12d79e0, 0x0, 0x0) Aug 31 17:49:48 debian kernel: [0]more> Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01327c0 0xc013288c Aug 31 17:49:48 debian kernel: 0xf0543f68 0xc0132a47 write_some_buffers+0x9b (0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc01329ac 0xc0132b08 Aug 31 17:49:48 debian kernel: 0xf0543f78 0xc0132b23 write_unlocked_buffers+0x1b (0x0, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0132b08 0xc0132b48 Aug 31 17:49:48 debian kernel: 0xf0543f90 0xc0132c2d sync_buffers+0x15 (0x0, 0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0132c18 0xc0132c60 Aug 31 17:49:48 debian kernel: 0xf0543fb0 0xc0132d68 fsync_dev+0x18 (0x0) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0132d50 0xc0132dec Aug 31 17:49:48 debian kernel: 0xf0543fbc 0xc0132e0a sys_sync+0xa (0xbffffbd4, 0x2, 0x4012bc48, 0x1, 0xbffffbd4) Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0132e00 0xc0132e10 Aug 31 17:49:48 debian kernel: 0xc010707b system_call+0x33 Aug 31 17:49:48 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 From owner-linux-xfs@oss.sgi.com Fri Aug 31 11:12:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VICIN25320 for linux-xfs-outgoing; Fri, 31 Aug 2001 11:12:18 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VICBd25296 for ; Fri, 31 Aug 2001 11:12:11 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id E66E267040 for ; Fri, 31 Aug 2001 20:12:04 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Fri, 31 Aug 2001 20:12:03 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 20:12:05, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 20:12:05, Serialize complete at 31.08.2001 20:12:05, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 20:12:06, S/MIME Sign complete at 31.08.2001 20:12:06, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 31.08.2001 20:12:05 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z8842_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z8842_boundary_sign Content-Type: text/plain; charset="us-ascii" On 31.08.2001 19:39:10 Seth Mos wrote: >On Fri, 31 Aug 2001, Michael Wahlbrink wrote: > >> On 31.08.2001 18:40:57 Krzysztof Rusocki wrote: >> >Hi Michael, >> > >> >Filter this output through `ksymoops' since already THAT >> >is helpful for linux-xfs developers. >> > >> >Cheers, >> >Krzysztof >> > >> > >> Hi, >> It's done, I hope I've made it the right way it was my first time ;-) >> so here is the output: >> hth >> micha > >It seems to be incomplete, it can't find modules info. The function is >not translated. did you try it like this? >ksymoops < oops.txt > ksymoops.txt > >Doesn't your machine have module support of do you have no modules >loaded? >My machines have a /proc/modules file. Weird. Hi, I have a kernel with module support, but actually no compiled modules (will come later if the fs is working properly), so i think that it is ok that ksymoops cries about my modules (or not). my command was ksymoops oops.txt >output.txt (not the right way? should I call it your way again? I'm a newbie in debugging things....... so tell it to me). my /proc/modules is empty! hth micha ---------z8842_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDgzMTE4MTIwNlowIwYJKoZIhvcNAQkEMRYEFAADw4/+iwe3bksL F0CK0bSW4mUeMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAUZ2h2ajGJGMnTFXdurszttlp8z77zYXf+ST5IZejJiSVz/BtzQBp oPTEAb6BQ2x6Ba2ytDCgS1ykvHSR8Fs+okxus7Y1fPPNXTrwqNQ35KH8HYmeFMiX clt9iCc9AaENxNoMXWTDXvl5xDuDBtKV2+aOlecaHicBDEUIxlL1SaUAAAAAAAAA AA== ---------z8842_boundary_sign-- From owner-linux-xfs@oss.sgi.com Fri Aug 31 11:34:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VIYqI25873 for linux-xfs-outgoing; Fri, 31 Aug 2001 11:34:52 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VIYnd25847 for ; Fri, 31 Aug 2001 11:34:49 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA19378; Fri, 31 Aug 2001 20:34:48 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id UAA29354; Fri, 31 Aug 2001 20:34:48 +0200 (CEST) Date: Fri, 31 Aug 2001 20:34:48 +0200 (CEST) From: Seth Mos To: Michael Wahlbrink cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 31 Aug 2001, Michael Wahlbrink wrote: > On 31.08.2001 19:39:10 Seth Mos wrote: > >On Fri, 31 Aug 2001, Michael Wahlbrink wrote: > >It seems to be incomplete, it can't find modules info. The function is > >not translated. did you try it like this? > >ksymoops < oops.txt > ksymoops.txt > > > >Doesn't your machine have module support of do you have no modules > >loaded? > >My machines have a /proc/modules file. Weird. > Hi, > I have a kernel with module support, but actually no compiled modules > (will come later if the fs is working properly), so i think that it is ok > that ksymoops cries about my modules (or not). > my command was ksymoops oops.txt >output.txt (not the right way? should I > call it your way again? I'm a newbie in debugging things....... so tell it > to me). You did it right, it should be fine. > my /proc/modules is empty! No modules loaded I guess :-) Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 31 12:50:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VJoB727664 for linux-xfs-outgoing; Fri, 31 Aug 2001 12:50:11 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VJmdd27619 for ; Fri, 31 Aug 2001 12:48:40 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15cuGy-0007Hm-00; Fri, 31 Aug 2001 21:48:12 +0200 Message-ID: <3B8FE9FC.6CAAEA15@it.up.ac.za> Date: Fri, 31 Aug 2001 21:48:12 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: <7317.999217877@kao2.melbourne.sgi.com> <3B8FBC1B.4AB635C3@it.up.ac.za> <3B8FBD98.DFA2B271@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15cuGy-0007Hm-00*AFKJShdfFtU* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Here is another one. I have included the traces of all 6 the reiser_fract_tr kswapd kreclaimd bdflush kupdated pagebuf_daemon Paul kswapd Aug 31 21:08:16 debian kernel: [0]kdb> btp 4 Aug 31 21:08:16 debian kernel: EBP EIP Function(args) Aug 31 21:08:16 debian kernel: 0xf7f51a14 0xc0111756 schedule+0x482 (0xd44468e0, 0x1) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:08:16 debian kernel: 0xf7f51a40 0xc0105d44 __down+0x78 Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc0105ccc 0xc0105da4 Aug 31 21:08:16 debian kernel: 0xf7f51a54 0xc0105eff __down_failed+0xb (0xf7f51b04, 0xc01ab63e, 0xd44468e0, 0x43e4e000, 0xf7d31ea0) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc0105ef4 0xc0105f08 Aug 31 21:08:16 debian kernel: 0xc02e676d stext_lock+0x43dd Aug 31 21:08:16 debian kernel: kernel .text.lock 0xc02e2390 0xc02e2390 0xc02ebd60 Aug 31 21:08:16 debian kernel: 0xf7f51a5c 0xc01ab533 _pagebuf_grab_lock+0x13 (0xd44468e0, 0x43e4e000) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01ab520 0xc01ab538 Aug 31 21:08:16 debian kernel: 0xf7f51b04 0xc01ab63e _pagebuf_find_lockable_buffer+0x106 (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01ab538 0xc01ab724 Aug 31 21:08:16 debian kernel: 0xf7f51b34 0xc01ab755 _pagebuf_get_lockable_buffer+0x31 (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01ab724 0xc01ab800 Aug 31 21:08:16 debian kernel: 0xf7f51b70 0xc01a7c51 pagebuf_get+0x91 (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 21:08:16 debian kernel: 0xf7f51ba0 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf6404400, 0x0, 0xf6404564, 0x121f270, 0x0) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 21:08:16 debian kernel: 0xf7f51bfc 0xc01e01f3 xfs_itobp+0xfb (0xf6404400, 0x0, 0xccb7c890, 0xf7f51c40, 0xf7f51c44) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 21:08:16 debian kernel: 0xf7f51c48 0xc01e2f43 xfs_iflush+0xab (0xccb7c890, 0x5) Aug 31 21:08:16 debian kernel: [0]more> Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 21:08:16 debian kernel: 0xf7f51c5c 0xc01e415a xfs_inode_item_push+0x12 (0xe6ccb698) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 21:08:16 debian kernel: 0xf7f51ca4 0xc01f451a xfs_trans_push_ail+0x136 (0xf6404400, 0x8bc, 0x26) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 21:08:16 debian kernel: 0xf7f51cf8 0xc01e713f xlog_grant_push_ail+0x167 (0xf6404400, 0x37f70, 0xf70e6660, 0x1adb8, 0x2) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 21:08:16 debian kernel: 0xf7f51d28 0xc01e6534 xfs_log_reserve+0x74 (0xf6404400, 0x1adb8, 0x2, 0xc0bbc254, 0x69) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 21:08:16 debian kernel: 0xf7f51d54 0xc01f3422 xfs_trans_reserve+0x7a (0xc0bbc220, 0x0, 0x1adb8, 0x0, 0x4) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 21:08:16 debian kernel: 0xf7f51e80 0xc0204a9e xfs_strategy+0x3c2 (0xcc059dc4, 0x0, 0x0, 0x1000, 0x10002) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc02046dc 0xc0204fe8 Aug 31 21:08:16 debian kernel: 0xf7f51eb8 0xc02031c3 linvfs_pb_bmap+0x6f (0xf45a6240, 0x0, 0x0, 0x1000, 0xf7f51f08) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc0203154 0xc0203208 Aug 31 21:08:16 debian kernel: 0xf7f51f28 0xc01aa6a8 __pb_block_prepare_write_async+0xac (0xf45a6240, 0xc1deeaf0, 0x0, 0x1000, 0x1) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01aa5fc 0xc01aa824 Aug 31 21:08:16 debian kernel: 0xf7f51f78 0xc01aa360 pagebuf_write_full_page+0xe0 (0xc1deeaf0, 0xc0203154) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01aa280 0xc01aa470 Aug 31 21:08:16 debian kernel: 0xf7f51f88 0xc020334d linvfs_write_full_page+0x11 (0xc1deeaf0) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc020333c 0xc020335c Aug 31 21:08:16 debian kernel: 0xf7f51fb0 0xc012b4a2 page_launder+0x336 (0x1c0, 0x1) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc012b16c 0xc012b954 Aug 31 21:08:16 debian kernel: [0]more> Aug 31 21:08:16 debian kernel: 0xf7f51fd0 0xc012bc3a do_try_to_free_pages+0x52 (0x1c0, 0x1) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc012bbe8 0xc012bcb4 Aug 31 21:08:16 debian kernel: 0xf7f51fec 0xc012bd21 kswapd+0x6d Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc012bcb4 0xc012bd64 Aug 31 21:08:16 debian kernel: 0xc01057b7 kernel_thread+0x23 Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc0105794 0xc01057cc --------------------------------------------------------------------------------------------------------------------- kreclaimd Aug 31 21:08:16 debian kernel: [0]kdb> btp 5 Aug 31 21:08:16 debian kernel: EBP EIP Function(args) Aug 31 21:08:16 debian kernel: 0xf7f4ffac 0xc0111756 schedule+0x482 (0xc03f85a0) Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:08:16 debian kernel: 0xf7f4ffcc 0xc0111d19 interruptible_sleep_on+0x4d Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc0111ccc 0xc0111d3c Aug 31 21:08:16 debian kernel: 0xf7f4ffec 0xc012be06 kreclaimd+0x4a Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc012bdbc 0xc012be84 Aug 31 21:08:16 debian kernel: 0xc01057b7 kernel_thread+0x23 Aug 31 21:08:16 debian kernel: kernel .text 0xc0100000 0xc0105794 0xc01057cc Aug 31 21:08:16 debian kernel: [0]kdb> go ---------------------------------------------------------------------------------------------------------------------------- bdflush Aug 31 21:10:18 debian kernel: [0]kdb> btp 6 Aug 31 21:10:18 debian kernel: EBP EIP Function(args) Aug 31 21:10:18 debian kernel: 0xf7f4dfb8 0xc0111756 schedule+0x482 (0xf7f4c000) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:10:18 debian kernel: 0xf7f4dfd8 0xc0111d19 interruptible_sleep_on+0x4d (0x10f00) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0111ccc 0xc0111d3c Aug 31 21:10:18 debian kernel: 0xf7f4dfec 0xc0135e23 bdflush+0xc7 Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0135d5c 0xc0135e28 Aug 31 21:10:18 debian kernel: 0xc01057b7 kernel_thread+0x23 Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0105794 0xc01057cc ---------------------------------------------------------------------------------------------------------------------------------- kupdated Aug 31 21:10:18 debian kernel: [0]kdb> btp 7 Aug 31 21:10:18 debian kernel: EBP EIP Function(args) Aug 31 21:10:18 debian kernel: 0xf7f4b98c 0xc0111756 schedule+0x482 (0xd44466a0, 0x1) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:10:18 debian kernel: 0xf7f4b9b8 0xc0105d44 __down+0x78 Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0105ccc 0xc0105da4 Aug 31 21:10:18 debian kernel: 0xf7f4b9cc 0xc0105eff __down_failed+0xb (0xf7f4ba7c, 0xc01ab63e, 0xd44466a0, 0x5902000, 0xf7d31ea0) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0105ef4 0xc0105f08 Aug 31 21:10:18 debian kernel: 0xc02e676d stext_lock+0x43dd Aug 31 21:10:18 debian kernel: kernel .text.lock 0xc02e2390 0xc02e2390 0xc02ebd60 Aug 31 21:10:18 debian kernel: 0xf7f4b9d4 0xc01ab533 _pagebuf_grab_lock+0x13 (0xd44466a0, 0x5902000) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01ab520 0xc01ab538 Aug 31 21:10:18 debian kernel: 0xf7f4ba7c 0xc01ab63e _pagebuf_find_lockable_buffer+0x106 (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01ab538 0xc01ab724 Aug 31 21:10:18 debian kernel: 0xf7f4baac 0xc01ab755 _pagebuf_get_lockable_buffer+0x31 (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01ab724 0xc01ab800 Aug 31 21:10:18 debian kernel: 0xf7f4bae8 0xc01a7c51 pagebuf_get+0x91 (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 21:10:18 debian kernel: 0xf7f4bb18 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf6404400, 0x0, 0xf6404564, 0x102c810, 0x0) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 21:10:18 debian kernel: 0xf7f4bb74 0xc01e01f3 xfs_itobp+0xfb (0xf6404400, 0x0, 0xcc9d569c, 0xf7f4bbb8, 0xf7f4bbbc) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 21:10:18 debian kernel: 0xf7f4bbc0 0xc01e2f43 xfs_iflush+0xab (0xcc9d569c, 0x5) Aug 31 21:10:18 debian kernel: [0]more> Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 21:10:18 debian kernel: 0xf7f4bbd4 0xc01e415a xfs_inode_item_push+0x12 (0xc4dfe4b8) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 21:10:18 debian kernel: 0xf7f4bc1c 0xc01f451a xfs_trans_push_ail+0x136 (0xf6404400, 0x87c, 0x26) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 21:10:18 debian kernel: 0xf7f4bc70 0xc01e713f xlog_grant_push_ail+0x167 (0xf6404400, 0x37f70, 0xf70e6660, 0x1adb8, 0x2) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 21:10:18 debian kernel: 0xf7f4bca0 0xc01e6534 xfs_log_reserve+0x74 (0xf6404400, 0x1adb8, 0x2, 0xc0bbc4d4, 0x69) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 21:10:18 debian kernel: 0xf7f4bccc 0xc01f3422 xfs_trans_reserve+0x7a (0xc0bbc4a0, 0x0, 0x1adb8, 0x0, 0x4) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 21:10:18 debian kernel: 0xf7f4bdf8 0xc0204a9e xfs_strategy+0x3c2 (0xc523c0d8, 0x0, 0x0, 0x1000, 0x10002) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc02046dc 0xc0204fe8 Aug 31 21:10:18 debian kernel: 0xf7f4be30 0xc02031c3 linvfs_pb_bmap+0x6f (0xe8fbdc20, 0x0, 0x0, 0x1000, 0xf7f4be80) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0203154 0xc0203208 Aug 31 21:10:18 debian kernel: 0xf7f4bea0 0xc01aa6a8 __pb_block_prepare_write_async+0xac (0xe8fbdc20, 0xc1a53b40, 0x0, 0x1000, 0x1) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01aa5fc 0xc01aa824 Aug 31 21:10:18 debian kernel: 0xf7f4bef0 0xc01aa360 pagebuf_write_full_page+0xe0 (0xc1a53b40, 0xc0203154) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01aa280 0xc01aa470 Aug 31 21:10:18 debian kernel: 0xf7f4bf00 0xc020334d linvfs_write_full_page+0x11 (0xc1a53b40) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc020333c 0xc020335c Aug 31 21:10:18 debian kernel: 0xf7f4bf18 0xc0132835 _write_buffer+0x75 (0xe6d67560, 0x0, 0xf7f4a000) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01327c0 0xc013288c Aug 31 21:10:18 debian kernel: [0]more> Aug 31 21:10:18 debian kernel: 0xf7f4bfc4 0xc0132a47 write_some_buffers+0x9b (0x0) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01329ac 0xc0132b08 Aug 31 21:10:18 debian kernel: 0xf7f4bfd4 0xc0135c5f sync_old_buffers+0x77 (0x10f00) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0135be8 0xc0135c98 Aug 31 21:10:18 debian kernel: 0xf7f4bfec 0xc0135f51 kupdate+0x129 Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0135e28 0xc0135f58 Aug 31 21:10:18 debian kernel: 0xc01057b7 kernel_thread+0x23 Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0105794 0xc01057cc ---------------------------------------------------------------------------------------------------------------------------- pagebuf_daemon Aug 31 21:10:18 debian kernel: [0]kdb> btp 8 Aug 31 21:10:18 debian kernel: EBP EIP Function(args) Aug 31 21:10:18 debian kernel: 0xf7f43f84 0xc0111756 schedule+0x482 (0xf33edce0) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:10:18 debian kernel: 0xf7f43fa4 0xc0111d19 interruptible_sleep_on+0x4d (0xf7f43fd8, 0xf7f43fd8, 0xf00, 0xc1ef9f9c, 0xc0105000) Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0111ccc 0xc0111d3c Aug 31 21:10:18 debian kernel: 0xf7f43fec 0xc01a91ff pagebuf_daemon+0xdb Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc01a9124 0xc01a939c Aug 31 21:10:18 debian kernel: 0xc01057b7 kernel_thread+0x23 Aug 31 21:10:18 debian kernel: kernel .text 0xc0100000 0xc0105794 0xc01057cc Aug 31 21:10:18 debian kernel: [0]kdb> go -------------------------------------------------------------------------------------------------------------------------- reiser_fract_tr: Aug 31 21:12:28 debian kernel: [0]kdb> btp 253 Aug 31 21:12:28 debian kernel: EBP EIP Function(args) Aug 31 21:12:28 debian kernel: 0xf3b17a20 0xc0111756 schedule+0x482 (0xd44468e0, 0x1) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:12:28 debian kernel: 0xf3b17a4c 0xc0105d44 __down+0x78 Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc0105ccc 0xc0105da4 Aug 31 21:12:28 debian kernel: 0xf3b17a60 0xc0105eff __down_failed+0xb (0xf3b17b10, 0xc01ab63e, 0xd44468e0, 0x43e4e000, 0xf7d31ea0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc0105ef4 0xc0105f08 Aug 31 21:12:28 debian kernel: 0xc02e676d stext_lock+0x43dd Aug 31 21:12:28 debian kernel: kernel .text.lock 0xc02e2390 0xc02e2390 0xc02ebd60 Aug 31 21:12:28 debian kernel: 0xf3b17a68 0xc01ab533 _pagebuf_grab_lock+0x13 (0xd44468e0, 0x43e4e000) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01ab520 0xc01ab538 Aug 31 21:12:28 debian kernel: 0xf3b17b10 0xc01ab63e _pagebuf_find_lockable_buffer+0x106 (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01ab538 0xc01ab724 Aug 31 21:12:28 debian kernel: 0xf3b17b40 0xc01ab755 _pagebuf_get_lockable_buffer+0x31 (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01ab724 0xc01ab800 Aug 31 21:12:28 debian kernel: 0xf3b17b7c 0xc01a7c51 pagebuf_get+0x91 (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 21:12:28 debian kernel: 0xf3b17bac 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf6404400, 0x0, 0xf6404564, 0x121f270, 0x0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 21:12:28 debian kernel: 0xf3b17c08 0xc01e01f3 xfs_itobp+0xfb (0xf6404400, 0x0, 0xccb7ca64, 0xf3b17c4c, 0xf3b17c50) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 21:12:28 debian kernel: 0xf3b17c54 0xc01e2f43 xfs_iflush+0xab (0xccb7ca64, 0x5) Aug 31 21:12:28 debian kernel: [0]more> Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 21:12:28 debian kernel: 0xf3b17c68 0xc01e415a xfs_inode_item_push+0x12 (0xe6ccb720) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 21:12:28 debian kernel: 0xf3b17cb0 0xc01f451a xfs_trans_push_ail+0x136 (0xf6404400, 0x8bc, 0x26) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 21:12:28 debian kernel: 0xf3b17d04 0xc01e713f xlog_grant_push_ail+0x167 (0xf6404400, 0x5f470, 0xf70e6660, 0x2de38, 0x2) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 21:12:28 debian kernel: 0xf3b17d34 0xc01e6534 xfs_log_reserve+0x74 (0xf6404400, 0x2de38, 0x2, 0xdff3ed94, 0x69) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 21:12:28 debian kernel: 0xf3b17d60 0xc01f3422 xfs_trans_reserve+0x7a (0xdff3ed60, 0x44, 0x2de38, 0x0, 0x4) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 21:12:28 debian kernel: 0xf3b17e24 0xc01fa1dd xfs_create+0x23d (0xd9bfb9bc, 0xd6fc6efc, 0xf3b17e70, 0x0, 0x0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f9fa0 0xc01fa9cc Aug 31 21:12:28 debian kernel: 0xf3b17ee0 0xc02025a5 linvfs_common_cr+0x99 (0xc9fcb5e0, 0xd6fc6ea0, 0x81ed, 0x1, 0x0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc020250c 0xc0202730 Aug 31 21:12:28 debian kernel: 0xf3b17efc 0xc0202748 linvfs_create+0x18 (0xc9fcb5e0, 0xd6fc6ea0, 0x81ed) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc0202730 0xc020274c Aug 31 21:12:28 debian kernel: 0xf3b17f24 0xc013e0fb vfs_create+0xb3 (0xc9fcb5e0, 0xd6fc6ea0, 0x1ed) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc013e048 0xc013e164 Aug 31 21:12:28 debian kernel: 0xf3b17f58 0xc013e2d5 open_namei+0x171 (0xccf8d000, 0xc3, 0x1ed, 0xf3b17f7c) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc013e164 0xc013e6d8 Aug 31 21:12:28 debian kernel: 0xf3b17f98 0xc0130ee6 filp_open+0x3a (0xccf8d000, 0xc2, 0x1ff) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc0130eac 0xc0130f08 Aug 31 21:12:28 debian kernel: [0]more> Aug 31 21:12:28 debian kernel: 0xf3b17fbc 0xc01311fe sys_open+0x42 (0xbffff524, 0xc2, 0x1ff, 0x40014d34, 0xbffff6a8) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01311bc 0xc01312b0 Aug 31 21:12:28 debian kernel: 0xc010707b system_call+0x33 Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 ----------------------------------------------------------------------------------------------------------------------- reiser_fract_tr Aug 31 21:12:28 debian kernel: [0]kdb> btp 254 Aug 31 21:12:28 debian kernel: EBP EIP Function(args) Aug 31 21:12:28 debian kernel: 0xf3afb5d8 0xc0111756 schedule+0x482 (0xd44468e0, 0x1) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:12:28 debian kernel: 0xf3afb604 0xc0105d44 __down+0x78 Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc0105ccc 0xc0105da4 Aug 31 21:12:28 debian kernel: 0xf3afb618 0xc0105eff __down_failed+0xb (0xf3afb6c8, 0xc01ab63e, 0xd44468e0, 0x43e4e000, 0xf7d31ea0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc0105ef4 0xc0105f08 Aug 31 21:12:28 debian kernel: 0xc02e676d stext_lock+0x43dd Aug 31 21:12:28 debian kernel: kernel .text.lock 0xc02e2390 0xc02e2390 0xc02ebd60 Aug 31 21:12:28 debian kernel: 0xf3afb620 0xc01ab533 _pagebuf_grab_lock+0x13 (0xd44468e0, 0x43e4e000) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01ab520 0xc01ab538 Aug 31 21:12:28 debian kernel: 0xf3afb6c8 0xc01ab63e _pagebuf_find_lockable_buffer+0x106 (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01ab538 0xc01ab724 Aug 31 21:12:28 debian kernel: 0xf3afb6f8 0xc01ab755 _pagebuf_get_lockable_buffer+0x31 (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01ab724 0xc01ab800 Aug 31 21:12:28 debian kernel: 0xf3afb734 0xc01a7c51 pagebuf_get+0x91 (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 21:12:28 debian kernel: 0xf3afb764 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf6404400, 0x0, 0xf6404564, 0x121f270, 0x0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 21:12:28 debian kernel: 0xf3afb7c0 0xc01e01f3 xfs_itobp+0xfb (0xf6404400, 0x0, 0xccb7c6bc, 0xf3afb804, 0xf3afb808) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 21:12:28 debian kernel: 0xf3afb80c 0xc01e2f43 xfs_iflush+0xab (0xccb7c6bc, 0x5) Aug 31 21:12:28 debian kernel: [0]more> Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 21:12:28 debian kernel: 0xf3afb820 0xc01e415a xfs_inode_item_push+0x12 (0xe6ccb610) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 21:12:28 debian kernel: 0xf3afb868 0xc01f451a xfs_trans_push_ail+0x136 (0xf6404400, 0x8fc, 0x26) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 21:12:28 debian kernel: 0xf3afb8bc 0xc01e713f xlog_grant_push_ail+0x167 (0xf6404400, 0x37f70, 0xf70e6660, 0x1adb8, 0x2) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 21:12:28 debian kernel: 0xf3afb8ec 0xc01e6534 xfs_log_reserve+0x74 (0xf6404400, 0x1adb8, 0x2, 0xdff3e894, 0x69) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 21:12:28 debian kernel: 0xf3afb918 0xc01f3422 xfs_trans_reserve+0x7a (0xdff3e860, 0x0, 0x1adb8, 0x0, 0x4) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 21:12:28 debian kernel: 0xf3afba44 0xc0204a9e xfs_strategy+0x3c2 (0xcc07228c, 0x0, 0x0, 0x1000, 0x10002) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc02046dc 0xc0204fe8 Aug 31 21:12:28 debian kernel: 0xf3afba7c 0xc02031c3 linvfs_pb_bmap+0x6f (0xf4744da0, 0x0, 0x0, 0x1000, 0xf3afbacc) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc0203154 0xc0203208 Aug 31 21:12:28 debian kernel: 0xf3afbaec 0xc01aa6a8 __pb_block_prepare_write_async+0xac (0xf4744da0, 0xc1df28d4, 0x0, 0x1000, 0x1) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01aa5fc 0xc01aa824 Aug 31 21:12:28 debian kernel: 0xf3afbb3c 0xc01aa360 pagebuf_write_full_page+0xe0 (0xc1df28d4, 0xc0203154) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01aa280 0xc01aa470 Aug 31 21:12:28 debian kernel: 0xf3afbb4c 0xc020334d linvfs_write_full_page+0x11 (0xc1df28d4) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc020333c 0xc020335c Aug 31 21:12:28 debian kernel: 0xf3afbb74 0xc012b4a2 page_launder+0x336 (0x1f0, 0x1) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc012b16c 0xc012b954 Aug 31 21:12:28 debian kernel: [0]more> Aug 31 21:12:28 debian kernel: 0xf3afbb94 0xc012bc3a do_try_to_free_pages+0x52 (0x1f0, 0x1, 0x0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc012bbe8 0xc012bcb4 Aug 31 21:12:28 debian kernel: 0xf3afbba8 0xc012bdb0 try_to_free_pages+0x24 (0x1f0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc012bd8c 0xc012bdbc Aug 31 21:12:28 debian kernel: 0xf3afbbd8 0xc012c9c3 __alloc_pages+0x1d3 Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc012c7f0 0xc012ca78 Aug 31 21:12:28 debian kernel: 0xf3afbbe4 0xc012c7e7 _alloc_pages+0x1b Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc012c7cc 0xc012c7f0 Aug 31 21:12:28 debian kernel: 0xf3afbc2c 0xc01a77ea _pagebuf_lookup_pages+0x18e (0xd44468e0, 0xf7d31ea8, 0x2201) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01a765c 0xc01a79f4 Aug 31 21:12:28 debian kernel: 0xf3afbc5c 0xc01a7c7a pagebuf_get+0xba (0xf7d31ea0, 0x43e4e000, 0x2, 0x2000, 0x2201) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 21:12:28 debian kernel: 0xf3afbc8c 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf6404400, 0x0, 0xf6404564, 0x121f270, 0x0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 21:12:28 debian kernel: 0xf3afbce8 0xc01e01f3 xfs_itobp+0xfb (0xf6404400, 0x0, 0xccb7c4e8, 0xf3afbd2c, 0xf3afbd30) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 21:12:28 debian kernel: 0xf3afbd34 0xc01e2f43 xfs_iflush+0xab (0xccb7c4e8, 0x5) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 21:12:28 debian kernel: 0xf3afbd48 0xc01e415a xfs_inode_item_push+0x12 (0xe6ccb588) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 21:12:28 debian kernel: 0xf3afbd90 0xc01f451a xfs_trans_push_ail+0x136 (0xf6404400, 0x8bc, 0x26) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 21:12:28 debian kernel: 0xf3afbde4 0xc01e713f xlog_grant_push_ail+0x167 (0xf6404400, 0x2c5b8) Aug 31 21:12:28 debian kernel: [0]more> Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 21:12:28 debian kernel: 0xf3afbe00 0xc01e64ff xfs_log_reserve+0x3f (0xf6404400, 0x2abb8, 0x2, 0xdfee3d14, 0x69) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 21:12:28 debian kernel: 0xf3afbe2c 0xc01f3422 xfs_trans_reserve+0x7a (0xdfee3ce0, 0x0, 0x2abb8, 0x0, 0x4) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 21:12:28 debian kernel: 0xf3afbeb4 0xc01e1c31 xfs_itruncate_finish+0x2c1 (0xf3afbf10, 0xf46ec274, 0xd6, 0x0, 0x0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01e1970 0xc01e1c90 Aug 31 21:12:28 debian kernel: 0xf3afbf3c 0xc01f9446 xfs_inactive_free_eofblocks+0x20a (0xf6404400, 0xf46ec274) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f923c 0xc01f9488 Aug 31 21:12:28 debian kernel: 0xf3afbf54 0xc01f9a17 xfs_release+0x7f (0xf46ec28c) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01f9998 0xc01f9a4c Aug 31 21:12:28 debian kernel: 0xf3afbf60 0xc01ffe6a linvfs_release+0x26 (0xf46ed280, 0xe5421c00) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01ffe44 0xc01ffe70 Aug 31 21:12:28 debian kernel: 0xf3afbf80 0xc013258d fput+0x41 (0xe5421c00, 0xf65153e0, 0x0, 0xe5421c00, 0x0) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc013254c 0xc0132630 Aug 31 21:12:28 debian kernel: 0xf3afbfa8 0xc013137e filp_close+0xb2 (0xe5421c00, 0xf65153e0, 0xf3afa000) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc01312cc 0xc013138c Aug 31 21:12:28 debian kernel: 0xf3afbfbc 0xc01313eb sys_close+0x5f (0x3, 0x804b090, 0xbffff6d8, 0x40014d34, 0xbffff6a8) Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc013138c 0xc0131404 Aug 31 21:12:28 debian kernel: 0xc010707b system_call+0x33 Aug 31 21:12:28 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 Aug 31 21:12:28 debian kernel: [0]kdb> go ----------------------------------------------------------------------------------------------------------------------- reiser_fract_tr Aug 31 21:13:04 debian kernel: [0]kdb> btp 255 Aug 31 21:13:04 debian kernel: EBP EIP Function(args) Aug 31 21:13:04 debian kernel: 0xf3ae55d8 0xc0111756 schedule+0x482 (0xd44466a0, 0x1) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:13:04 debian kernel: 0xf3ae5604 0xc0105d44 __down+0x78 Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0105ccc 0xc0105da4 Aug 31 21:13:04 debian kernel: 0xf3ae5618 0xc0105eff __down_failed+0xb (0xf3ae56c8, 0xc01ab63e, 0xd44466a0, 0x5902000, 0xf7d31ea0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0105ef4 0xc0105f08 Aug 31 21:13:04 debian kernel: 0xc02e676d stext_lock+0x43dd Aug 31 21:13:04 debian kernel: kernel .text.lock 0xc02e2390 0xc02e2390 0xc02ebd60 Aug 31 21:13:04 debian kernel: 0xf3ae5620 0xc01ab533 _pagebuf_grab_lock+0x13 (0xd44466a0, 0x5902000) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01ab520 0xc01ab538 Aug 31 21:13:04 debian kernel: 0xf3ae56c8 0xc01ab63e _pagebuf_find_lockable_buffer+0x106 (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01ab538 0xc01ab724 Aug 31 21:13:04 debian kernel: 0xf3ae56f8 0xc01ab755 _pagebuf_get_lockable_buffer+0x31 (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01ab724 0xc01ab800 Aug 31 21:13:04 debian kernel: 0xf3ae5734 0xc01a7c51 pagebuf_get+0x91 (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 21:13:04 debian kernel: 0xf3ae5764 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf6404400, 0x0, 0xf6404564, 0x102c810, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 21:13:04 debian kernel: 0xf3ae57c0 0xc01e01f3 xfs_itobp+0xfb (0xf6404400, 0x0, 0xcc9d54c8, 0xf3ae5804, 0xf3ae5808) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 21:13:04 debian kernel: 0xf3ae580c 0xc01e2f43 xfs_iflush+0xab (0xcc9d54c8, 0x5) Aug 31 21:13:04 debian kernel: [0]more> Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 21:13:04 debian kernel: 0xf3ae5820 0xc01e415a xfs_inode_item_push+0x12 (0xc4dfe430) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 21:13:04 debian kernel: 0xf3ae5868 0xc01f451a xfs_trans_push_ail+0x136 (0xf6404400, 0x8bc, 0x26) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 21:13:04 debian kernel: 0xf3ae58bc 0xc01e713f xlog_grant_push_ail+0x167 (0xf6404400, 0x37f70, 0xf70e6660, 0x1adb8, 0x2) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 21:13:04 debian kernel: 0xf3ae58ec 0xc01e6534 xfs_log_reserve+0x74 (0xf6404400, 0x1adb8, 0x2, 0xdff3e4d4, 0x69) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 21:13:04 debian kernel: 0xf3ae5918 0xc01f3422 xfs_trans_reserve+0x7a (0xdff3e4a0, 0x0, 0x1adb8, 0x0, 0x4) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 21:13:04 debian kernel: 0xf3ae5a44 0xc0204a9e xfs_strategy+0x3c2 (0xcc059848, 0x0, 0x0, 0x1000, 0x10002) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc02046dc 0xc0204fe8 Aug 31 21:13:04 debian kernel: 0xf3ae5a7c 0xc02031c3 linvfs_pb_bmap+0x6f (0xf45a6600, 0x0, 0x0, 0x1000, 0xf3ae5acc) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0203154 0xc0203208 Aug 31 21:13:04 debian kernel: 0xf3ae5aec 0xc01aa6a8 __pb_block_prepare_write_async+0xac (0xf45a6600, 0xc1dee99c, 0x0, 0x1000, 0x1) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01aa5fc 0xc01aa824 Aug 31 21:13:04 debian kernel: 0xf3ae5b3c 0xc01aa360 pagebuf_write_full_page+0xe0 (0xc1dee99c, 0xc0203154) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01aa280 0xc01aa470 Aug 31 21:13:04 debian kernel: 0xf3ae5b4c 0xc020334d linvfs_write_full_page+0x11 (0xc1dee99c) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc020333c 0xc020335c Aug 31 21:13:04 debian kernel: 0xf3ae5b74 0xc012b4a2 page_launder+0x336 (0x1f0, 0x1) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012b16c 0xc012b954 Aug 31 21:13:04 debian kernel: [0]more> Aug 31 21:13:04 debian kernel: 0xf3ae5b94 0xc012bc3a do_try_to_free_pages+0x52 (0x1f0, 0x1, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012bbe8 0xc012bcb4 Aug 31 21:13:04 debian kernel: 0xf3ae5ba8 0xc012bdb0 try_to_free_pages+0x24 (0x1f0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012bd8c 0xc012bdbc Aug 31 21:13:04 debian kernel: 0xf3ae5bd8 0xc012c9c3 __alloc_pages+0x1d3 Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012c7f0 0xc012ca78 Aug 31 21:13:04 debian kernel: 0xf3ae5be4 0xc012c7e7 _alloc_pages+0x1b Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012c7cc 0xc012c7f0 Aug 31 21:13:04 debian kernel: 0xf3ae5c2c 0xc01a77ea _pagebuf_lookup_pages+0x18e (0xd44466a0, 0xf7d31ea8, 0x2201) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01a765c 0xc01a79f4 Aug 31 21:13:04 debian kernel: 0xf3ae5c5c 0xc01a7c7a pagebuf_get+0xba (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 21:13:04 debian kernel: 0xf3ae5c8c 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf6404400, 0x0, 0xf6404564, 0x102c810, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 21:13:04 debian kernel: 0xf3ae5ce8 0xc01e01f3 xfs_itobp+0xfb (0xf6404400, 0x0, 0xcc9d52f4, 0xf3ae5d2c, 0xf3ae5d30) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 21:13:04 debian kernel: 0xf3ae5d34 0xc01e2f43 xfs_iflush+0xab (0xcc9d52f4, 0x5) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 21:13:04 debian kernel: 0xf3ae5d48 0xc01e415a xfs_inode_item_push+0x12 (0xc4dfe3a8) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 21:13:04 debian kernel: 0xf3ae5d90 0xc01f451a xfs_trans_push_ail+0x136 (0xf6404400, 0x87c, 0x26) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 21:13:04 debian kernel: 0xf3ae5de4 0xc01e713f xlog_grant_push_ail+0x167 (0xf6404400, 0x2c5b8) Aug 31 21:13:04 debian kernel: [0]more> Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 21:13:04 debian kernel: 0xf3ae5e00 0xc01e64ff xfs_log_reserve+0x3f (0xf6404400, 0x2abb8, 0x2, 0xc0bbc754, 0x69) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 21:13:04 debian kernel: 0xf3ae5e2c 0xc01f3422 xfs_trans_reserve+0x7a (0xc0bbc720, 0x0, 0x2abb8, 0x0, 0x4) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 21:13:04 debian kernel: 0xf3ae5eb4 0xc01e1c31 xfs_itruncate_finish+0x2c1 (0xf3ae5f10, 0xf46ec61c, 0x1f, 0x0, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e1970 0xc01e1c90 Aug 31 21:13:04 debian kernel: 0xf3ae5f3c 0xc01f9446 xfs_inactive_free_eofblocks+0x20a (0xf6404400, 0xf46ec61c) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f923c 0xc01f9488 Aug 31 21:13:04 debian kernel: 0xf3ae5f54 0xc01f9a17 xfs_release+0x7f (0xf46ec634) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f9998 0xc01f9a4c Aug 31 21:13:04 debian kernel: 0xf3ae5f60 0xc01ffe6a linvfs_release+0x26 (0xf46ed640, 0xf3a7f140) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01ffe44 0xc01ffe70 Aug 31 21:13:04 debian kernel: 0xf3ae5f80 0xc013258d fput+0x41 (0xf3a7f140, 0xf6515240, 0x0, 0xf3a7f140, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc013254c 0xc0132630 Aug 31 21:13:04 debian kernel: 0xf3ae5fa8 0xc013137e filp_close+0xb2 (0xf3a7f140, 0xf6515240, 0xf3ae4000) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01312cc 0xc013138c Aug 31 21:13:04 debian kernel: 0xf3ae5fbc 0xc01313eb sys_close+0x5f (0x3, 0x804b090, 0xbffff6d8, 0x40014d34, 0xbffff6a8) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc013138c 0xc0131404 Aug 31 21:13:04 debian kernel: 0xc010707b system_call+0x33 Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 --------------------------------------------------------------------------------------------------------------------- reiser_fract_tr Aug 31 21:13:04 debian kernel: [0]kdb> btp 256 Aug 31 21:13:04 debian kernel: EBP EIP Function(args) Aug 31 21:13:04 debian kernel: 0xf3ad5c94 0xc0111756 schedule+0x482 (0xf5ff5c58) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:13:04 debian kernel: 0xf3ad5cd0 0xc02091a1 _sv_wait+0xd1 (0xf5ff5c58, 0xf70e6704, 0x282, 0x0, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc02090d0 0xc02091bc Aug 31 21:13:04 debian kernel: 0xf3ad5cfc 0xc01e8139 xlog_grant_log_space+0x135 (0xf70e6660, 0xf5ff5c58, 0xf6404400, 0x5f470, 0xf70e6660) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e8004 0xc01e8294 Aug 31 21:13:04 debian kernel: 0xf3ad5d34 0xc01e653b xfs_log_reserve+0x7b (0xf6404400, 0x2de38, 0x2, 0xf21b4af4, 0x69) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 21:13:04 debian kernel: 0xf3ad5d60 0xc01f3422 xfs_trans_reserve+0x7a (0xf21b4ac0, 0x44, 0x2de38, 0x0, 0x4) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 21:13:04 debian kernel: 0xf3ad5e24 0xc01fa1dd xfs_create+0x23d (0xd04e45f4, 0xf31a391c, 0xf3ad5e70, 0x0, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f9fa0 0xc01fa9cc Aug 31 21:13:04 debian kernel: 0xf3ad5ee0 0xc02025a5 linvfs_common_cr+0x99 (0xd04e55e0, 0xf31a38c0, 0x81ed, 0x1, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc020250c 0xc0202730 Aug 31 21:13:04 debian kernel: 0xf3ad5efc 0xc0202748 linvfs_create+0x18 (0xd04e55e0, 0xf31a38c0, 0x81ed) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0202730 0xc020274c Aug 31 21:13:04 debian kernel: 0xf3ad5f24 0xc013e0fb vfs_create+0xb3 (0xd04e55e0, 0xf31a38c0, 0x1ed) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc013e048 0xc013e164 Aug 31 21:13:04 debian kernel: 0xf3ad5f58 0xc013e2d5 open_namei+0x171 (0xce1bb000, 0xc3, 0x1ed, 0xf3ad5f7c) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc013e164 0xc013e6d8 Aug 31 21:13:04 debian kernel: 0xf3ad5f98 0xc0130ee6 filp_open+0x3a (0xce1bb000, 0xc2, 0x1ff) Aug 31 21:13:04 debian kernel: [0]more> Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0130eac 0xc0130f08 Aug 31 21:13:04 debian kernel: 0xf3ad5fbc 0xc01311fe sys_open+0x42 (0xbffff524, 0xc2, 0x1ff, 0x40014d34, 0xbffff6a8) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01311bc 0xc01312b0 Aug 31 21:13:04 debian kernel: 0xc010707b system_call+0x33 Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 ------------------------------------------------------------------------------------------------------------------------- reiser_fract_tr Aug 31 21:13:04 debian kernel: [0]kdb> btp 257 Aug 31 21:13:04 debian kernel: EBP EIP Function(args) Aug 31 21:13:04 debian kernel: 0xf3ac5574 0xc0111756 schedule+0x482 (0xd44466a0, 0x1) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:13:04 debian kernel: 0xf3ac55a0 0xc0105d44 __down+0x78 Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0105ccc 0xc0105da4 Aug 31 21:13:04 debian kernel: 0xf3ac55b4 0xc0105eff __down_failed+0xb (0xf3ac5664, 0xc01ab63e, 0xd44466a0, 0x5902000, 0xf7d31ea0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0105ef4 0xc0105f08 Aug 31 21:13:04 debian kernel: 0xc02e676d stext_lock+0x43dd Aug 31 21:13:04 debian kernel: kernel .text.lock 0xc02e2390 0xc02e2390 0xc02ebd60 Aug 31 21:13:04 debian kernel: 0xf3ac55bc 0xc01ab533 _pagebuf_grab_lock+0x13 (0xd44466a0, 0x5902000) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01ab520 0xc01ab538 Aug 31 21:13:04 debian kernel: 0xf3ac5664 0xc01ab63e _pagebuf_find_lockable_buffer+0x106 (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01ab538 0xc01ab724 Aug 31 21:13:04 debian kernel: 0xf3ac5694 0xc01ab755 _pagebuf_get_lockable_buffer+0x31 (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01ab724 0xc01ab800 Aug 31 21:13:04 debian kernel: 0xf3ac56d0 0xc01a7c51 pagebuf_get+0x91 (0xf7d31ea0, 0x5902000, 0x2, 0x2000, 0x2201) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01a7bc0 0xc01a7d18 Aug 31 21:13:04 debian kernel: 0xf3ac5700 0xc01f4b94 xfs_trans_read_buf+0x44 (0xf6404400, 0x0, 0xf6404564, 0x102c810, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f4b50 0xc01f4e38 Aug 31 21:13:04 debian kernel: 0xf3ac575c 0xc01e01f3 xfs_itobp+0xfb (0xf6404400, 0x0, 0xcc9d5870, 0xf3ac57a0, 0xf3ac57a4) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e00f8 0xc01e02b4 Aug 31 21:13:04 debian kernel: 0xf3ac57a8 0xc01e2f43 xfs_iflush+0xab (0xcc9d5870, 0x5) Aug 31 21:13:04 debian kernel: [0]more> Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e2e98 0xc01e32a4 Aug 31 21:13:04 debian kernel: 0xf3ac57bc 0xc01e415a xfs_inode_item_push+0x12 (0xc4dfe540) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e4148 0xc01e416c Aug 31 21:13:04 debian kernel: 0xf3ac5804 0xc01f451a xfs_trans_push_ail+0x136 (0xf6404400, 0x8bc, 0x26) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f43e4 0xc01f4608 Aug 31 21:13:04 debian kernel: 0xf3ac5858 0xc01e713f xlog_grant_push_ail+0x167 (0xf6404400, 0x37f70, 0xf70e6660, 0x1adb8, 0x2) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e6fd8 0xc01e714c Aug 31 21:13:04 debian kernel: 0xf3ac5888 0xc01e6534 xfs_log_reserve+0x74 (0xf6404400, 0x1adb8, 0x2, 0xc0bbc614, 0x69) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e64c0 0xc01e6548 Aug 31 21:13:04 debian kernel: 0xf3ac58b4 0xc01f3422 xfs_trans_reserve+0x7a (0xc0bbc5e0, 0x0, 0x1adb8, 0x0, 0x4) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f33a8 0xc01f34d0 Aug 31 21:13:04 debian kernel: 0xf3ac59e0 0xc0204a9e xfs_strategy+0x3c2 (0xcc059a1c, 0x0, 0x0, 0x1000, 0x10002) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc02046dc 0xc0204fe8 Aug 31 21:13:04 debian kernel: 0xf3ac5a18 0xc02031c3 linvfs_pb_bmap+0x6f (0xf45a6420, 0x0, 0x0, 0x1000, 0xf3ac5a68) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0203154 0xc0203208 Aug 31 21:13:04 debian kernel: 0xf3ac5a88 0xc01aa6a8 __pb_block_prepare_write_async+0xac (0xf45a6420, 0xc1dee958, 0x0, 0x1000, 0x1) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01aa5fc 0xc01aa824 Aug 31 21:13:04 debian kernel: 0xf3ac5ad8 0xc01aa360 pagebuf_write_full_page+0xe0 (0xc1dee958, 0xc0203154) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01aa280 0xc01aa470 Aug 31 21:13:04 debian kernel: 0xf3ac5ae8 0xc020334d linvfs_write_full_page+0x11 (0xc1dee958) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc020333c 0xc020335c Aug 31 21:13:04 debian kernel: 0xf3ac5b10 0xc012b4a2 page_launder+0x336 (0x1f0, 0x1) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012b16c 0xc012b954 Aug 31 21:13:04 debian kernel: [0]more> Aug 31 21:13:04 debian kernel: 0xf3ac5b30 0xc012bc3a do_try_to_free_pages+0x52 (0x1f0, 0x1, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012bbe8 0xc012bcb4 Aug 31 21:13:04 debian kernel: 0xf3ac5b44 0xc012bdb0 try_to_free_pages+0x24 (0x1f0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012bd8c 0xc012bdbc Aug 31 21:13:04 debian kernel: 0xf3ac5b74 0xc012c9c3 __alloc_pages+0x1d3 Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012c7f0 0xc012ca78 Aug 31 21:13:04 debian kernel: 0xf3ac5b80 0xc012c7e7 _alloc_pages+0x1b Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012c7cc 0xc012c7f0 Aug 31 21:13:04 debian kernel: 0xf3ac5b88 0xc012ca85 __get_free_pages+0xd Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc012ca78 0xc012ca98 Aug 31 21:13:04 debian kernel: 0xf3ac5bac 0xc0129236 kmem_cache_grow+0xe6 (0xc1eef148, 0x1f0, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0129150 0xc01293c0 Aug 31 21:13:04 debian kernel: 0xf3ac5bd4 0xc01295d6 kmem_cache_alloc+0xae (0xc1eef148, 0x1f0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0129528 0xc01295f0 Aug 31 21:13:04 debian kernel: 0xf3ac5bf0 0xc0147a75 get_new_inode+0x19 (0xf6404800, 0x58911b, 0xf7fcdb28, 0x0, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0147a5c 0xc0147b94 Aug 31 21:13:04 debian kernel: 0xf3ac5c1c 0xc0147d7d icreate4+0xd9 (0xf6404800, 0x58911b, 0x0, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0147ca4 0xc0147d88 Aug 31 21:13:04 debian kernel: 0xf3ac5c40 0xc01df673 xfs_iget+0x23 (0xf6404400, 0xc0bbcea0, 0x58911b, 0x0, 0x4) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01df650 0xc01df77c Aug 31 21:13:04 debian kernel: 0xf3ac5c78 0xc01f534c xfs_trans_iget+0x90 (0xf6404400, 0xc0bbcea0, 0x58911b, 0x0, 0x4) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f52bc 0xc01f53b4 Aug 31 21:13:04 debian kernel: 0xf3ac5cd4 0xc01e151f xfs_ialloc+0xb3 (0xc0bbcea0, 0xf321d9c4, 0x81ed, 0x1, 0x0) Aug 31 21:13:04 debian kernel: [0]more> Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01e146c 0xc01e17f0 Aug 31 21:13:04 debian kernel: 0xf3ac5d4c 0xc01f5d0f xfs_dir_ialloc+0x67 (0xf3ac5df8, 0xf321d9c4, 0x81ed, 0x1, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f5ca8 0xc01f5eb8 Aug 31 21:13:04 debian kernel: 0xf3ac5e24 0xc01fa3c3 xfs_create+0x423 (0xf321d9dc, 0xd6fc6dfc, 0xf3ac5e70, 0x0, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01f9fa0 0xc01fa9cc Aug 31 21:13:04 debian kernel: 0xf3ac5ee0 0xc02025a5 linvfs_common_cr+0x99 (0xf4e99620, 0xd6fc6da0, 0x81ed, 0x1, 0x0) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc020250c 0xc0202730 Aug 31 21:13:04 debian kernel: 0xf3ac5efc 0xc0202748 linvfs_create+0x18 (0xf4e99620, 0xd6fc6da0, 0x81ed) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0202730 0xc020274c Aug 31 21:13:04 debian kernel: 0xf3ac5f24 0xc013e0fb vfs_create+0xb3 (0xf4e99620, 0xd6fc6da0, 0x1ed) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc013e048 0xc013e164 Aug 31 21:13:04 debian kernel: 0xf3ac5f58 0xc013e2d5 open_namei+0x171 (0xce22d000, 0xc3, 0x1ed, 0xf3ac5f7c) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc013e164 0xc013e6d8 Aug 31 21:13:04 debian kernel: 0xf3ac5f98 0xc0130ee6 filp_open+0x3a (0xce22d000, 0xc2, 0x1ff) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0130eac 0xc0130f08 Aug 31 21:13:04 debian kernel: 0xf3ac5fbc 0xc01311fe sys_open+0x42 (0xbffff524, 0xc2, 0x1ff, 0x40014d34, 0xbffff6a8) Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc01311bc 0xc01312b0 Aug 31 21:13:04 debian kernel: 0xc010707b system_call+0x33 Aug 31 21:13:04 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 Aug 31 21:13:04 debian kernel: [0]kdb> go ------------------------------------------------------------------------------------------------------------------------- reiser_fract_tr Aug 31 21:13:46 debian kernel: [0]kdb> btp 258 Aug 31 21:13:46 debian kernel: EBP EIP Function(args) Aug 31 21:13:46 debian kernel: 0xf3a9d848 0xc0111756 schedule+0x482 Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01112d4 0xc0111974 Aug 31 21:13:46 debian kernel: 0xf3a9d87c 0xc0208d68 lock_wait+0xa0 (0xf46ec310, 0xf46ec328, 0x0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0208cc8 0xc0208d98 Aug 31 21:13:46 debian kernel: 0xf3a9d89c 0xc0208e10 mraccessf+0x4c (0xf46ec300, 0x288) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0208dc4 0xc0208e30 Aug 31 21:13:46 debian kernel: 0xf3a9d8b8 0xc01dfbd6 xfs_ilock_ra+0x82 (0xf46ec274, 0xc8, 0xc02047f7) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01dfb54 0xc01dfbe0 Aug 31 21:13:46 debian kernel: 0xf3a9d8cc 0xc01dfbf4 xfs_ilock+0x14 (0xf46ec274, 0xc8) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01dfbe0 0xc01dfbf8 Aug 31 21:13:46 debian kernel: 0xf3a9d9e0 0xc02047f7 xfs_strategy+0x11b (0xf46ec28c, 0x0, 0x0, 0x1000, 0x10002) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc02046dc 0xc0204fe8 Aug 31 21:13:46 debian kernel: 0xf3a9da18 0xc02031c3 linvfs_pb_bmap+0x6f (0xf46ed280, 0x0, 0x0, 0x1000, 0xf3a9da68) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0203154 0xc0203208 Aug 31 21:13:46 debian kernel: 0xf3a9da88 0xc01aa6a8 __pb_block_prepare_write_async+0xac (0xf46ed280, 0xc103a2d0, 0x0, 0x1000, 0x1) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01aa5fc 0xc01aa824 Aug 31 21:13:46 debian kernel: 0xf3a9dad8 0xc01aa360 pagebuf_write_full_page+0xe0 (0xc103a2d0, 0xc0203154) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01aa280 0xc01aa470 Aug 31 21:13:46 debian kernel: 0xf3a9dae8 0xc020334d linvfs_write_full_page+0x11 (0xc103a2d0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc020333c 0xc020335c Aug 31 21:13:46 debian kernel: 0xf3a9db10 0xc012b4a2 page_launder+0x336 (0x1f0, 0x1) Aug 31 21:13:46 debian kernel: [0]more> Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc012b16c 0xc012b954 Aug 31 21:13:46 debian kernel: 0xf3a9db30 0xc012bc3a do_try_to_free_pages+0x52 (0x1f0, 0x1, 0x0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc012bbe8 0xc012bcb4 Aug 31 21:13:46 debian kernel: 0xf3a9db44 0xc012bdb0 try_to_free_pages+0x24 (0x1f0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc012bd8c 0xc012bdbc Aug 31 21:13:46 debian kernel: 0xf3a9db74 0xc012c9c3 __alloc_pages+0x1d3 Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc012c7f0 0xc012ca78 Aug 31 21:13:46 debian kernel: 0xf3a9db80 0xc012c7e7 _alloc_pages+0x1b Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc012c7cc 0xc012c7f0 Aug 31 21:13:46 debian kernel: 0xf3a9db88 0xc012ca85 __get_free_pages+0xd Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc012ca78 0xc012ca98 Aug 31 21:13:46 debian kernel: 0xf3a9dbac 0xc0129236 kmem_cache_grow+0xe6 (0xc1eef148, 0x1f0, 0x0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0129150 0xc01293c0 Aug 31 21:13:46 debian kernel: 0xf3a9dbd4 0xc01295d6 kmem_cache_alloc+0xae (0xc1eef148, 0x1f0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0129528 0xc01295f0 Aug 31 21:13:46 debian kernel: 0xf3a9dbf0 0xc0147a75 get_new_inode+0x19 (0xf6404800, 0x8045e5, 0xf7fa82b8, 0x0, 0x0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0147a5c 0xc0147b94 Aug 31 21:13:46 debian kernel: 0xf3a9dc1c 0xc0147d7d icreate4+0xd9 (0xf6404800, 0x8045e5, 0x0, 0x0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0147ca4 0xc0147d88 Aug 31 21:13:46 debian kernel: 0xf3a9dc40 0xc01df673 xfs_iget+0x23 (0xf6404400, 0xdff3eea0, 0x8045e5, 0x0, 0x4) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01df650 0xc01df77c Aug 31 21:13:46 debian kernel: 0xf3a9dc78 0xc01f534c xfs_trans_iget+0x90 (0xf6404400, 0xdff3eea0, 0x8045e5, 0x0, 0x4) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01f52bc 0xc01f53b4 Aug 31 21:13:46 debian kernel: [0]more> Aug 31 21:13:46 debian kernel: 0xf3a9dcd4 0xc01e151f xfs_ialloc+0xb3 (0xdff3eea0, 0xe8d82b38, 0x81ed, 0x1, 0x0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01e146c 0xc01e17f0 Aug 31 21:13:46 debian kernel: 0xf3a9dd4c 0xc01f5d0f xfs_dir_ialloc+0x67 (0xf3a9ddf8, 0xe8d82b38, 0x81ed, 0x1, 0x0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01f5ca8 0xc01f5eb8 Aug 31 21:13:46 debian kernel: 0xf3a9de24 0xc01fa3c3 xfs_create+0x423 (0xe8d82b50, 0xd6fc6f7c, 0xf3a9de70, 0x0, 0x0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01f9fa0 0xc01fa9cc Aug 31 21:13:46 debian kernel: 0xf3a9dee0 0xc02025a5 linvfs_common_cr+0x99 (0xe958cde0, 0xd6fc6f20, 0x81ed, 0x1, 0x0) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc020250c 0xc0202730 Aug 31 21:13:46 debian kernel: 0xf3a9defc 0xc0202748 linvfs_create+0x18 (0xe958cde0, 0xd6fc6f20, 0x81ed) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0202730 0xc020274c Aug 31 21:13:46 debian kernel: 0xf3a9df24 0xc013e0fb vfs_create+0xb3 (0xe958cde0, 0xd6fc6f20, 0x1ed) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc013e048 0xc013e164 Aug 31 21:13:46 debian kernel: 0xf3a9df58 0xc013e2d5 open_namei+0x171 (0xc75c7000, 0xc3, 0x1ed, 0xf3a9df7c) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc013e164 0xc013e6d8 Aug 31 21:13:46 debian kernel: 0xf3a9df98 0xc0130ee6 filp_open+0x3a (0xc75c7000, 0xc2, 0x1ff) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0130eac 0xc0130f08 Aug 31 21:13:46 debian kernel: 0xf3a9dfbc 0xc01311fe sys_open+0x42 (0xbffff524, 0xc2, 0x1ff, 0x40014d34, 0xbffff6a8) Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc01311bc 0xc01312b0 Aug 31 21:13:46 debian kernel: 0xc010707b system_call+0x33 Aug 31 21:13:46 debian kernel: kernel .text 0xc0100000 0xc0107048 0xc0107080 From owner-linux-xfs@oss.sgi.com Fri Aug 31 13:16:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VKGWq28228 for linux-xfs-outgoing; Fri, 31 Aug 2001 13:16:32 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VKGSd28209 for ; Fri, 31 Aug 2001 13:16:28 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA07420 for ; Fri, 31 Aug 2001 13:14:46 -0700 (PDT) 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 PAA2859984 for ; Fri, 31 Aug 2001 15:15:10 -0500 (CDT) 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 PAA19339 for ; Fri, 31 Aug 2001 15:15:10 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.2/SGI-client-1.7) id f7VKEMj09529; Fri, 31 Aug 2001 15:14:22 -0500 Message-Id: <200108312014.f7VKEMj09529@stout.americas.sgi.com> Date: Fri, 31 Aug 2001 15:14:22 -0500 From: Eric Sandeen Subject: TAKE - mkfs/growfs 32-bit inode number awareness Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS uses 64-bit inode numbers internally; however, the number of significant bits in an inode number is affected by filesystem geometry. In practice, filesystem size and inode size are the predominant factors. The Linux kernel and most applications cannot currently handle inode numbers greater than 32 significant bits. With default blocksize & inode size on Linux, we hit 32 bits at right about 1 Terabyte. This mod changes mkfs.xfs so that if inode size is not specified, it will attempt to choose a size that will keep inode numbers < 32 significant bits. If it cannot, or if an inode size was specified on the command line, it will issue a warning if inode numbers will have > 32 significant bits. We run into this in growfs as well - on average, doubling the size of a filesystem will add one significant bit to the inode numbers. xfs_growfs will warn & fail if this goes over 32 bits, but this can be overridden with the -I option. Both growfs and mkfs will also print how many significant bits will be required for inodes when it prints the filesystem geometry. Date: Fri Aug 31 13:08:21 PDT 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102025a cmd/xfsprogs/growfs/xfs_growfs.c - 1.6 - Warn & fail if new FS inode numbers will be > 32 bits Add -I option to allow these big inode numbers. cmd/xfsprogs/mkfs/xfs_mkfs.h - 1.2 - Add #define for max # of significant inode bits we're comfortable with cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.15 - Try to keep inode numbers < 32 significant bits, warn if we can't cmd/xfsprogs/man/man8/xfs_growfs.8 - 1.2 - Document new -I option Document 32-bit inode number issues & caveats. cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.7 - Document 32-bit inode number issues & caveats. cmd/xfsprogs/doc/CHANGES - 1.34 - Info on 32 bit changes for mkfs and growfs cmd/xfsprogs/VERSION - 1.27 - Bump version for 32-bit awareness. From owner-linux-xfs@oss.sgi.com Fri Aug 31 13:16:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VKGns28344 for linux-xfs-outgoing; Fri, 31 Aug 2001 13:16:49 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VKGed28293 for ; Fri, 31 Aug 2001 13:16:40 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 0357C67040 for ; Fri, 31 Aug 2001 22:16:32 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Fri, 31 Aug 2001 22:16:32 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 22:16:34, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 22:16:34, Serialize complete at 31.08.2001 22:16:34, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 22:16:35, S/MIME Sign complete at 31.08.2001 22:16:35, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 31.08.2001 22:16:34 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z26135_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z26135_boundary_sign Content-Type: text/plain; charset="us-ascii" On 31.08.2001 20:34:48 Seth Mos wrote: >On Fri, 31 Aug 2001, Michael Wahlbrink wrote: > >> On 31.08.2001 19:39:10 Seth Mos wrote: >> >On Fri, 31 Aug 2001, Michael Wahlbrink wrote: >> >It seems to be incomplete, it can't find modules info. The function >is >> >not translated. did you try it like this? >> >ksymoops < oops.txt > ksymoops.txt >> > >> >Doesn't your machine have module support of do you have no modules >> >loaded? >> >My machines have a /proc/modules file. Weird. >> Hi, >> I have a kernel with module support, but actually no compiled modules >> (will come later if the fs is working properly), so i think that it >is ok >> that ksymoops cries about my modules (or not). >> my command was ksymoops oops.txt >output.txt (not the right way? >should I >> call it your way again? I'm a newbie in debugging things....... so >tell it >> to me). > >You did it right, it should be fine. > >> my /proc/modules is empty! > >No modules loaded I guess :-) You are right! Now I had reproduced the oops on a newly made filesystem # cp -r /usr/src /xfsmounted/ doing some other copystuff and then do # cp -r /usr/src /xfsmounted/ again..... if you do 'ls -al' I can see that the directory is now bigger (also if I tar the directory on /xfsmounted its bigger then the tarred /usr/src/ and i get some errormessages) If I now try to do an # rm -r /xfsmounted/src I get errormessages about not emty folders.... If I do the rm again I get the oops!! :-(( hope this helps what can/should I do?? cu micha ---------z26135_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDgzMTIwMTYzNVowIwYJKoZIhvcNAQkEMRYEFHK42G60rNoCni1j 4pMtjDV3bijOMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGACta3pUV6aun16VpZL/11si4pC66sHttIm2NtvGBRZlDxpdiltaGs 2pdOh2KaFHPt8KHIUMmKyWF7dozxeizQZtE5qeaTARJ7bdkVMpehi3zS/QYzo0E6 3ThuCUdvKHgK9JJiIYPtNqjdJr94B6YEq9eygAjVxbFQRrMgjpdaBT0AAAAAAAAA AA== ---------z26135_boundary_sign-- From owner-linux-xfs@oss.sgi.com Fri Aug 31 13:25:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VKPA628589 for linux-xfs-outgoing; Fri, 31 Aug 2001 13:25:10 -0700 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 f7VKP7d28570 for ; Fri, 31 Aug 2001 13:25:07 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7VKUl527400 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Fri, 31 Aug 2001 13:30:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA763093 for ; Fri, 31 Aug 2001 22:25:00 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2863728; Fri, 31 Aug 2001 15:23:43 -0500 (CDT) Received: from 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 PAA38978; Fri, 31 Aug 2001 15:23:43 -0500 (CDT) Message-ID: <3B8FF21F.4D13D8C@sgi.com> Date: Fri, 31 Aug 2001 15:22:55 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Wahlbrink CC: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael Wahlbrink wrote: > hope this helps > what can/should I do?? Before we get too far into this... what compiler did you use for this? I'm guessing maybe not the recommended one? :) Strange things happen when kernels miscompile, let's make sure you're using gcc 2.91.66 (aka egcs 1.1.2) and see if things get better. http://oss.sgi.com/projects/xfs/faq.html#compilersissues -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 Aug 31 13:29:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VKT7c28766 for linux-xfs-outgoing; Fri, 31 Aug 2001 13:29:07 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VKT0d28747 for ; Fri, 31 Aug 2001 13:29:00 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id F274E67040 for ; Fri, 31 Aug 2001 22:28:53 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Fri, 31 Aug 2001 22:28:53 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 22:28:55, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 22:28:55, Serialize complete at 31.08.2001 22:28:55, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 22:28:55, S/MIME Sign complete at 31.08.2001 22:28:55, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 31.08.2001 22:28:54, Serialize complete at 31.08.2001 22:28:54 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z25641_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z25641_boundary_sign Content-Type: text/plain; charset="us-ascii" On 31.08.2001 22:22:55 Eric Sandeen wrote: >Michael Wahlbrink wrote: > >> hope this helps >> what can/should I do?? > >Before we get too far into this... what compiler did you use for this? >I'm guessing maybe not the recommended one? :) > >Strange things happen when kernels miscompile, let's make sure you're >using gcc 2.91.66 (aka egcs 1.1.2) and see if things get better. > >http://oss.sgi.com/projects/xfs/faq.html#compilersissues > >-Eric Hi eric, I've read this, but where I can get this egs for the suse 7.2 which I have to use (company standard..... I would prefer debian.......)?? So I hope you can help me.... cu michael ---------z25641_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDgzMTIwMjg1NVowIwYJKoZIhvcNAQkEMRYEFC3nku9C89/1Kc+k uIfU6WwIpIiJMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAJg61FDdh94AVNKE2banUUW2RY9bYVjzm20d/9JCPwyPa1G3iC/DT uzYENCwHiGt85xlYc6rH3Q/bwzzs5uxLUNw/JoGPJM/DbPjBzdATIqq2U3/0NPrd cBe3m6S6I0fTscel0YkR+2AMu9gYYuMBgzNAFacmVygDJVItV4vECgMAAAAAAAAA AA== ---------z25641_boundary_sign-- From owner-linux-xfs@oss.sgi.com Fri Aug 31 13:44:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VKiWh29314 for linux-xfs-outgoing; Fri, 31 Aug 2001 13:44:32 -0700 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 f7VKiTd29291 for ; Fri, 31 Aug 2001 13:44:29 -0700 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 f7VKpBa02568 for ; Fri, 31 Aug 2001 13:51:12 -0700 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 PAA2865717; Fri, 31 Aug 2001 15:43:07 -0500 (CDT) Received: from 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 PAA25963; Fri, 31 Aug 2001 15:43:06 -0500 (CDT) Message-ID: <3B8FF6AB.FD382483@sgi.com> Date: Fri, 31 Aug 2001 15:42:19 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Wahlbrink CC: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael Wahlbrink wrote: > Hi eric, > I've read this, but where I can get this egs for the suse 7.2 which I have > to use (company standard..... I would prefer debian.......)?? > > So I hope you can help me.... Hi Michael - I _think_ you could use Red Hat's compat-egcs and compat-glibc RPMs on a SuSE system, to get this compiler - can any of the SuSE-users verify that this is OK? -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 Aug 31 13:57:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VKvp129749 for linux-xfs-outgoing; Fri, 31 Aug 2001 13:57:51 -0700 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 f7VKvdd29728 for ; Fri, 31 Aug 2001 13:57:39 -0700 Received: (qmail 13229 invoked from network); 31 Aug 2001 20:57:36 -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; 31 Aug 2001 20:57:36 -0000 Message-ID: <3B8FFA69.7060409@st-peter.stw.uni-erlangen.de> Date: Fri, 31 Aug 2001 22:58:17 +0200 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: [linux-lvm] PBs with LVM over software RAID References: <3B8E3F0E.8050609@st-peter.stw.uni-erlangen.de> <20010830083546.A20989@sistina.com> <3B8EC633.40202@st-peter.stw.uni-erlangen.de> <3B8F8C5E.7030603@st-peter.stw.uni-erlangen.de> <20010831110512.V541@turbolinux.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi i'm having a serios trouble with creating a LVM over software linear RAID well i created it, formated it with XFS but every time i try to mount the LV mount segfaults and then i can not mount any other file system ( partition, CD, .. until i reboot, when i try to mount smth mount simple stop to respond without an error and blocks the console i'm using XFS cvs kernel 2.4.9 and LVM-1.0.1rc1 on ABIT's BP6 2xCelleron 533 512Mb RAM the drives are on onboard HPT366 controler 2xWD 30Gb 1xMaxtor 40Gb the LV is striped over the 3 devices of the VG the VG is /dev/hdh10 /dev/md6 /dev/md7 /dev/md6 is linear software RAID /dev/hde6 /dev/hde12 /dev/md7 is linear software RAID /dev/hdg1 /dev/hdg5 /dev/hdg6 dev/hdg11 i posted to the LVM-lists and there i was told to try "dmesg | ksymoops" and i became the folowing answer > >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <===== > >> Trace; c023fa12 <__make_request+412/6d0> >> Trace; c0278dcd >> Trace; c027fa0f >> Trace; c023fd89 > >OK, so the oops is inside the RAID layer, but it may be that it is >being fed bogus data from a higher layer. Even so, it should not >oops in this case. Since XFS changes a lot of the kernel code, I >would either suggest asking the XFS folks to look at this oops, >or maybe on the MD RAID mailing list, as they will know more about it. this is the full "dmesg | ksymoops" , i'll try to use other FS to find out whether it's a problem with XFS, but i wish me not to have to use other FS, i realy love XFS Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010247 eax: 004ac1ab ebx: 004ac1ab ecx: 00000000 edx: 00000000 esi: d54eb320 edi: c188b928 ebp: 00958357 esp: d4eb3670 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 5536, stackpage=d4eb3000) Stack: d54eb3e0 c023fa12 00000907 d54eb320 00000000 01c02000 c0278dcd dcec43c0 00000000 d54eb320 d54eb320 00000000 01c02000 c027fa0f 00000001 d54eb320 c023fd89 c03a7254 00000000 d54eb320 00000282 00000021 00000000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f7 f9 85 d2 74 24 55 51 68 c0 03 9c e2 e8 58 6c 75 dd 6a 00 >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <===== Trace; c023fa12 <__make_request+412/6d0> Trace; c0278dcd Trace; c027fa0f Trace; c023fd89 Trace; c01a6814 <_pagebuf_page_io+1f4/370> Trace; c01a6a85 <_page_buf_page_apply+f5/1c0> Trace; c01a6fc1 Trace; c01a6c47 Trace; c01a6990 <_page_buf_page_apply+0/1c0> Trace; c0105dac <__down+bc/d0> Trace; c0105f1c <__down_failed+8/c> Trace; c02e2140 Trace; c021c10a Trace; c01fe5b8 Trace; c01ff2a4 Trace; c01a553e <_pagebuf_get_object+3e/170> Trace; c01feb6f Trace; c01feed8 Trace; c01fc322 Trace; c0201f40 Trace; c01fb8f3 Trace; c0202fdf Trace; c02026bf Trace; c01a60be Trace; c02026eb Trace; c021e674 Trace; c020b69c Trace; c020b843 Trace; c020b871 Trace; c021cf48 Trace; c01294e0 Trace; c0125f0e Trace; c0125d9d Trace; c013cd72 Trace; c013d01b Trace; c013dafc Trace; c01131e0 Trace; c010724c Trace; c013dd56 Trace; c013dbfc Trace; c013de13 Trace; c010715b Code; e29c0266 <[linear]linear_make_request+36/f0> 00000000 <_EIP>: Code; e29c0266 <[linear]linear_make_request+36/f0> <===== 0: f7 f9 idiv %ecx,%eax <===== Code; e29c0268 <[linear]linear_make_request+38/f0> 2: 85 d2 test %edx,%edx Code; e29c026a <[linear]linear_make_request+3a/f0> 4: 74 24 je 2a <_EIP+0x2a> e29c0290 <[linear]linear_make_request+60/f0> Code; e29c026c <[linear]linear_make_request+3c/f0> 6: 55 push %ebp Code; e29c026d <[linear]linear_make_request+3d/f0> 7: 51 push %ecx Code; e29c026e <[linear]linear_make_request+3e/f0> 8: 68 c0 03 9c e2 push $0xe29c03c0 Code; e29c0273 <[linear]linear_make_request+43/f0> d: e8 58 6c 75 dd call dd756c6a <_EIP+0xdd756c6a> c0116ed0 Code; e29c0278 <[linear]linear_make_request+48/f0> 12: 6a 00 push $0x0 Andreas Dilger wrote: >On Aug 31, 2001 15:08 +0200, svetljo wrote: > >>[root@svetljo mnt]# mount -t xfs /dev/myData/Music music >>Segmentation fault >> > >Generally this is a bad sign. Either mount is segfaulting (unlikely) >or you are getting an oops in the kernel. You need do run something >like "dmesg | ksymoops" in order to get some useful data about where >the problem is (could be xfs, LVM, or elsewhere in the kernel). > >Once you have an oops, you are best off rebooting the system, because >your kernel memory may be corrupted, and cause more oopses which do >not mean anything. If you look in /var/log/messages (or /var/log/kern.log >or some other place, depending on where kernel messages go), you can >decode the FIRST oops in the log with ksymoops. All subsequent ones are >useless. > > >>the LV ( lvcreate -i3 -I4 -L26G -nMusic ) >> >>the VG -> myData /dev/hdh10 /dev/linVG1/linLV1 /dev/linVG2/linLV2 >> >>/dev/hdh10 normal partition 14G >>/dev/linVG1/linLV1 -> linear LV 14G /dev/hde6 /dev/hde12 >>/dev/linVg2/linLV2 -> linear LV 14G /dev/hdg1 /dev/hdg5 /dev/hdg6 /dev/hdg12 >> > >There is absolutely no point in doing this (not that it is possible to do >so anyways). First of all, striping is almost never needed "for performance" >unless you are normally doing very large sequential I/Os, and even so most >disks today have very good sequential I/O rates (e.g. 15-30MB/s). Secondly, >you _should_ be able to just create a single LV that is striped across all >of the PVs above. You would likely need to build it in steps, to ensure >that it is striped across the disks correctly. > >Cheers, Andreas > From owner-linux-xfs@oss.sgi.com Fri Aug 31 14:12:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VLCRD30116 for linux-xfs-outgoing; Fri, 31 Aug 2001 14:12:27 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VLCOd30092 for ; Fri, 31 Aug 2001 14:12:24 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA12067; Fri, 31 Aug 2001 23:12:22 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA07189; Fri, 31 Aug 2001 23:12:22 +0200 (CEST) Date: Fri, 31 Aug 2001 23:12:22 +0200 (CEST) From: Seth Mos To: Eric Sandeen cc: Michael Wahlbrink , linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-Reply-To: <3B8FF6AB.FD382483@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 Fri, 31 Aug 2001, Eric Sandeen wrote: > Michael Wahlbrink wrote: > > > Hi eric, > > I've read this, but where I can get this egs for the suse 7.2 which I have > > to use (company standard..... I would prefer debian.......)?? > > > > So I hope you can help me.... > > Hi Michael - > > I _think_ you could use Red Hat's compat-egcs and compat-glibc RPMs on a > SuSE system, to get this compiler - can any of the SuSE-users verify > that this is OK? I have seen reports that it can succesfully be used on SuSE. I believe this is what most people are doing right now. Cheers From owner-linux-xfs@oss.sgi.com Fri Aug 31 14:27:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VLRXh30471 for linux-xfs-outgoing; Fri, 31 Aug 2001 14:27:33 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VLRUd30452 for ; Fri, 31 Aug 2001 14:27:30 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05166 for ; Fri, 31 Aug 2001 14:27:23 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1959872; Fri, 31 Aug 2001 16:26:06 -0500 (CDT) Received: from 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 QAA31147; Fri, 31 Aug 2001 16:26:04 -0500 (CDT) Message-ID: <3B9000BC.6541828@sgi.com> Date: Fri, 31 Aug 2001 16:25:16 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Schutte CC: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: <3B8E6E8E.D2082F15@it.up.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Paul Schutte wrote: > > Hi, > > I found a problem while doing benchmarks with mongo.pl > > The sympthom is that the machine just hangs. No error messages. Ok, I see this too.... looks like bdflush is the only thing that's running. If I try a sync, then that's what hangs, both of these get lost in write_some_buffers - looks like a deadlock? Hm.... you think Hans did this on purpose? ;-) I'll see if I can find anything next week... time for my weekend now, I'm afraid. Thanks for pointing this out! -Eric p.s. fwiw, this is on adaptec hardware as well. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Aug 31 14:49:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VLnd630941 for linux-xfs-outgoing; Fri, 31 Aug 2001 14:49:39 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VLnVd30922 for ; Fri, 31 Aug 2001 14:49:32 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 3D98167040 for ; Fri, 31 Aug 2001 23:49:25 +0200 (CEST) Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Fri, 31 Aug 2001 23:49:20 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 23:49:22, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 23:49:22, Serialize complete at 31.08.2001 23:49:22, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 31.08.2001 23:49:23, S/MIME Sign complete at 31.08.2001 23:49:23, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 31.08.2001 23:49:25, Serialize complete at 31.08.2001 23:49:25 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z32088_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z32088_boundary_sign Content-Type: text/plain; charset="us-ascii" On 31.08.2001 23:12:22 Seth Mos wrote: >On Fri, 31 Aug 2001, Eric Sandeen wrote: > >> Michael Wahlbrink wrote: >> >> > Hi eric, >> > I've read this, but where I can get this egs for the suse 7.2 which >I have >> > to use (company standard..... I would prefer debian.......)?? >> > >> > So I hope you can help me.... >> >> Hi Michael - >> >> I _think_ you could use Red Hat's compat-egcs and compat-glibc RPMs >on a >> SuSE system, to get this compiler - can any of the SuSE-users verify >> that this is OK? > >I have seen reports that it can succesfully be used on SuSE. I believe >this is what most people are doing right now. > >Cheers Ok I've downloaded and installed these rpms, now my stupid question: what I've to do, that these other Compiler will be used (change the 'cc-link' to the kgcc??)???? I'm now so far with xfs so I want also a running system ;-) so please give me a little hint, that I can bring my first xfs-box up! cu michael ps: I'm very impressed on the fact how fast you get help on the xfs mailinglist, a _big_thank you to the xfs people!!! ---------z32088_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDgzMTIxNDkyMlowIwYJKoZIhvcNAQkEMRYEFKOVLKVl8BDRl69z 64hUJM/Z+ebzMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGApWiAKm0xGXs/9xnpdQepzKlM4ogCMWLhmibDNl7WhnQsSrKESocO HaZWyM2AgdiybcDahihw/eKvlXaHCRnlDkBtQ3aVgeNbhbv33LkMPVyZe2413uYv OK7feqVTZzA5W5xoECDSZ602a7GApeQciHh2ckz90N/qWXPRUWKohhUAAAAAAAAA AA== ---------z32088_boundary_sign-- From owner-linux-xfs@oss.sgi.com Fri Aug 31 14:55:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VLtCZ31138 for linux-xfs-outgoing; Fri, 31 Aug 2001 14:55:12 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VLt8d31118 for ; Fri, 31 Aug 2001 14:55:08 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA16769; Fri, 31 Aug 2001 23:55:06 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA08859; Fri, 31 Aug 2001 23:55:06 +0200 (CEST) Date: Fri, 31 Aug 2001 23:55:05 +0200 (CEST) From: Seth Mos To: Eric Sandeen cc: Paul Schutte , XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. In-Reply-To: <3B9000BC.6541828@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 Fri, 31 Aug 2001, Eric Sandeen wrote: > Paul Schutte wrote: > > > > Hi, > > > > I found a problem while doing benchmarks with mongo.pl > > > > The sympthom is that the machine just hangs. No error messages. > > Ok, I see this too.... looks like bdflush is the only thing that's > running. > > If I try a sync, then that's what hangs, both of these get lost in > write_some_buffers - looks like a deadlock? Then it is specific to scsi perhaps. AFAIk the scsi layer was never considered "elegant". > Hm.... you think Hans did this on purpose? ;-) > > I'll see if I can find anything next week... time for my weekend now, > I'm afraid. Mine started 8 hours ago :-) > Thanks for pointing this out! > > -Eric > > p.s. fwiw, this is on adaptec hardware as well. I am not seeing it on my Athlon and IDE home box. Is this thus only reproducable on adaptec/scsi hardware? I'll scavenge the room for my spare 4.5GB scsi disk and see if I can get my homebox to hang. My controller however is a sym53c8xx. I have tried 1,5 and 10 processes but it just won't hang :-) Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 31 14:57:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VLvCe31283 for linux-xfs-outgoing; Fri, 31 Aug 2001 14:57:12 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VLv9d31264 for ; Fri, 31 Aug 2001 14:57:09 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA16937; Fri, 31 Aug 2001 23:57:07 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA08955; Fri, 31 Aug 2001 23:57:07 +0200 (CEST) Date: Fri, 31 Aug 2001 23:57:07 +0200 (CEST) From: Seth Mos To: Michael Wahlbrink cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 31 Aug 2001, Michael Wahlbrink wrote: > On 31.08.2001 23:12:22 Seth Mos wrote: > >On Fri, 31 Aug 2001, Eric Sandeen wrote: > > > >> Michael Wahlbrink wrote: > >> > >> > Hi eric, > >> > I've read this, but where I can get this egs for the suse 7.2 which > >I have > >> > to use (company standard..... I would prefer debian.......)?? > >> > > >> > So I hope you can help me.... > >> > >> Hi Michael - > >> > >> I _think_ you could use Red Hat's compat-egcs and compat-glibc RPMs > >on a > >> SuSE system, to get this compiler - can any of the SuSE-users verify > >> that this is OK? > > > >I have seen reports that it can succesfully be used on SuSE. I believe > >this is what most people are doing right now. > > > >Cheers > Ok I've downloaded and installed these rpms, now my stupid question: what > I've to do, that these other Compiler will be used (change the 'cc-link' > to the kgcc??)???? I'm now so far with xfs so I want also a running system > ;-) so please give me a little hint, that I can bring my first xfs-box up! In the top level Makefile for the kernel is one that is especially for kgcc. You can find it including comments. Just remove the # sign from that line. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Aug 31 15:26:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VMQit32049 for linux-xfs-outgoing; Fri, 31 Aug 2001 15:26:44 -0700 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 f7VMQcd32023 for ; Fri, 31 Aug 2001 15:26:39 -0700 Received: (qmail 12066 invoked from network); 31 Aug 2001 22:26:37 -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; 31 Aug 2001 22:26:37 -0000 Message-ID: <3B900F46.9040402@st-peter.stw.uni-erlangen.de> Date: Sat, 01 Sep 2001 00:27:18 +0200 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-lvm@sistina.com, linux-xfs@oss.sgi.com Subject: Re: [linux-lvm] PBs with LVM over software RAID References: <3B8E3F0E.8050609@st-peter.stw.uni-erlangen.de> <20010830083546.A20989@sistina.com> <3B8EC633.40202@st-peter.stw.uni-erlangen.de> <3B8F8C5E.7030603@st-peter.stw.uni-erlangen.de> <20010831110512.V541@turbolinux.com> <3B8FD95C.60702@st-peter.stw.uni-erlangen.de> <20010831130718.C541@turbolinux.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi it works with IMB's JFS when i try mkfs -t reiserfs -f /dev/myData/SRC it segfaults : [root@svetljo mnt]# mkfs -t reiserfs -f /dev/myData/SRC mkreiserfs, 2001 - reiserfsprogs 3.x.0j =================================================================== LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey ------------------------------------------------------------------------------- |###|type|ilen|f/sp| loc|fmt|fsck| key | | | | |e/cn| | |need| | ------------------------------------------------------------------------------- Segmentation fault isn't that a bit strange that reiserfs and xfs doesn't handle it, but jfs does and the one with ext2 : [root@svetljo mnt]# mkfs -t ext2 /dev/myData/SRC mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 786432 inodes, 1572864 blocks 78643 blocks (5.00%) reserved for the super user First data block=0 48 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736 Writing inode tables: Segmentation fault i realy don't like that Andreas Dilger wrote: >On Aug 31, 2001 20:37 +0200, svetljo wrote: > >>>>EIP; e29c0266 <[linear]linear_make_request+36/f0> <===== >>>> >>Trace; c023fa12 <__make_request+412/6d0> >>Trace; c0278dcd >>Trace; c027fa0f >>Trace; c023fd89 >> > >OK, so the oops is inside the RAID layer, but it may be that it is >being fed bogus data from a higher layer. Even so, it should not >oops in this case. Since XFS changes a lot of the kernel code, I >would either suggest asking the XFS folks to look at this oops, >or maybe on the MD RAID mailing list, as they will know more about it. > >Cheers, Andreas > From owner-linux-xfs@oss.sgi.com Fri Aug 31 17:07:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8107Ln01384 for linux-xfs-outgoing; Fri, 31 Aug 2001 17:07:21 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8107Hd01365 for ; Fri, 31 Aug 2001 17:07:17 -0700 Received: (qmail 30383 invoked from network); 1 Sep 2001 00:07:14 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 1 Sep 2001 00:07:14 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Paul Schutte cc: XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. In-reply-to: Your message of "Fri, 31 Aug 2001 18:32:27 +0200." <3B8FBC1B.4AB635C3@it.up.ac.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Sep 2001 10:07:14 +1000 Message-ID: <18173.999302834@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 31 Aug 2001 18:32:27 +0200, Paul Schutte wrote: >I have not worked with kdb before. I scanned the mailing lists and FAQ on >kdb. >I am sorry if this was mentioned earlier, but I could'nt find a way to >search the archives. > >I am in the debugger by pressing Pause. > >What info must I gather for you guys and how do I capture it ? Start with the bt command, for backtrace. Capturing debugger output is difficult because the machine is dead and cannot write to disk. The best way is to build the kernel with a serial console and debug over that. Recommended reading: linux/Documentation/serial-console.txt man linux/Documentation/kdb/kdb.mm man linux/Documentation/kdb/kdb_bt.man From owner-linux-xfs@oss.sgi.com Fri Aug 31 21:21:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f814L0P04810 for linux-xfs-outgoing; Fri, 31 Aug 2001 21:21:00 -0700 Received: from monkeyiq.dnsalias.org (CPE-203-45-215-234.qld.bigpond.net.au [203.45.215.234]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f814Kvd04791 for ; Fri, 31 Aug 2001 21:20:57 -0700 Received: by monkeyiq.dnsalias.org id f814KhY32589 ; Sat, 1 Sep 2001 14:20:43 +1000 Date: Sat, 1 Sep 2001 14:20:43 +1000 Message-Id: <200109010420.f814KhY32589@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com Subject: Standard EA names From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I am creating a VFS solution that relies on EA to a heavy degree. I am wondering if there is a EA naming convention forum out there? For example, the GPG guys might decide what the attr name of a sig block should be? I will probably make up names myself using something like the emacs-naming-scheme that I have been using for read only generated EA so far in ferris. Just thought I'd ask incase there was already an effort in place for shared naming of handy attributes. ----------------------------------------------------- Ask not what you can do for your VFS, http://witme.sourceforge.net/libferris.web/