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.