From owner-linux-xfs@oss.sgi.com Mon Jul 1 00:25:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g617PGnC012329 for ; Mon, 1 Jul 2002 00:25:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g617PG8n012328 for linux-xfs-outgoing; Mon, 1 Jul 2002 00:25:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g617P1nC012293 for ; Mon, 1 Jul 2002 00:25:02 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id 1998CC2B0 for ; Mon, 1 Jul 2002 09:28:45 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA12084 for linux-xfs@oss.sgi.com; Mon, 1 Jul 2002 09:28:43 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 625CB57306 for ; Mon, 1 Jul 2002 09:28:33 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 1A0BA25835 for ; Mon, 1 Jul 2002 09:28:33 +0200 (CEST) Message-ID: <3D2004A1.BE4C7C7@ch.sauter-bc.com> Date: Mon, 01 Jul 2002 09:28:33 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: Crash and some more problems Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi One of my servers running RedHat 7.2-XFS with kernel 2.4.9-34SGI_XFS_1.1 has crashed yesterday. With crash I mean really dead, nothing in the logs, no keyboard leds, no output on the console. I don't know what happened, my only guess is that temperature was getting too high for this quite old box. Unfortunately there were two more things: 1) When I restarted the box (after cooling it down), it started all the soft raid devices, mounted root and died again when 'mounting local filesystems'. HD leds kept flashing which means the raid was synced but everything else was dead. I finally booted with 'lilo init=/bin/sh', waited for all raid devices to finish sync. I mounted and unmounted all filesystems to replay logs, ran xfs_repair on them without showing up any problem. I have then rebooted and it came up as expected. 2) I have checked the filesystems and logs. Everything seems fine except that I found some lines of /var/log/messages in the file /var/log/squid/store.log from squid. Not really nice from a security point of view. Any comments? Simon file /etc/fstab: LABEL=/boot /boot xfs defaults 1 2 /dev/md1 / xfs defaults 1 1 LABEL=/var /var xfs defaults 1 2 LABEL=/tmp /tmp xfs defaults 1 2 LABEL=/opt /opt xfs defaults 1 2 LABEL=/usr /usr xfs defaults 1 2 LABEL=/home /home xfs defaults,logdev=/dev/md9 1 2 /dev/md6 swap swap defaults,pri=0 0 0 /dev/md3 swap swap defaults,pri=0 0 0 file /proc/mdstat: Personalities : [raid1] [raid5] read_ahead 1024 sectors md8 : active raid5 hde10[0] hdf7[2] hdg10[1] hdh7[3] 31406976 blocks level 5, 128k chunk, algorithm 0 [4/4] [UUUU] md7 : active raid1 hdf6[0] hdh6[1] 1024000 blocks [2/2] [UU] md5 : active raid1 hdf5[0] hdh5[1] 3072256 blocks [2/2] [UU] md9 : active raid1 hdf1[0] hdh1[1] 102720 blocks [2/2] [UU] md6 : active raid1 hde9[0] hdg9[1] 1024000 blocks [2/2] [UU] md4 : active raid1 hde8[0] hdg8[1] 511936 blocks [2/2] [UU] md3 : active raid1 hde7[0] hdg7[1] 511936 blocks [2/2] [UU] md2 : active raid1 hde6[0] hdg6[1] 1755328 blocks [2/2] [UU] md1 : active raid1 hde5[0] hdg5[1] 292672 blocks [2/2] [UU] md0 : active raid1 hde1[0] hdg1[1] 102720 blocks [2/2] [UU] unused devices: From owner-linux-xfs@oss.sgi.com Mon Jul 1 04:53:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61BrZnC032108 for ; Mon, 1 Jul 2002 04:53:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61BrZuW032107 for linux-xfs-outgoing; Mon, 1 Jul 2002 04:53:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.visp.co.nz (mail.visp.co.nz [210.55.24.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61BrNnC032069 for ; Mon, 1 Jul 2002 04:53:25 -0700 Received: from localhost.localdomain (210-54-175-12.visp.co.nz [210.54.175.12] (may be forged)) by mail.visp.co.nz (8.11.1/8.11.1) with ESMTP id g61BvCP01026 for ; Mon, 1 Jul 2002 23:57:12 +1200 (NZST) Subject: Error: uffix or operands invalid for `bsf' From: mdew To: xfs Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+Fi4AV5wgx0dwSIF8g+o" X-Mailer: Ximian Evolution 1.0.7 Date: 01 Jul 2002 23:54:40 +1200 Message-Id: <1025524486.3196.2.camel@mdew> Mime-Version: 1.0 X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-+Fi4AV5wgx0dwSIF8g+o Content-Type: text/plain Content-Transfer-Encoding: quoted-printable While making the latest linux-2.4-xfs tree...I came across this error. make[4]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs/pagebuf' gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O3 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=3D2 -march=3Di686=20 -I.. -nostdinc -I /usr/lib/gcc-lib/i386-linux/3.1.1/include -DKBUILD_BASENAME=3Dpage_buf_locking -c -o page_buf_locking.o page_buf_locking.c {standard input}: Assembler messages: {standard input}:416: Error: suffix or operands invalid for `bsf' make[4]: *** [page_buf_locking.o] Error 1 make[4]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs/pagebuf' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs/pagebuf' make[2]: *** [_subdir_pagebuf] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' make[1]: *** [_subdir_xfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' make: *** [_dir_fs] Error 2 Debian Sid/GCC 3.1.1pre2/Binutils 2.12.90.0.9-1 --=20 ph33r! Linux mdew 2.4.19-rc1-xfs #5 Tue Jun 25 17:35:28 NZST 2002 i686 unknown GPG Key: http://mdew.orcon.net.nz/gpg --=-+Fi4AV5wgx0dwSIF8g+o Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9IEMAH5J/xul0J+4RAtSpAKCMn3eKZsJJ8p+TSuD1Rn42XrHwBACcCFBE nvYNYCVHhNUgeh/bmp2BMWU= =I2lJ -----END PGP SIGNATURE----- --=-+Fi4AV5wgx0dwSIF8g+o-- From owner-linux-xfs@oss.sgi.com Mon Jul 1 16:16:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61NGenC021406 for ; Mon, 1 Jul 2002 16:16:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61NGe1h021405 for linux-xfs-outgoing; Mon, 1 Jul 2002 16:16:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61NGWnC021377 for ; Mon, 1 Jul 2002 16:16:33 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 QAA02847 for ; Mon, 1 Jul 2002 16:20:22 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA16357; Tue, 2 Jul 2002 09:19:01 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g61NI23K002871; Tue, 2 Jul 2002 09:18:02 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g61NI1vp002869; Tue, 2 Jul 2002 09:18:01 +1000 Date: Tue, 2 Jul 2002 09:18:01 +1000 From: Nathan Scott To: John Stevens Cc: linux-xfs@oss.sgi.com Subject: Re: XFS NFS and umask Message-ID: <20020701231801.GC469@frodo> References: <00bd01c21bfe$1a547160$6401a8c0@fatboy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00bd01c21bfe$1a547160$6401a8c0@fatboy> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 24, 2002 at 09:09:28PM -0700, John Stevens wrote: > I am running kernel 2.4.18 XFS, a clean install using the SGI installer. I > have searched the archive for a solution to the umask not being set properly > on NFS mounted volumes. I am mounting the Linux box on multiple Onyx and > Onyx 2, is there a solution to this problem?? We've recently discussed a solution to this which the ext2/ext3 patch maintainer is using - we will do a similar thing to that. This change should go into CVS later today. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jul 1 17:34:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g620YlnC022093 for ; Mon, 1 Jul 2002 17:34:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g620Ylkd022092 for linux-xfs-outgoing; Mon, 1 Jul 2002 17:34:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g620YZnC022063 for ; Mon, 1 Jul 2002 17:34:35 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 RAA05946 for ; Mon, 1 Jul 2002 17:38:26 -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 KAA05855 for linux-xfs@oss.sgi.com; Tue, 2 Jul 2002 10:36:15 +1000 (EST) Date: Tue, 2 Jul 2002 10:36:15 +1000 (EST) From: Nathan Scott Message-Id: <200207020036.KAA05855@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ACLs X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Several changes to reduce the overlap we have with the rest of the kernel due to ACLs - eg. we no longer add a new field to the struct super_block. Also use Andreas' idea to work around the problems in our handling of the umask/mode for inodes coming to us from NFS. cheers. Date: Mon Jul 1 17:12:19 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/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:122601a linux/include/linux/posix_acl_xattr.h - 1.1 - the minimal types and macros we need in order to support the posix_acl extended attributes. linux/include/linux/fs.h - 1.151 - remove use of additional s_xattr_flags, use the existing inode flags field instead if ACLs are enabled. linux/fs/namei.c - 1.44 - use a naming scheme consistent with the other inode flags. linux/fs/xfs/linux/xfs_linux.h - 1.75 - rework acl headers so that only one, simpler acl header is needed. linux/fs/xfs/linux/xfs_vnode.c - 1.84 linux/fs/xfs/linux/xfs_super.c - 1.185 - remove use of additional s_xattr_flags, use the existing inode flags field instead if ACLs are enabled. linux/fs/xfs/linux/xfs_iops.c - 1.154 - use a naming scheme consistent with the other inode flags. fix for the NFS umask problem as suggested by AndreasG. linux/fs/xfs/xfs_acl.h - 1.16 - remove use of additional s_xattr_flags, use the existing inode flags field instead if ACLs are enabled. changes to ACL type names and macros so that we can keep external-to-xfs headers much simpler. linux/fs/xfs/xfs_acl.c - 1.28 - changes to ACL type names and macros so that we can keep external headers (to xfs) much simpler. linux/fs/xfs/linux/xfs_xattr.c - 1.14 - sync revalidate changes with 2.5 (?), small change to some ACL macros so that we can keep external-to-xfs headers simpler. linux/fs/xattr.c - 1.7 - fix copyright info - we get this file from Linus only, so don't make local changes to it. linux/include/linux/acl_ea.h - 1.3 linux/include/linux/posix_acl.h - 1.3 - rationalise this header (removed). From owner-linux-xfs@oss.sgi.com Mon Jul 1 18:50:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g621o1nC022752 for ; Mon, 1 Jul 2002 18:50:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g621o1fW022751 for linux-xfs-outgoing; Mon, 1 Jul 2002 18:50:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g621npnC022718 for ; Mon, 1 Jul 2002 18:49:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 SAA01678 for ; Mon, 1 Jul 2002 18:53:42 -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 LAA19074; Tue, 2 Jul 2002 11:51:17 +1000 (EST) Date: Tue, 2 Jul 2002 11:51:17 +1000 (EST) From: Nathan Scott Message-Id: <200207020151.LAA19074@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, lachlan@adacel.com.au Subject: TAKE - experimental capabilities code X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Early days for capability support, but this will be helpful to people investigating this stuff. cheers. Date: Sun Jun 30 18:18:23 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122587a cmd/xfsprogs/doc/CHANGES - 1.71 cmd/xfsprogs/mkfs/proto.c - 1.8 - Fix typo in mkfs realtime summary inode alloc failure message. Date: Mon Jul 1 18:36:32 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:122603a linux/include/linux/posix_cap_xattr.h - 1.1 - initial, experimental structure definitions for capability extended attribute. almost guaranteed that this will change... linux/fs/xfs/xfs_cap.c - 1.1 - initial version of the backend filesystem code which converts ondisk extended attribute format to the kernels native capability structure. lots to do here still, not yet functional. linux/fs/xfs/Makefile - 1.146 linux/fs/xfs/Makefile.in - 1.19 - we now have a valid xfs_cap.c target. linux/fs/xfs/xfs_mac.h - 1.4 linux/fs/xfs/xfs_mac.c - 1.3 - add trivial, missing xfs_mac_vhaslabel routine. linux/fs/xfs/linux/xfs_xattr.c - 1.15 - remove hack workaround for missing capabilities and mac code. linux/fs/xfs/xfs_cap.h - 1.2 - provide some of the missing capabilities code from the filesystem specific point of view. lots to do here still, not yet functional. From owner-linux-xfs@oss.sgi.com Mon Jul 1 23:45:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g626jpnC029532 for ; Mon, 1 Jul 2002 23:45:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g626jpXl029531 for linux-xfs-outgoing; Mon, 1 Jul 2002 23:45:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g626jhnC029496 for ; Mon, 1 Jul 2002 23:45:44 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g626nVR19069 for ; Tue, 2 Jul 2002 15:49:31 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g626nUa11890 for ; Tue, 2 Jul 2002 15:49:30 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g626nSN22913 for ; Tue, 2 Jul 2002 15:49:28 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA510 for ; Tue, 2 Jul 2002 15:49:27 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Tue Jul 02 15:49:26 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g626nRA28528; Tue, 2 Jul 2002 15:49:27 +0900 (JST) Received: from NEC4D4BGTKMOBI (TNES017100.bsd.tnes.nec.co.jp [10.1.104.62]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id g626nRY32718; Tue, 2 Jul 2002 15:49:27 +0900 Message-ID: <00a301c22194$9bb063e0$3e68010a@bsd.tnes.nec.co.jp> From: "Hiroyuki Nakano" To: "Stephen Lord" Cc: References: <014201c21e70$611e47a0$3e68010a@bsd.tnes.nec.co.jp> <1025270852.1090.4.camel@n236> Subject: Re: XFS force shutdown : EFSCORRUPTED Date: Tue, 2 Jul 2002 15:49:26 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, I wanted to confirm XFS commands are executed to normaly on mounted device. So I tried to access to mounted device. Now I see commands are no problem to executed on mounted device. Thanks a lot. -nak > > I happened to be sitting next to another filesystem developer > when I read this, and he remembered an old ext2 race condition. > I think I understand what is happening - and how to fix it, the > only problem is that fixing it will potentially be a major > performance issue - so the question is, why do you need this to > work? Would a solution which disallowed block access to the > device when it was mounted be sufficient, or do you really > want to look at metadata live via the block device. The > xfsdump program does not need this, the only thing which does > is running xfs_db on a live filesystem, but that is not really > of use to anyone but developers. > > Steve > From owner-linux-xfs@oss.sgi.com Tue Jul 2 14:36:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62LawRw026073 for ; Tue, 2 Jul 2002 14:36:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62LawBT026072 for linux-xfs-outgoing; Tue, 2 Jul 2002 14:36:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62LaqRw026044 for ; Tue, 2 Jul 2002 14:36:52 -0700 Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by deliverator.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 OAA06579 for ; Tue, 2 Jul 2002 14:40:45 -0700 (PDT) mail_from (akpm@zip.com.au) Received: from nowaydude.rearden.com ([64.160.169.126] helo=zip.com.au) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 17PVJG-0006dm-00; Tue, 02 Jul 2002 22:35:42 +0100 Message-ID: <3D221C40.CFA7C46E@zip.com.au> Date: Tue, 02 Jul 2002 14:33:52 -0700 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: [PATCH] fix qsort breakage References: <20020504121512.A8534@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph Hellwig wrote: > > Qsort in the XFS tree has two problems: > > o allocates memory using GFP_KERNEL although called from under i_sem > (possible deadlock) The page allocator will never take an i_sem. Note how generic_file_write() performs tons of GFP_HIGHUSER allocations inside i_sem. No deadlocks there. qsort should take gfp_flags as an argument. Or not perform any allocation, as you've described. But the code seems OK as-is. Suggest you stick with the more robust GFP_KERNEL. (It'd be nice to stick that qsort in lib/qsort.c, rather than making it XFS-private, btw). - From owner-linux-xfs@oss.sgi.com Tue Jul 2 21:57:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g634vVRw013994 for ; Tue, 2 Jul 2002 21:57:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g634vV2G013993 for linux-xfs-outgoing; Tue, 2 Jul 2002 21:57:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g634vBRw013960 for ; Tue, 2 Jul 2002 21:57:12 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g63513R19956 for ; Wed, 3 Jul 2002 14:01:03 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g63512r11957 for ; Wed, 3 Jul 2002 14:01:02 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g6350tN04740 for ; Wed, 3 Jul 2002 14:01:00 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA370 for ; Wed, 3 Jul 2002 14:00:54 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Jul 03 14:00:53 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g6350sA36874 for ; Wed, 3 Jul 2002 14:00:54 +0900 (JST) Received: from tnes007164.tnes.nec.co.jp (TNES017301.bsd.tnes.nec.co.jp [10.1.104.178]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id g6350sY12402 for ; Wed, 3 Jul 2002 14:00:54 +0900 Message-Id: <200207030501.AA00767@tnes007164.tnes.nec.co.jp> Date: Wed, 03 Jul 2002 14:01:42 +0900 To: linux-xfs@oss.sgi.com Subject: mount as read-only and XFS commands From: Tatsu Yasugahira MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.11 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'd like to confirm the behavior of XFS. I found that the XFS command (xfs_growfs) changes the filesystem which is mounted by read-only. This phenomenon occurs on the read-only filesystem and on the filesystem that goes to read-only by the remount operation. I think it should be the error with EROFS or EBUSY. How do you think? -------- I did the following (tp_readonly.sh) : MNT=/mnt/xfs DEV=/dev/hda8 mkfs -t xfs -f $DEV -d size=12000b mount -t xfs -o ro $DEV $MNT xfs_growfs -d $MNT xfs_growfs -n $MNT umount $MNT mount -t xfs $DEV $MNT This results in the following messages: + MNT=/mnt/xfs + DEV=/dev/hda8 + mkfs.xfs -f /dev/hda8 -d size=12000b meta-data=/dev/hda8 isize=256 agcount=2, agsize=6000 blks data = bsize=4096 blocks=12000, 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 + mount -t xfs -o ro /dev/hda8 /mnt/xfs XFS mounting filesystem ide0(3,8) + xfs_growfs -d /mnt/xfs meta-data=/mnt/xfs isize=256 agcount=2, agsize=6000 blks data = bsize=4096 blocks=12000, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 data blocks changed from 12000 to 2797310 + xfs_growfs -n /mnt/xfs meta-data=/mnt/xfs isize=256 agcount=467, agsize=6000 blks data = bsize=4096 blocks=2797310, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 + umount /mnt/xfs + mount -t xfs /dev/hda8 /mnt/xfs XFS mounting filesystem ide0(3,8) Starting XFS recovery on filesystem: ide0(3,8) (dev: 3/8) Ending XFS recovery on filesystem: ide0(3,8) (dev: 3/8) I did the following (tp_remount.sh): MNT=/mnt/xfs DEV=/dev/hda8 mkfs -t xfs -f $DEV -d size=12000b mount -t xfs $DEV $MNT xfs_growfs -n $MNT xfs_growfs -d $MNT & sleep 2 mount -t xfs -o remount -o ro $DEV $MNT sleep 10 xfs_growfs -n $MNT umount $MNT mount -t xfs $DEV $MNT This results in the following messages: + MNT=/mnt/xfs + DEV=/dev/hda8 + mkfs.xfs -f /dev/hda8 -d size=12000b meta-data=/dev/hda8 isize=256 agcount=2, agsize=6000 blks data = bsize=4096 blocks=12000, 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 + mount -t xfs /dev/hda8 /mnt/xfs XFS mounting filesystem ide0(3,8) + xfs_growfs -n /mnt/xfs meta-data=/mnt/xfs isize=256 agcount=2, agsize=6000 blks data = bsize=4096 blocks=12000, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 + sleep 2 + xfs_growfs -d /mnt/xfs meta-data=/mnt/xfs isize=256 agcount=2, agsize=6000 blks data = bsize=4096 blocks=12000, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 + mount -t xfs -o remount -o ro /dev/hda8 /mnt/xfs + sleep 10 data blocks changed from 12000 to 2797310 + xfs_growfs -n /mnt/xfs meta-data=/mnt/xfs isize=256 agcount=467, agsize=6000 blks data = bsize=4096 blocks=2797310, imaxpct=25 XFS mounting filesystem ide0(3,8) = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 + umount /mnt/xfs + mount -t xfs /dev/hda8 /mnt/xfs Starting XFS recovery on filesystem: ide0(3,8) (dev: 3/8) Ending XFS recovery on filesystem: ide0(3,8) (dev: 3/8) ---------- Running 2.4.18-xfs in this case. Thanks and Regards tatsu From owner-linux-xfs@oss.sgi.com Wed Jul 3 07:05:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g63E56Rw004726 for ; Wed, 3 Jul 2002 07:05:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g63E56nm004725 for linux-xfs-outgoing; Wed, 3 Jul 2002 07:05:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g63E4wRw004679 for ; Wed, 3 Jul 2002 07:04:59 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA92290; Wed, 3 Jul 2002 09:08:51 -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 JAA43240; Wed, 3 Jul 2002 09:08:50 -0500 (CDT) Date: Wed, 3 Jul 2002 09:08:33 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Tatsu Yasugahira cc: linux-xfs@oss.sgi.com Subject: Re: mount as read-only and XFS commands In-Reply-To: <200207030501.AA00767@tnes007164.tnes.nec.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi - I think it depends on how you define "read only" - read-only usually implies that you cannot alter the data on a filesystem. I don't know whether it should apply to the underlying geometry of the filesystem. Since the growfs operation leaves the data on the filesystem unchanged, I don't see any problem with xfs_growfs on a read-only fs. I'm also fairly certain that this matches Irix behavior, but I'll have to check. -Eric On Wed, 3 Jul 2002, Tatsu Yasugahira wrote: > Hi, > > I'd like to confirm the behavior of XFS. > > I found that the XFS command (xfs_growfs) changes the filesystem > which is mounted by read-only. > This phenomenon occurs on the read-only filesystem and > on the filesystem that goes to read-only by the remount operation. > > I think it should be the error with EROFS or EBUSY. > From owner-linux-xfs@oss.sgi.com Wed Jul 3 11:54:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g63IsdRw016158 for ; Wed, 3 Jul 2002 11:54:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g63Isd5o016157 for linux-xfs-outgoing; Wed, 3 Jul 2002 11:54:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf16bis.bellsouth.net (mail116.mail.bellsouth.net [205.152.58.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g63IsXRw016126 for ; Wed, 3 Jul 2002 11:54:34 -0700 Received: from taz ([66.156.0.229]) by imf16bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020703185958.JPRF9213.imf16bis.bellsouth.net@taz> for ; Wed, 3 Jul 2002 14:59:58 -0400 Date: Wed, 3 Jul 2002 14:48:39 -0400 From: Greg Freemyer Subject: Getting past 2 TB in Linux To: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020703185958.JPRF9213.imf16bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g63IsYRw016130 X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As an FYI, I just came across this msg. http://old.lwn.net/2002/0516/a/2tb-2.php3 It is about a VA Linux engineer working on a set of patches to Linux 2.4.17 to get past the 2 TB limitation. He is using XFS as the filesystem, but I don't think any of the patches are XFS related. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Jul 3 23:46:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g646kpRw009146 for ; Wed, 3 Jul 2002 23:46:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g646koV7009145 for linux-xfs-outgoing; Wed, 3 Jul 2002 23:46:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g646keRw009115 for ; Wed, 3 Jul 2002 23:46:41 -0700 Received: from octopus.india.hp.com (octopus.india.hp.com [15.76.114.34]) by atlrel9.hp.com (Postfix) with ESMTP id D2F7FE00599; Thu, 4 Jul 2002 02:50:22 -0400 (EDT) Received: from nt17106 (nt17106.india.hp.com [15.76.117.106]) by octopus.india.hp.com with SMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id MAA15316; Thu, 4 Jul 2002 12:20:57 +0530 (IST) Reply-To: From: "Zameer M" To: , Subject: kernel panicked when mounting XFS LVM volumes on kernel-2.4.17-ia64 Date: Thu, 4 Jul 2002 12:20:14 +0530 Message-ID: <00fa01c22327$0de25a70$6a754c0f@india.hp.com> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Kernel panicked when mounting XFS LVM volumes. The following is configuration used. 1)kernel-2.4.17 2)linux-2.4.17-ia64-011226.diff 3)linux-2.4.17-xfs-2002-02-07.cvs-patch 4)lvm-1.1-rc1 new# mount -t xfs /dev/volg00/lvol1 /xfs Segmentation fault Jul 4 11:09:49 new kernel: I/O error in filesystem ("lvm(58,0)") meta-data dev 0x0 block 0x0 Jul 4 11:09:49 new kernel: ("xfs_read_buf") error 1023875264 buf count 0 Jul 4 11:09:49 new kernel: Unable to handle kernel NULL pointer dereferencemount[715]: Oops 8804682956800 Jul 4 11:09:49 new kernel: Jul 4 11:09:49 new kernel: Pid: 715, comm: mount Jul 4 11:09:49 new kernel: psr : 0000101008022018 ifs : 8000000000000004 ip : [xfs_reclaim+1280/1344] Not tainted Jul 4 11:09:49 new kernel: psr : 0000101008022018 ifs : 8000000000000004 ip : [] Not tainted Jul 4 11:09:49 new kernel: unat: 0000000000000000 pfs : 000000000000040c rsc : 0000000000000003 Jul 4 11:09:49 new kernel: rnat: 3736353433323130 bsps: e00000003bef7870 pr : 69566a668996a957 Jul 4 11:09:49 new kernel: ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f Jul 4 11:09:49 new kernel: b0 : e0000000046f8d90 b6 : e0000000049840c0 b7 : e000000004987820 LVM is working well with ext2 filesystem. Is it a XFS problem? Regards zameer From owner-linux-xfs@oss.sgi.com Thu Jul 4 00:43:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g647hwRw010967 for ; Thu, 4 Jul 2002 00:43:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g647hwWY010966 for linux-xfs-outgoing; Thu, 4 Jul 2002 00:43:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g647hpRw010912 for ; Thu, 4 Jul 2002 00:43:51 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g647llR07054 for ; Thu, 4 Jul 2002 16:47:47 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g647llr20801 for ; Thu, 4 Jul 2002 16:47:47 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g647liN00220 for ; Thu, 4 Jul 2002 16:47:46 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA495 for ; Thu, 4 Jul 2002 16:47:42 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Thu Jul 04 16:47:40 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g647lbA39638; Thu, 4 Jul 2002 16:47:37 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g647lbY10236; Thu, 4 Jul 2002 16:47:37 +0900 To: zameer@india.hp.com Cc: linux-lvm@sistina.com, linux-xfs@oss.sgi.com Subject: Re: kernel panicked when mounting XFS LVM volumes on kernel-2.4.17-ia64 In-Reply-To: <00fa01c22327$0de25a70$6a754c0f@india.hp.com> References: <00fa01c22327$0de25a70$6a754c0f@india.hp.com> References: <200203250337.OAA55079@snort.melbourne.sgi.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Honest Recruiter) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020704164737N.masano@tnes.nec.co.jp> Date: Thu, 04 Jul 2002 16:47:37 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 26 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, From: "Zameer M" Subject: kernel panicked when mounting XFS LVM volumes on kernel-2.4.17-ia64 Date: Thu, 4 Jul 2002 12:20:14 +0530 Message-ID: <00fa01c22327$0de25a70$6a754c0f@india.hp.com> > Hi, > > Kernel panicked when mounting XFS LVM volumes. > > The following is configuration used. > 1)kernel-2.4.17 > 2)linux-2.4.17-ia64-011226.diff > 3)linux-2.4.17-xfs-2002-02-07.cvs-patch > 4)lvm-1.1-rc1 If your box's page size is larger than 4KB, use more recent CVS tree (at least after 25th March) or change _pagebuf_page_io() in linux/fs/pagebuf/page_buf.c as follows. from: struct buffer_head *bh, *bufferlist[8]; to: struct buffer_head *bh, *bufferlist[PAGE_SIZE/512]; -- Masano From owner-linux-xfs@oss.sgi.com Thu Jul 4 09:12:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64GCVRw009490 for ; Thu, 4 Jul 2002 09:12:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64GCVlc009489 for linux-xfs-outgoing; Thu, 4 Jul 2002 09:12:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64GCORw009461 for ; Thu, 4 Jul 2002 09:12:25 -0700 Received: from offline.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 17Q9H4-0000xX-00; Thu, 04 Jul 2002 17:16:06 +0100 Message-ID: <3D2474C6.461E618@moving-picture.com> Date: Thu, 04 Jul 2002 17:16:06 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: nfs@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: NFS server stalls with 2.4.18 + XFS 1.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We have noticed a problem with a couple of our NFS servers (running RedHat 7.2 with a stock 2.4.18 kernel with XFS v1.1) whereby NFS access slows to a crawl or stalls. The exported filesystem(s) are XFS with 8 nfsd's running - when we have the problem the load average is about 8 - but CPU usage, disk access and network traffic are minimal. I found, by accident, that running the command 'sync' appears to 'fix' the situation... I'm not sure if this is an XFS or NFS related problem (hence posting to both lists). Thanks James Pearson From owner-linux-xfs@oss.sgi.com Thu Jul 4 15:36:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64Ma4Rw020750 for ; Thu, 4 Jul 2002 15:36:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64Ma4w2020749 for linux-xfs-outgoing; Thu, 4 Jul 2002 15:36:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64MZtRw020717 for ; Thu, 4 Jul 2002 15:35:57 -0700 Received: (qmail 10136 invoked from network); 4 Jul 2002 22:39:58 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 4 Jul 2002 22:39:58 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 02F423000BA; Fri, 5 Jul 2002 08:39:55 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D28D4A0; Fri, 5 Jul 2002 08:39:55 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: James Pearson Cc: nfs@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: Re: NFS server stalls with 2.4.18 + XFS 1.1 In-reply-to: Your message of "Thu, 04 Jul 2002 17:16:06 +0100." <3D2474C6.461E618@moving-picture.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jul 2002 08:39:50 +1000 Message-ID: <18036.1025822390@ocs3.intra.ocs.com.au> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 04 Jul 2002 17:16:06 +0100, James Pearson wrote: >We have noticed a problem with a couple of our NFS servers (running >RedHat 7.2 with a stock 2.4.18 kernel with XFS v1.1) whereby NFS access >slows to a crawl or stalls. > >The exported filesystem(s) are XFS with 8 nfsd's running - when we have >the problem the load average is about 8 - but CPU usage, disk access and >network traffic are minimal. > >I found, by accident, that running the command 'sync' appears to 'fix' >the situation... > >I'm not sure if this is an XFS or NFS related problem (hence posting to >both lists). XFS. 2.4.18 would sometimes get into a situation where two XFS operations were waiting on locks (not deadlocked) and nothing was moving. Performing some other disk activity such as sync would get things moving again. AFAICT this is fixed in the XFS CVS tree, against 2.4.19-rc1. From owner-linux-xfs@oss.sgi.com Thu Jul 4 21:31:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g654VaRw027047 for ; Thu, 4 Jul 2002 21:31:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g654VamN027046 for linux-xfs-outgoing; Thu, 4 Jul 2002 21:31:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g654VKRw027004 for ; Thu, 4 Jul 2002 21:31:20 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 VAA03509 for ; Thu, 4 Jul 2002 21:35:25 -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 OAA26330; Fri, 5 Jul 2002 14:31:25 +1000 (EST) Date: Fri, 5 Jul 2002 14:31:25 +1000 (EST) From: Nathan Scott Message-Id: <200207050431.OAA26330@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: quintela@mandrakesoft.com, ag@bestbits.at Subject: TAKE - userspace build, Alpha syscalls X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This allows the configure path-options to be used and simplifies the configure scripts a 'lil bit in doing so. It'd be a good idea to do a "make distclean" when rebuilding these for the configure.in update to take effect. Hopefully nothing will break here, but it might ... let me know. The extended attribute and ACL userspace tools should start working for Alpha users now (the syscall numbers have been assigned on 2.5; for 2.4 you'd need to backport the syscall table updates, as is the case for most other architectures). cheers. Date: Thu Jul 4 21:16:49 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122627a cmd/attr/libattr/Makefile - 1.9 cmd/attr/libattr/syscalls.c - 1.13 - Add in syscall numbers for the Alpha architecture; bump the library .so version number (1.0.0->1.0.1). cmd/acl/configure.in - 1.17 cmd/acl/Makepkgs - 1.6 cmd/acl/Makefile - 1.13 cmd/acl/VERSION - 1.31 cmd/acl/doc/CHANGES - 1.36 cmd/acl/build/rpm/acl.spec.in - 1.7 cmd/acl/include/builddefs.in - 1.20 cmd/acl/debian/changelog - 1.26 cmd/acl/debian/rules - 1.8 cmd/attr/configure.in - 1.9 cmd/attr/Makepkgs - 1.5 cmd/attr/Makefile - 1.8 cmd/attr/VERSION - 1.20 cmd/attr/doc/CHANGES - 1.23 cmd/attr/build/rpm/attr.spec.in - 1.9 cmd/attr/include/builddefs.in - 1.17 cmd/attr/debian/changelog - 1.21 cmd/attr/debian/rules - 1.7 cmd/xfsprogs/configure.in - 1.13 cmd/xfsprogs/Makepkgs - 1.6 cmd/xfsprogs/Makefile - 1.13 cmd/xfsprogs/VERSION - 1.49 cmd/xfsprogs/doc/CHANGES - 1.72 cmd/xfsprogs/build/rpm/xfsprogs.spec.in - 1.12 cmd/xfsprogs/include/builddefs.in - 1.22 cmd/xfsprogs/debian/changelog - 1.47 cmd/xfsprogs/debian/rules - 1.13 cmd/xfsdump/configure.in - 1.19 cmd/xfsdump/Makepkgs - 1.4 cmd/xfsdump/Makefile - 1.9 cmd/xfsdump/VERSION - 1.34 cmd/xfsdump/doc/CHANGES - 1.42 cmd/xfsdump/build/rpm/xfsdump.spec.in - 1.10 cmd/xfsdump/include/builddefs.in - 1.17 cmd/xfsdump/debian/changelog - 1.24 cmd/xfsdump/debian/rules - 1.7 cmd/dmapi/configure.in - 1.14 cmd/dmapi/Makepkgs - 1.5 cmd/dmapi/Makefile - 1.7 cmd/dmapi/VERSION - 1.14 cmd/dmapi/doc/CHANGES - 1.13 cmd/dmapi/build/rpm/dmapi.spec.in - 1.12 cmd/dmapi/include/builddefs.in - 1.16 cmd/dmapi/debian/changelog - 1.14 cmd/dmapi/debian/rules - 1.6 cmd/dmapi/include/buildmacros - 1.4 cmd/xfsprogs/include/buildmacros - 1.4 cmd/acl/include/buildmacros - 1.4 cmd/attr/include/buildmacros - 1.4 cmd/xfsdump/include/buildmacros - 1.4 - Build infrastructure updates so that configure options can be used to specify paths rather than semi-hard-coded path names controlled by the PREFIX/ROOT_PREFIX environment variables; eg. now allows /lib64 and /lib32 as alternate library install paths, which some folks need. From owner-linux-xfs@oss.sgi.com Thu Jul 4 23:52:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g656qCRw001133 for ; Thu, 4 Jul 2002 23:52:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g656qCQO001132 for linux-xfs-outgoing; Thu, 4 Jul 2002 23:52:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g656q0Rw001098 for ; Thu, 4 Jul 2002 23:52:01 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 76BACC6E262; Fri, 5 Jul 2002 16:56:05 +1000 (EST) Date: Fri, 5 Jul 2002 16:56:05 +1000 From: Ian Cumming To: linux-xfs@oss.sgi.com Subject: setquota on Debian (testing) Message-ID: <20020705065605.GA1820@ids.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've just noticed some weirdness with setquota on my debian (testing) machine. Basically, setquota is ignoring the soft and hard block limits on the command line. However, it is recognising the file limits. Here's an example: 1. before setquota: Disk quotas for user cprevost (uid 1202): Filesystem blocks quota limit grace files quota limit grace /dev/hda8 12 20480 25600 4 15000 20000 /dev/hdc5 99684 102400 122880 1549 17000 20000 2. setquota /usr/sbin/setquota -F xfs -u cprevost 256000 225280 17000 20000 /dev/hdc5 3. after setquota Same as 1. I found, however, that it was possible to edit the (number of) files quota on the command line with the setquota command. It is possible to set the quota with "edquota" via an editor. The changes made in the editor have the correct effect on the user's quota. I am running 2.4.18 with xfs-1.1, and it was only last week that setquota seemed to break. As I have not changed my kernel for since the 1.1 release, I'm suspecting that the recent testing/woody updates have broken something. I've tried rebuilding the xfs_cmds released with 1.1, however it has had no effect. Here's a list of the relevant xfs related software I have installed: ii xfs-xtt 1.3.0.xf420-4 X-TrueType font server ii xfsdump 2.0.1-1 Administrative utilities for the XFS filesys ii xfslibs-dev 2.0.3-1 XFS filesystem-specific static libraries and ii xfsprogs 2.0.3-1 Utilities for managing the XFS filesystem ii acl 2.0.9-1 Access control list utilities ii acl-dev 2.0.9-1 Access control list static libraries and hea ii libacl1 2.0.9-1 Access control list shared library ii attr 2.0.7-1 Utilities for manipulating filesystem extend ii attr-dev 2.0.7-1 Extended attribute static libraries and head ii libattr1 2.0.7-1 Extended attribute shared library ii quota 3.04-1 An implementation of the disk quota system. If anyone has any ideas how I can fix this, it would be greatly appreciated! (And make my automated quota scripts happy too! ;) Ian. -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 From owner-linux-xfs@oss.sgi.com Fri Jul 5 03:06:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g65A6ERw015520 for ; Fri, 5 Jul 2002 03:06:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g65A6EgQ015519 for linux-xfs-outgoing; Fri, 5 Jul 2002 03:06:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g65A67Rw015490 for ; Fri, 5 Jul 2002 03:06:08 -0700 Received: (qmail 13757 invoked from network); 5 Jul 2002 10:10:13 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Jul 2002 10:10:13 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id D8DBE3000BA; Fri, 5 Jul 2002 20:10:08 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 6700598; Fri, 5 Jul 2002 20:10:08 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: James Pearson Cc: linux-xfs@oss.sgi.com Subject: Re: NFS server stalls with 2.4.18 + XFS 1.1 In-reply-to: Your message of "Fri, 05 Jul 2002 10:55:45 +0100." <3D256D21.400E6D9E@moving-picture.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jul 2002 20:10:03 +1000 Message-ID: <23440.1025863803@ocs3.intra.ocs.com.au> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 05 Jul 2002 10:55:45 +0100, James Pearson wrote: >Do you happen to know if the fix can be back ported to 2.4.18/XFS 1.1 ? >Where in the CVS code would I find the fix? I was hoping you would not ask that ;). The CVS tree has five months of changes since 2.4.18, both to XFS and to go from 2.4.18 to 2.4.19-rc1. I don't know which fix corrected this problem. Steve Lord might know but he is away until July 8, USA time. From owner-linux-xfs@oss.sgi.com Fri Jul 5 03:19:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g65AJYRw017187 for ; Fri, 5 Jul 2002 03:19:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g65AJYBi017186 for linux-xfs-outgoing; Fri, 5 Jul 2002 03:19:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g65AJPRw017156 for ; Fri, 5 Jul 2002 03:19:25 -0700 Received: from offline.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 17QPoY-0000uw-00; Fri, 05 Jul 2002 10:55:46 +0100 Message-ID: <3D256D21.400E6D9E@moving-picture.com> Date: Fri, 05 Jul 2002 10:55:45 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: NFS server stalls with 2.4.18 + XFS 1.1 References: <18036.1025822390@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Do you happen to know if the fix can be back ported to 2.4.18/XFS 1.1 ? Where in the CVS code would I find the fix? Thanks James Pearson Keith Owens wrote: > > On Thu, 04 Jul 2002 17:16:06 +0100, > James Pearson wrote: > >We have noticed a problem with a couple of our NFS servers (running > >RedHat 7.2 with a stock 2.4.18 kernel with XFS v1.1) whereby NFS access > >slows to a crawl or stalls. > > > >The exported filesystem(s) are XFS with 8 nfsd's running - when we have > >the problem the load average is about 8 - but CPU usage, disk access and > >network traffic are minimal. > > > >I found, by accident, that running the command 'sync' appears to 'fix' > >the situation... > > > >I'm not sure if this is an XFS or NFS related problem (hence posting to > >both lists). > > XFS. 2.4.18 would sometimes get into a situation where two XFS > operations were waiting on locks (not deadlocked) and nothing was > moving. Performing some other disk activity such as sync would get > things moving again. > > AFAICT this is fixed in the XFS CVS tree, against 2.4.19-rc1. From owner-linux-xfs@oss.sgi.com Fri Jul 5 14:58:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g65Lw1Rw013075 for ; Fri, 5 Jul 2002 14:58:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g65Lw1Il013074 for linux-xfs-outgoing; Fri, 5 Jul 2002 14:58:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g65LvmRw013044 for ; Fri, 5 Jul 2002 14:57:49 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA06147; Fri, 5 Jul 2002 17:01: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 RAA55207; Fri, 5 Jul 2002 17:01:51 -0500 (CDT) Date: Fri, 5 Jul 2002 17:01:12 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: hisaak@email.cz cc: linux-xfs@oss.sgi.com Subject: Re: New XFS Survey Response In-Reply-To: <200207052145.g65LjWDn012822@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi - Can you try running your oops through ksymoops manually? The oops output below looks a little odd. For starters, you said this happened after several minutes, but you show a couple log recovery functions in your stack, which doesn't make sense unless the kernel oopsed during mount. also, the mailing list at linux-xfs@oss.sgi.com is the best place to send these reports. Thanks, -Eric On Fri, 5 Jul 2002, hisaak@email.cz wrote: > Name: hisaak > Email: hisaak@email.cz > Company: > XFS version: SGI_XFS_1.1 > Number of machines: 1 > Std. Linux distribution: Redhat > Other Linux distribution: > Hardware: other > Total Number Systems: 1 > Total Number Server: 0 > Total Number Workstation: 1 > Average CPU count: 1 > Hard Drives: ide > Manufacturer(s): ibm, seagate > Storage amount: 51 - 100 GB > LVM: MD: true OTHER: NONE: > Tape Drive: > Comments: > I use xfs patches from http://oss.sgi.com/projects/xfs/patchlist.html for quite long time. When I tried them with 2.4.19-pre10 and 2.4.19-rc1 my system goes to trouble after several minutes of using xfs partition. > This partition is 10G raid1 md device. With linux 2.4.17 I saw no problem for many months. Now it hangs after two or three minutes with this error in /var/log/messages: > Jul 5 20:38:08 mrkvoslav kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000010e > Jul 5 20:38:08 mrkvoslav kernel: printing eip: > Jul 5 20:38:08 mrkvoslav kernel: c01bd6fd > Jul 5 20:38:08 mrkvoslav kernel: pde = 00000000 > Jul 5 20:38:08 mrkvoslav kernel: Oops: 0000 > Jul 5 20:38:08 mrkvoslav kernel: CPU: 0 > Jul 5 20:38:08 mrkvoslav kernel: EIP: 0010:[xfs_inobt_get_rec+3501/4688] Not tainted > Jul 5 20:38:08 mrkvoslav kernel: EIP: 0010:[c01bd6fd] Not tainted > Jul 5 20:38:08 mrkvoslav kernel: EFLAGS: 00010246 > Jul 5 20:38:08 mrkvoslav kernel: eax: c02ecb80 ebx: ffffffe8 ecx: c02e5530 edx: c02ecb80 > Jul 5 20:38:08 mrkvoslav kernel: esi: 00000000 edi: de55a838 ebp: de55a824 esp: dcd69e38 > Jul 5 20:38:08 mrkvoslav kernel: ds: 0018 es: 0018 ss: 0018 > Jul 5 20:38:08 mrkvoslav kernel: Process kdeinit (pid: 4165, stackpage=dcd69000) > Jul 5 20:38:08 mrkvoslav kernel: Stack: 00000000 00000000 f7228800 0000004b f22e1148 f70d64f0 c01d2d7c f7228800 > Jul 5 20:38:08 mrkvoslav kernel: 00000000 0100c9af 00000000 00000000 dcd69ec0 00000000 00000000 00000000 > Jul 5 20:38:08 mrkvoslav kernel: 00000008 00000004 dcc4741c c0123e71 e8e883c0 f70d6508 00000008 f70d64f0 > Jul 5 20:38:08 mrkvoslav kernel: Call Trace: [xlog_recover_do_trans+37916/70656] [c0123e71] [xlog_recover_do_trans+55661/70656] [xfs_symlink+37461/71072] [c013b6ed] > Jul 5 20:38:08 mrkvoslav kernel: Call Trace: [c01d2d7c] [c0123e71] [c01d72cd] [c01e2a75] [c013b6ed] > Jul 5 20:38:08 mrkvoslav kernel: [c013be71] [c013b43d] [c013c493] [c01393f4] [c0125212] [c010887c] > Jul 5 20:38:08 mrkvoslav kernel: [c010878b] > Jul 5 20:38:08 mrkvoslav kernel: > Jul 5 20:38:08 mrkvoslav kernel: Code: 66 83 bb 26 01 00 00 00 75 0f 66 83 a3 18 01 00 00 f7 53 e8 > > After this I must shutdown to get control over this partition again. :-( > > I didn't find better place to post this bug so sorry for this. > I hope I will get some answer to hisaak@email.cz. > From owner-linux-xfs@oss.sgi.com Fri Jul 5 15:50:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g65MoZRw013676 for ; Fri, 5 Jul 2002 15:50:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g65MoZbZ013675 for linux-xfs-outgoing; Fri, 5 Jul 2002 15:50:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mrkvoslav.ascs.muni.cz ([147.251.62.152]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g65MoFRw013633 for ; Fri, 5 Jul 2002 15:50:16 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mrkvoslav.ascs.muni.cz (Postfix) with ESMTP id 3B9AA20BFB; Sat, 6 Jul 2002 00:54:24 +0200 (CEST) Received: by mrkvoslav.ascs.muni.cz (Postfix, from userid 500) id 5C05320BED; Sat, 6 Jul 2002 00:54:22 +0200 (CEST) From: David =?iso-8859-2?q?Olszy=F1ski?= To: Eric Sandeen Subject: Re: New XFS Survey Response Date: Sat, 6 Jul 2002 00:54:21 +0200 User-Agent: KMail/1.4.2 Cc: linux-xfs@oss.sgi.com References: In-Reply-To: X-muni: filtrovani posty je humus, takze: penize, komerce, vydelek, firma, zakazka X-policie-CR: Neserte mi nebo nebo ukradnu, vyloupim, vysmirovani obcanu je nechutne, takze: bouchnu, znasilnim, zabiju, podpalim, umucim, podriznu, zapichnu a vubec vsechno X-echelon: do not copper! NSA, CIA, CI5, MI5, FBI, KGB, BIS, kua MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_LYSS8AHR8N3570AMGNQG" Message-Id: <200207060054.21838.hisaak@email.cz> X-Virus-Scanned: by AMaViS perl-11 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --------------Boundary-00=_LYSS8AHR8N3570AMGNQG Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dne so 6. =E8ervenec 2002 00:01 Eric Sandeen napsal(a): > Hi - > > Can you try running your oops through ksymoops manually?=20=20 I tried ksymoops /var/log/messages and attached output, hope it'll help you. > The oops output > below looks a little odd. For starters, you said this happened after > several minutes, but you show a couple log recovery functions in your > stack, which doesn't make sense unless the kernel oopsed during mount. It was just last entry in messages before shutdown. mount is ok and it real= ly=20 hangs after several accesses to files on this partition. hisaak --------------Boundary-00=_LYSS8AHR8N3570AMGNQG Content-Type: text/plain; charset="iso-8859-1"; name="xfs-ksymoops" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xfs-ksymoops" ksymoops 2.4.0 on i686 2.4.19-rc1-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.19-rc1-xfs/ (default) -m /boot/System.map-2.4.19-rc1-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Jul 1 09:52:09 mrkvoslav kernel: SGI XFS with ACLs, EAs, quota, no debug enabled Jul 1 09:52:10 mrkvoslav kernel: ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) Jul 2 11:05:18 mrkvoslav kernel: SGI XFS with ACLs, EAs, quota, no debug enabled Jul 2 11:05:18 mrkvoslav kernel: ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) Jul 3 18:18:57 mrkvoslav kernel: SGI XFS with ACLs, EAs, quota, no debug enabled Jul 3 18:18:58 mrkvoslav kernel: ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) Jul 4 16:22:45 mrkvoslav kernel: SGI XFS with ACLs, EAs, quota, no debug enabled Jul 4 16:22:45 mrkvoslav kernel: ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) Jul 4 19:39:13 mrkvoslav kernel: SGI XFS with ACLs, EAs, quota, no debug enabled Jul 4 19:39:14 mrkvoslav kernel: ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) Jul 5 20:02:43 mrkvoslav kernel: SGI XFS with ACLs, quota, no debug enabled Jul 5 20:02:43 mrkvoslav kernel: ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) Jul 5 20:38:08 mrkvoslav kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000010e Jul 5 20:38:08 mrkvoslav kernel: c01bd6fd Jul 5 20:38:08 mrkvoslav kernel: *pde = 00000000 Jul 5 20:38:08 mrkvoslav kernel: Oops: 0000 Jul 5 20:38:08 mrkvoslav kernel: CPU: 0 Jul 5 20:38:08 mrkvoslav kernel: EIP: 0010:[xfs_inobt_get_rec+3501/4688] Not tainted Jul 5 20:38:08 mrkvoslav kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Jul 5 20:38:08 mrkvoslav kernel: EFLAGS: 00010246 Jul 5 20:38:08 mrkvoslav kernel: eax: c02ecb80 ebx: ffffffe8 ecx: c02e5530 edx: c02ecb80 Jul 5 20:38:08 mrkvoslav kernel: esi: 00000000 edi: de55a838 ebp: de55a824 esp: dcd69e38 Jul 5 20:38:08 mrkvoslav kernel: ds: 0018 es: 0018 ss: 0018 Jul 5 20:38:08 mrkvoslav kernel: Process kdeinit (pid: 4165, stackpage=dcd69000) Jul 5 20:38:08 mrkvoslav kernel: Stack: 00000000 00000000 f7228800 0000004b f22e1148 f70d64f0 c01d2d7c f7228800 Jul 5 20:38:08 mrkvoslav kernel: 00000000 0100c9af 00000000 00000000 dcd69ec0 00000000 00000000 00000000 Jul 5 20:38:08 mrkvoslav kernel: 00000008 00000004 dcc4741c c0123e71 e8e883c0 f70d6508 00000008 f70d64f0 Jul 5 20:38:08 mrkvoslav kernel: Call Trace: [xlog_recover_do_trans+37916/70656] [] [xlog_recover_do_trans+55661/70656] [xfs_symlink+37461/71072] [] Jul 5 20:38:08 mrkvoslav kernel: Call Trace: [] [] [] [] [] Jul 5 20:38:08 mrkvoslav kernel: [] [] [] [] [] [] Jul 5 20:38:08 mrkvoslav kernel: [] Jul 5 20:38:08 mrkvoslav kernel: Code: 66 83 bb 26 01 00 00 00 75 0f 66 83 a3 18 01 00 00 f7 53 e8 >>EIP; c01bd6fd <===== Trace; c01d2d7c Trace; c0123e71 Trace; c01d72cd Trace; c01e2a75 Trace; c013b6ed Trace; c013be71 Trace; c013b43d Trace; c013c493 <__user_walk+33/50> Trace; c01393f4 Trace; c0125212 Trace; c010887c Trace; c010878b Code; c01bd6fd 00000000 <_EIP>: Code; c01bd6fd <===== 0: 66 83 bb 26 01 00 00 cmpw $0x0,0x126(%ebx) <===== Code; c01bd704 7: 00 Code; c01bd705 8: 75 0f jne 19 <_EIP+0x19> c01bd716 Code; c01bd707 a: 66 83 a3 18 01 00 00 andw $0xfffffff7,0x118(%ebx) Code; c01bd70e 11: f7 Code; c01bd70f 12: 53 push %ebx Code; c01bd710 13: e8 00 00 00 00 call 18 <_EIP+0x18> c01bd715 Jul 5 20:40:09 mrkvoslav kernel: SGI XFS with ACLs, EAs, quota, no debug enabled Jul 5 20:40:10 mrkvoslav kernel: ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) Jul 5 22:56:59 mrkvoslav kernel: SGI XFS with ACLs, EAs, quota, no debug enabled Jul 5 22:56:59 mrkvoslav kernel: ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) Jul 6 00:39:43 mrkvoslav kernel: SGI XFS with ACLs, quota, no debug enabled Jul 6 00:39:44 mrkvoslav kernel: ac97_codec: AC97 Audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) 1 warning issued. Results may not be reliable. --------------Boundary-00=_LYSS8AHR8N3570AMGNQG-- From owner-linux-xfs@oss.sgi.com Sun Jul 7 10:12:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g67HC7Rw031682 for ; Sun, 7 Jul 2002 10:12:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g67HC7Lj031681 for linux-xfs-outgoing; Sun, 7 Jul 2002 10:12:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (cm61-10-218-213.hkcable.com.hk [61.10.218.213]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g67HBvRw031653 for ; Sun, 7 Jul 2002 10:11:59 -0700 Received: from private ([192.168.1.10]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id g67HGDK01316 for ; Mon, 8 Jul 2002 01:16:13 +0800 From: "Damon" To: Subject: fs size of ext2 vs xfs Date: Mon, 8 Jul 2002 01:16:10 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g67HC1Rw031654 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk My machine is RH7.2 + XFS1.1 and I installed an additional 16M compact flesh installed which regonized as /dev/hdc I then use fdisk to make a Linux file system (#83) and format it as ext2 and xfs. I find that the formatted size of ext2 is much bigger than xfs The command to format the cf as follows: ext2: mkfs.ext2 /dev/hdc1 xfs: mkfs.xfs -f /dev/hdc1 size for two different fs as ext2: ~14M xfs: ~10M Is this normal or what I can do to format it as xfs with bigger resulting size. Best regards, Damon From owner-linux-xfs@oss.sgi.com Sun Jul 7 12:44:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g67JigRw000370 for ; Sun, 7 Jul 2002 12:44:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g67Jigbw000369 for linux-xfs-outgoing; Sun, 7 Jul 2002 12:44:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g67JiXRw000340 for ; Sun, 7 Jul 2002 12:44:34 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA17108; Sun, 7 Jul 2002 14:48:46 -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 OAA96040; Sun, 7 Jul 2002 14:48:45 -0500 (CDT) Date: Sun, 7 Jul 2002 14:47:48 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Damon cc: linux-xfs@oss.sgi.com Subject: Re: fs size of ext2 vs xfs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Damon - The internal log for XFS will take up some room. For a 16M filesystem, the default log size will be 1200 4k blocks, which would account for the difference you are seeing. You can specify a smaller log size with, for example: mkfs.xfs -f -l size=512b /dev/foo (512 blocks is as small as you can go for a 4k block fs.) If you are doing lots of writes, the smaller log may impact your performance. Also, FWIW, the constant log writes of any journaling filesystem might be pretty hard on your CF disk... -Eric On Mon, 8 Jul 2002, Damon wrote: > My machine is RH7.2 + XFS1.1 and I installed an additional 16M compact flesh installed which regonized as /dev/hdc > > I then use fdisk to make a Linux file system (#83) and format it as ext2 and xfs. I find that the formatted size of ext2 is much bigger than xfs > > The command to format the cf as follows: > > ext2: mkfs.ext2 /dev/hdc1 > xfs: mkfs.xfs -f /dev/hdc1 > > size for two different fs as > > ext2: ~14M > xfs: ~10M > > Is this normal or what I can do to format it as xfs with bigger resulting size. > > Best regards, > Damon > From owner-linux-xfs@oss.sgi.com Mon Jul 8 08:54:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68FsJRw024105 for ; Mon, 8 Jul 2002 08:54:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68FsJZh024104 for linux-xfs-outgoing; Mon, 8 Jul 2002 08:54:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68Fs7Rw024069 for ; Mon, 8 Jul 2002 08:54:08 -0700 Received: from offline.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 17Rau4-00079R-00; Mon, 08 Jul 2002 16:58:20 +0100 Message-ID: <3D29B69C.345173EE@moving-picture.com> Date: Mon, 08 Jul 2002 16:58:20 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens , Stephen Lord CC: linux-xfs@oss.sgi.com Subject: Re: NFS server stalls with 2.4.18 + XFS 1.1 References: <23440.1025863803@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've had a similar problem this morning - however, typing 'sync' didn't help - nor did rebooting the server - after a reboot the nfsd's worked for a short while, then they 'stalled' again. The server has two XFS volumes (/disk1 and /disk2), running 'find /disk2' on the server also 'hung' ..., so I brought the machine up in single user mode and ran xfs_repair - but it reported no problems - however when I then brought the machine up in multi user mode, NFS access was OK - I don't know if running xfs_repair helped, or if it was just a coincidence that whatever NFS access that had been causing the stall 'went away'... If this still sounds like the problem that Keith has described, then I would like to know if the fix can be back ported to 2.4.18/XFS1.1 - I don't want to use a CVS version unless I really have to ... Thanks James Pearson Keith Owens wrote: > > On Fri, 05 Jul 2002 10:55:45 +0100, > James Pearson wrote: > >Do you happen to know if the fix can be back ported to 2.4.18/XFS 1.1 ? > >Where in the CVS code would I find the fix? > > I was hoping you would not ask that ;). The CVS tree has five months > of changes since 2.4.18, both to XFS and to go from 2.4.18 to > 2.4.19-rc1. I don't know which fix corrected this problem. Steve Lord > might know but he is away until July 8, USA time. > On Thu, 04 Jul 2002 17:16:06 +0100, > James Pearson wrote: > >We have noticed a problem with a couple of our NFS servers (running > >RedHat 7.2 with a stock 2.4.18 kernel with XFS v1.1) whereby NFS access > >slows to a crawl or stalls. > > > >The exported filesystem(s) are XFS with 8 nfsd's running - when we have > >the problem the load average is about 8 - but CPU usage, disk access and > >network traffic are minimal. > > > >I found, by accident, that running the command 'sync' appears to 'fix' > >the situation... > > > >I'm not sure if this is an XFS or NFS related problem (hence posting to > >both lists). > > XFS. 2.4.18 would sometimes get into a situation where two XFS > operations were waiting on locks (not deadlocked) and nothing was > moving. Performing some other disk activity such as sync would get > things moving again. > > AFAICT this is fixed in the XFS CVS tree, against 2.4.19-rc1. From owner-linux-xfs@oss.sgi.com Mon Jul 8 09:40:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68GeJRw024761 for ; Mon, 8 Jul 2002 09:40:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68GeJEc024760 for linux-xfs-outgoing; Mon, 8 Jul 2002 09:40:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68Ge7Rw024731 for ; Mon, 8 Jul 2002 09:40:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA18958; Mon, 8 Jul 2002 11:44:22 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA38406; Mon, 8 Jul 2002 11:44:22 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g68GdjQ22286; Mon, 8 Jul 2002 11:39:45 -0500 Subject: Re: NFS server stalls with 2.4.18 + XFS 1.1 From: Steve Lord To: James Pearson Cc: Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: <3D29B69C.345173EE@moving-picture.com> References: <23440.1025863803@ocs3.intra.ocs.com.au> <3D29B69C.345173EE@moving-picture.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 08 Jul 2002 11:39:44 -0500 Message-Id: <1026146384.10016.12.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-07-08 at 10:58, James Pearson wrote: > I've had a similar problem this morning - however, typing 'sync' didn't > help - nor did rebooting the server - after a reboot the nfsd's worked > for a short while, then they 'stalled' again. > > The server has two XFS volumes (/disk1 and /disk2), running 'find > /disk2' on the server also 'hung' ..., so I brought the machine up in > single user mode and ran xfs_repair - but it reported no problems - > however when I then brought the machine up in multi user mode, NFS > access was OK - I don't know if running xfs_repair helped, or if it was > just a coincidence that whatever NFS access that had been causing the > stall 'went away'... > > If this still sounds like the problem that Keith has described, then I > would like to know if the fix can be back ported to 2.4.18/XFS1.1 - I > don't want to use a CVS version unless I really have to ... > > Thanks > > James Pearson > > Keith Owens wrote: > > > > On Fri, 05 Jul 2002 10:55:45 +0100, > > James Pearson wrote: > > >Do you happen to know if the fix can be back ported to 2.4.18/XFS 1.1 ? > > >Where in the CVS code would I find the fix? > > > > I was hoping you would not ask that ;). The CVS tree has five months > > of changes since 2.4.18, both to XFS and to go from 2.4.18 to > > 2.4.19-rc1. I don't know which fix corrected this problem. Steve Lord > > might know but he is away until July 8, USA time. > > > I really wish I could remember where in the code this got fixed, but it is sort of a needle in a haystack to find. Looking at the mail archives, there does not appear to be a specific fix for this, it was more that other changes in the filesystem affected when we sync data to disk, and this fixed the problem. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jul 8 13:22:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68KMfRw007064 for ; Mon, 8 Jul 2002 13:22:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68KMfNE007063 for linux-xfs-outgoing; Mon, 8 Jul 2002 13:22:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68KMXRw007018 for ; Mon, 8 Jul 2002 13:22:33 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA25860 for ; Mon, 8 Jul 2002 15:26:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA60506 for ; Mon, 8 Jul 2002 15:26:49 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g68KMAC11039; Mon, 8 Jul 2002 15:22:10 -0500 Message-Id: <200207082022.g68KMAC11039@jen.americas.sgi.com> Date: Mon, 8 Jul 2002 15:22:10 -0500 Subject: TAKE - inode flush changes To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Move XFS closer to the linux inode flushing model. Date: Mon Jul 8 13:25:42 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122661a linux/fs/xfs/xfs_vnodeops.c - 1.533 - Add an iflush call which will initiate an inode flush to disk if it can, otherwise return EAGAIN. linux/fs/xfs/xfs_trans.c - 1.131 - Mark the super block dirty after a transaction linux/fs/xfs/linux/xfs_super.c - 1.186 - change write_inode method to call into VOP_IFLUSH linux/fs/xfs/linux/xfs_iops.c - 1.156 - remove unneeded inode field updates, make more use of mark_inode_dirty linux/fs/xfs/linux/xfs_vnode.h - 1.43 - add VOP_IFLUSH From owner-linux-xfs@oss.sgi.com Mon Jul 8 15:06:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68M6MRw016722 for ; Mon, 8 Jul 2002 15:06:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68M6MMx016721 for linux-xfs-outgoing; Mon, 8 Jul 2002 15:06:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68M6FRw016693 for ; Mon, 8 Jul 2002 15:06:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA05329 for ; Mon, 8 Jul 2002 17:10:32 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA35409 for ; Mon, 8 Jul 2002 17:10:31 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g68M5pr19768; Mon, 8 Jul 2002 17:05:51 -0500 Message-Id: <200207082205.g68M5pr19768@jen.americas.sgi.com> Date: Mon, 8 Jul 2002 17:05:51 -0500 Subject: TAKE - io path cleanups To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nothing major here, just cleanup Date: Mon Jul 8 15:09:30 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122666a linux/fs/xfs/xfs_rw.h - 1.65 linux/fs/xfs/xfs_rw.c - 1.358 linux/fs/xfs/xfs_vnodeops.c - 1.534 linux/fs/xfs/xfs_dfrag.c - 1.31 - changes xfs_inval_cached_pages interface linux/fs/xfs/linux/xfs_lrw.c - 1.151 - move pagebuf_iozero here, relocate xfs stats here, change xfs_inval_cached_pages interface linux/fs/xfs/linux/xfs_file.c - 1.68 - move xfs stats into xfs linux/fs/xfs/pagebuf/page_buf_io.c - 1.47 linux/fs/xfs/pagebuf/page_buf.h - 1.22 - remove pagebuf_iozero from here From owner-linux-xfs@oss.sgi.com Mon Jul 8 15:22:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68MMoRw017011 for ; Mon, 8 Jul 2002 15:22:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68MMoKN017010 for linux-xfs-outgoing; Mon, 8 Jul 2002 15:22:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68MMRRw016981 for ; Mon, 8 Jul 2002 15:22:28 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g68MQn4K046732 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 8 Jul 2002 18:26:49 -0400 Received: from chavez.austin.ibm.com (chavez.austin.ibm.com [9.53.216.228]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g68MQmOB049506; Mon, 8 Jul 2002 16:26:48 -0600 Subject: Re: TAKE - Introduce version 2 log support to XFS From: Luciano Chavez To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <200206182039.g5IKdY810979@jen.americas.sgi.com> References: <200206182039.g5IKdY810979@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 08 Jul 2002 17:23:40 -0500 Message-Id: <1026167021.2203.65.camel@chavez> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 15:39, Steve Lord wrote: > OK, new feature time. This hopefully is the answer to performance > problems on software raid5, and to issues with EVMS and LVM2 when > using XFS. You will need new commands to use this. > > Basically this adds support for a new log format in XFS, which > allows for two things: > > o larger internal log buffers, and hence larger log writes, > the old limit was 32K, the new one is 256K. You must be using > version 2 log format to use the larger sizes. > > o Stripe aligned log writes, log writes can be stripe aligned to > the data stripe unit, or to an explicitly specified log stripe > unit. This is the part which helps out EVMS, LVM2 and software > raid5. > Steve, I finished a patch to xfsprogs (works for 2.0.3 and current CVS/2.1.1) that allows getting stripe info for EVMS volumes using a new EVMS IOCtl. I haven't submitted it to you yet because I still have the same alignment problems with XFS. I repeated the tests with the XFS kernel tree from CVS from xfs.org and still have problems. At the moment, the EVMS IOCtl called during mkfs always returns a 4K stripe unit and a width of 1 but we may expand the support for the best choice in a storage stack later. Here is what the 2.1.1 mkfs.xfs output looks like (it appears that the log sunit matches the data sunit although represented in bytes rather that fs blocksize units which looks correct): root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31359 blks data = bsize=4096 blocks=250872, imaxpct=25 = sunit=1 swidth=1 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sunit=4096 realtime =none extsz=4096 blocks=0, rtextents=0 The mount command generates the following entries in the message log: XFS mounting filesystem evms(117,4) evms: non-aligned request [bh(cd89a360), rsector(f5002), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f500a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f5012), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f501a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f5022), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f502a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f5032), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f503a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f5042), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f504a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f5052), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f505a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f5062), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f506a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f5072), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f507a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f5082), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f508a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f5092), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f509a), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50a2), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50aa), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50b2), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50ba), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50c2), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50ca), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50d2), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50da), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50e2), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50ea), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50f2), size(1000)] rejected on volume(md/md0). evms: non-aligned request [bh(cd89a360), rsector(f50fa), size(1000)] rejected on volume(md/md0). xfs_force_shutdown(evms(117,4),0x1) called from line 350 of file xfs_rw.c. Return address = 0xc01c7c19 I/O Error Detected. Shutting down filesystem: evms(117,4) Please umount the filesystem, and rectify the problem(s) I/O error in filesystem ("evms(117,4)") meta-data dev 0x7504 block 0xf5002 ("xlog_bwrite") error 5 buf count 131072 xfs_force_shutdown(evms(117,4),0x1) called from line 350 of file xfs_rw.c. Return address = 0xc01c7c19 I/O error in filesystem ("evms(117,4)") meta-data dev 0x7504 block 0xf5102 ("xlog_bwrite") error 5 buf count 131072 XFS: failed to locate log tail XFS: log mount/recovery failed XFS: log mount failed I am hoping that the issue is still with this following code in _pagebuf_page_io that you had mention some time back: /* This will attempt to make a request bigger than the sector * size if we are well aligned. */ if ((MAJOR(dev) != LVM_BLK_MAJOR) && (MAJOR(dev) != MD_MAJOR)) { sector = blk_length << SECTOR_SHIFT; blk_length = 1; } else if ((MAJOR(dev) == MD_MAJOR) && (pg_offset == 0) && (pg_length == PAGE_CACHE_SIZE) && (((unsigned int) bn) & BN_ALIGN_MASK) == 0) { sector = blk_length << SECTOR_SHIFT; blk_length = 1; } else { sector = SECTOR_SIZE; } -- regards, Luciano Chavez lnx1138@us.ibm.com http://evms.sourceforge.net From owner-linux-xfs@oss.sgi.com Mon Jul 8 15:57:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68MvORw017784 for ; Mon, 8 Jul 2002 15:57:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68MvOGE017783 for linux-xfs-outgoing; Mon, 8 Jul 2002 15:57:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68MvGRw017754 for ; Mon, 8 Jul 2002 15:57:16 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 QAA06031 for ; Mon, 8 Jul 2002 16:01:38 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA08765; Tue, 9 Jul 2002 09:00:18 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) with ESMTP id g68Mx9oE000891; Tue, 9 Jul 2002 08:59:09 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) id g68Mx8R7000889; Tue, 9 Jul 2002 08:59:08 +1000 Date: Tue, 9 Jul 2002 08:59:08 +1000 From: Nathan Scott To: Ian Cumming Cc: linux-xfs@oss.sgi.com Subject: Re: setquota on Debian (testing) Message-ID: <20020708225908.GA459@frodo> References: <20020705065605.GA1820@ids.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020705065605.GA1820@ids.org.au> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jul 05, 2002 at 04:56:05PM +1000, Ian Cumming wrote: > Hi, > > I've just noticed some weirdness with setquota on my debian (testing) > machine. Basically, setquota is ignoring the soft and hard block limits > on the command line. However, it is recognising the file limits. > > Here's an example: > > 1. before setquota: > Disk quotas for user cprevost (uid 1202): > Filesystem blocks quota limit grace files quota limit grace > /dev/hda8 12 20480 25600 4 15000 20000 > /dev/hdc5 99684 102400 122880 1549 17000 20000 > > 2. setquota > /usr/sbin/setquota -F xfs -u cprevost 256000 225280 17000 20000 /dev/hdc5 This looks incorrect - your softlimit is greater than your hardlimit - could that be the problem? I'm running Debian (unstable, not testing, so I have slightly newer quota tools) and this works for me. The "-F xfs" should be redundant too. > 3. after setquota > Same as 1. > > ... > If anyone has any ideas how I can fix this, it would be greatly > appreciated! (And make my automated quota scripts happy too! ;) Hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jul 8 19:58:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g692wCRw024534 for ; Mon, 8 Jul 2002 19:58:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g692wBvN024533 for linux-xfs-outgoing; Mon, 8 Jul 2002 19:58:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g692w0Rw024500 for ; Mon, 8 Jul 2002 19:58:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA24903 for ; Mon, 8 Jul 2002 22:02:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA70304 for ; Mon, 8 Jul 2002 22:02:17 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g692vZF21837; Mon, 8 Jul 2002 21:57:35 -0500 Message-Id: <200207090257.g692vZF21837@jen.americas.sgi.com> Date: Mon, 8 Jul 2002 21:57:35 -0500 Subject: TAKE - make XFS use the generic write code To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This removes the XFS specific write path by modifying the generic path to be usable by XFS. Also a couple of O_DIRECT related fixes, and a locking change in pagebuf which should protect the cases where the block device and the filesystem path are being accessed in parallel. Date: Mon Jul 8 19:59:39 PDT 2002 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:122679a linux/mm/filemap.c - 1.113 - break generic_file_write apart for use by xfs. Fix direct read end of file handling. linux/include/linux/fs.h - 1.152 - prototype for do_generic_file_write linux/fs/xfs/xfs_dmapi.c - 1.64 - Get max direct I/O size from a different place linux/fs/xfs/linux/xfs_lrw.c - 1.152 - replace call to pagebuf_generic_file_write with do_generic_file_write. linux/fs/xfs/linux/xfs_file.c - 1.69 - since we now call the generic write path in xfs remove the checks here which duplicate its functionality. Grab the i_sem lock in the non O_DIRECT case, we need it in the vmtruncate call out of do_generic_file_write. linux/fs/xfs/linux/xfs_iops.c - 1.157 - Add a truncate operation, change setattr to use vmtruncate and not call inode_setattr linux/fs/xfs/linux/xfs_ioctl.c - 1.65 - Get max direct I/O size from a different place linux/fs/xfs/pagebuf/page_buf_io.c - 1.48 - remove write path linux/fs/xfs/pagebuf/page_buf.c - 1.35 - leave pages locked when reading it in. linux/fs/xfs/pagebuf/page_buf.h - 1.23 - remove prototypes linux/fs/xfs/pagebuf/page_buf_internal.h - 1.10 - remove direct I/O config option From owner-linux-xfs@oss.sgi.com Mon Jul 8 23:15:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g696FnRw027675 for ; Mon, 8 Jul 2002 23:15:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g696FnrA027674 for linux-xfs-outgoing; Mon, 8 Jul 2002 23:15:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g696FgRw027646 for ; Mon, 8 Jul 2002 23:15:42 -0700 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g696K3Lj062760; Tue, 9 Jul 2002 08:20:04 +0200 (CEST) Message-Id: <4.3.2.7.2.20020709081450.03351490@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Jul 2002 08:19:19 +0200 To: Steve Lord , James Pearson From: Seth Mos Subject: Re: NFS server stalls with 2.4.18 + XFS 1.1 Cc: Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: <1026146384.10016.12.camel@jen.americas.sgi.com> References: <3D29B69C.345173EE@moving-picture.com> <23440.1025863803@ocs3.intra.ocs.com.au> <3D29B69C.345173EE@moving-picture.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:39 8-7-2002 -0500, Steve Lord wrote: >I really wish I could remember where in the code this got fixed, but >it is sort of a needle in a haystack to find. Looking at the mail >archives, there does not appear to be a specific fix for this, it >was more that other changes in the filesystem affected when we sync >data to disk, and this fixed the problem. I think steve bumped into this during the multiple blocksize work. I remember something like this from the changelogs or the list. And backporting that is near impossible without fetching the entire tree. Can you try and see if the CVS makes your problem go away? Backporting fixes is not something the SGI developers have time for. If people have problem with releases we recommend using the CVS tree if it works for them or wait untill the next release. Whenever that is ;) Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Jul 9 00:07:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6977kRw030494 for ; Tue, 9 Jul 2002 00:07:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6977jlq030491 for linux-xfs-outgoing; Tue, 9 Jul 2002 00:07:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6977YRw030422 for ; Tue, 9 Jul 2002 00:07:36 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 17RpA5-0001Cg-00; Tue, 09 Jul 2002 08:11:49 +0100 Date: Tue, 9 Jul 2002 08:11:49 +0100 From: Christoph Hellwig To: Andrew Morton Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: [PATCH] fix qsort breakage Message-ID: <20020709081149.A3621@infradead.org> References: <20020504121512.A8534@infradead.org> <3D221C40.CFA7C46E@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D221C40.CFA7C46E@zip.com.au>; from akpm@zip.com.au on Tue, Jul 02, 2002 at 02:33:52PM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jul 02, 2002 at 02:33:52PM -0700, Andrew Morton wrote: > qsort should take gfp_flags as an argument. Or not perform any allocation, > as you've described. I've patched it up to the latest glibc version that doesn't require any allocations. > (It'd be nice to stick that qsort in lib/qsort.c, rather than making > it XFS-private, btw). *nod* - the problem is that this would make the core changes of XFS bigger again. Maybe you find a use for it in 2.5 and can send it to Linus ;) From owner-linux-xfs@oss.sgi.com Tue Jul 9 00:40:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g697eeRw008321 for ; Tue, 9 Jul 2002 00:40:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g697ee0K008319 for linux-xfs-outgoing; Tue, 9 Jul 2002 00:40:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g697eYRw008281 for ; Tue, 9 Jul 2002 00:40:34 -0700 Received: from nodin.corp.sgi.com ([198.29.75.193]) 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 AAA06867 for ; Tue, 9 Jul 2002 00:45:22 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g697htQR11005752; Tue, 9 Jul 2002 00:43:56 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 0DA4B3000BA; Tue, 9 Jul 2002 17:43:53 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 9361C98; Tue, 9 Jul 2002 17:43:53 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Christoph Hellwig Cc: Andrew Morton , linux-xfs@oss.sgi.com Subject: Re: [PATCH] fix qsort breakage In-reply-to: Your message of "Tue, 09 Jul 2002 08:11:49 +0100." <20020709081149.A3621@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jul 2002 17:43:47 +1000 Message-ID: <25568.1026200627@kao2.melbourne.sgi.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 9 Jul 2002 08:11:49 +0100, Christoph Hellwig wrote: >On Tue, Jul 02, 2002 at 02:33:52PM -0700, Andrew Morton wrote: >> (It'd be nice to stick that qsort in lib/qsort.c, rather than making >> it XFS-private, btw). > >*nod* - the problem is that this would make the core changes of XFS bigger >again. Maybe you find a use for it in 2.5 and can send it to Linus ;) Kching! Init and exit sections break the assumptions that exception tables are sorted. The thread started in http://marc.theaimsgroup.com/?l=linux-kernel&m=101912337804026&w=2 and ended with agreement that the fix was needed but it should use a better sort routine. I got sidetracked and never did the better sort routine. Sounds like a good use for qsort. From owner-linux-xfs@oss.sgi.com Tue Jul 9 04:42:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69Bg9Rw014607 for ; Tue, 9 Jul 2002 04:42:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69Bg90i014604 for linux-xfs-outgoing; Tue, 9 Jul 2002 04:42:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from students.fct.unl.pt (students.fct.unl.pt [193.136.120.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69BfuRw014551 for ; Tue, 9 Jul 2002 04:41:57 -0700 Received: from localhost (pjsm@localhost) by students.fct.unl.pt (8.11.6/8.11.6) with ESMTP id g69Bjoj08766; Tue, 9 Jul 2002 12:45:51 +0100 X-Authentication-Warning: students.fct.unl.pt: pjsm owned process doing -bs Date: Tue, 9 Jul 2002 12:45:50 +0100 (WEST) From: Paulo Matos To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: RH 7.3 installer problem with CD verification Message-ID: X-GPG-PUBLIC_KEY: http://students.fct.unl.pt/~pjsm/pjsm_fct.public.asc X-GPG-FINGRPRINT: 1024D/1DD3CA2F 5E95 9FD3 3435 A763 18E9 FB57 282B BCD7 1DD3 CA2F MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by students.fct.unl.pt id g69Bjoj08766 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g69BfwRw014555 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Folks! I found a problem on RH7.3 + XFS1.1 installer with RH 7.3 CD1 verification. Please read bellow to get in context... On 2 Jul 2002, Florin Andrei wrote: florin> On Tue, 2002-07-02 at 19:36, Paulo Matos wrote: florin> > florin> > mbest> The SGI team put together an installer at: florin> > mbest> florin> > mbest> ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/ florin> > florin> > Already knew (but thanks) and already tried it... I had bad florin> > results: using CD-RW support for iso's, It does not recognize florin> > the RedHat CD1... using CD-RW for installer and CD-R support for florin> > RH disk, it still does not recognize (had reports that it worked florin> > with CD-R)... maybe it's because the device is a writer... out florin> > of ideas 4 now... (it's late). florin> florin> You definitely did something very wrong. Perhaps you didn't florin> checked the MD5 checksum after download? florin> That iso works for me and for everyone i know. It seem that I finally find the trouble... RedHat has released another iso for valhalla-i386-disc1.iso, on June 17... an extract from ftp.redhat.com -rw-r--r-- 1 0 0 668499968 Jun 17 18:57 valhalla-i386-disc1.iso -rw-r--r-- 1 0 0 669319168 Jun 14 04:49 valhalla-i386-disc2.iso -rw-r--r-- 1 0 0 517079040 Jun 14 04:50 valhalla-i386-disc3.iso looking at a previous iso (probably from June 14) cat /mnt/previous_iso/.disc1-i386 1024014876.906127 Valhalla 7.3 disc1 cat /mnt/latest_iso/.disc1-i386 1019242152.098183 Valhalla 7.3 disc1 I double checked md5sums and they were correct... SGI installer verifies (presumably) the timestamp on .disc1 file, that does not match the contents of the new iso.... Is this correct? If so, how can I fix it to work with the new iso? Thanks in advance. Best regards, -- Paulo Matos ----------------------------------- ---------------------------------- |Sys & Net Admin | Serviço de Informática | |Faculdade de Ciências e Tecnologia | Tel: +351-21-2948596 | |Universidade Nova de Lisboa | Fax: +351-21-2948548 | |P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt | ----------------------------------- ---------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jul 9 06:18:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69DI5Rw000347 for ; Tue, 9 Jul 2002 06:18:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69DI5av000346 for linux-xfs-outgoing; Tue, 9 Jul 2002 06:18:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69DHpRw032733 for ; Tue, 9 Jul 2002 06:17:52 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA28358; Tue, 9 Jul 2002 08:22: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 IAA41118; Tue, 9 Jul 2002 08:22:10 -0500 (CDT) Date: Tue, 9 Jul 2002 08:20:57 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Paulo Matos cc: linux-xfs@oss.sgi.com Subject: Re: RH 7.3 installer problem with CD verification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by zeus-e8.americas.sgi.com id IAA28358 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g69DHqRw032744 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Paulo - If Red Hat has 2 versions of 7.3 out there, then the answer is to use the first version, the one that works with the XFS installer. :) You could also try changing the timestamp in the XFS installer to match the new version, but I don't know what has changed, so you may well run into trouble on that path. (If RPM versions have changed, then the hdlist file on the XFS installer disc won't match, and it won't find the RPMs that it needs) -Eric On Tue, 9 Jul 2002, Paulo Matos wrote: > Hi Folks! > > I found a problem on RH7.3 + XFS1.1 installer with RH 7.3 CD1 > verification. Please read bellow to get in context... > > > On 2 Jul 2002, Florin Andrei wrote: > > florin> On Tue, 2002-07-02 at 19:36, Paulo Matos wrote: > florin> > > florin> > mbest> The SGI team put together an installer at: > florin> > mbest> > florin> > mbest> ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/ > florin> > > florin> > Already knew (but thanks) and already tried it... I had bad > florin> > results: using CD-RW support for iso's, It does not recognize > florin> > the RedHat CD1... using CD-RW for installer and CD-R support for > florin> > RH disk, it still does not recognize (had reports that it worked > florin> > with CD-R)... maybe it's because the device is a writer... out > florin> > of ideas 4 now... (it's late). > florin> > florin> You definitely did something very wrong. Perhaps you didn't > florin> checked the MD5 checksum after download? > florin> That iso works for me and for everyone i know. > > It seem that I finally find the trouble... > > RedHat has released another iso for valhalla-i386-disc1.iso, on > June 17... an extract from ftp.redhat.com > > -rw-r--r-- 1 0 0 668499968 Jun 17 18:57 valhalla-i386-disc1.iso > -rw-r--r-- 1 0 0 669319168 Jun 14 04:49 valhalla-i386-disc2.iso > -rw-r--r-- 1 0 0 517079040 Jun 14 04:50 valhalla-i386-disc3.iso > > looking at a previous iso (probably from June 14) > cat /mnt/previous_iso/.disc1-i386 > 1024014876.906127 > Valhalla 7.3 disc1 > > cat /mnt/latest_iso/.disc1-i386 > 1019242152.098183 > Valhalla 7.3 disc1 > > I double checked md5sums and they were correct... > > SGI installer verifies (presumably) the timestamp on .disc1 file, > that does not match the contents of the new iso.... > > Is this correct? If so, how can I fix it to work with the new iso? > > Thanks in advance. > > Best regards, > > -- > Paulo Matos > ----------------------------------- ---------------------------------- > |Sys & Net Admin | Serviço de Informática | > |Faculdade de Ciências e Tecnologia | Tel: +351-21-2948596 | > |Universidade Nova de Lisboa | Fax: +351-21-2948548 | > |P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt | > ----------------------------------- ---------------------------------- > From owner-linux-xfs@oss.sgi.com Tue Jul 9 06:28:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69DSNRw002317 for ; Tue, 9 Jul 2002 06:28:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69DSNOI002316 for linux-xfs-outgoing; Tue, 9 Jul 2002 06:28:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69DS7Rw002225 for ; Tue, 9 Jul 2002 06:28:07 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA97814; Tue, 9 Jul 2002 08:32:26 -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 IAA17276; Tue, 9 Jul 2002 08:32:26 -0500 (CDT) Date: Tue, 9 Jul 2002 08:31:13 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Paulo Matos cc: linux-xfs@oss.sgi.com Subject: Re: RH 7.3 installer problem with CD verification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by zeus-e8.americas.sgi.com id IAA97814 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g69DS8Rw002242 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ah, new information, apparently the old isos are not available anywhere, perhaps for some legal reason or other... ok, looks like we may have to re-spin it after all. I'll do it when I find some time, I guess. -Eric On Tue, 9 Jul 2002, Eric Sandeen wrote: > Hi Paulo - > > If Red Hat has 2 versions of 7.3 out there, then the answer is to use > the first version, the one that works with the XFS installer. :) > > You could also try changing the timestamp in the XFS installer to match the > new version, but I don't know what has changed, so you may well run into > trouble on that path. (If RPM versions have changed, then the hdlist file > on the XFS installer disc won't match, and it won't find the RPMs that it > needs) > > -Eric > > On Tue, 9 Jul 2002, Paulo Matos wrote: > > > Hi Folks! > > > > I found a problem on RH7.3 + XFS1.1 installer with RH 7.3 CD1 > > verification. Please read bellow to get in context... > > > > > > On 2 Jul 2002, Florin Andrei wrote: > > > > florin> On Tue, 2002-07-02 at 19:36, Paulo Matos wrote: > > florin> > > > florin> > mbest> The SGI team put together an installer at: > > florin> > mbest> > > florin> > mbest> ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/ > > florin> > > > florin> > Already knew (but thanks) and already tried it... I had bad > > florin> > results: using CD-RW support for iso's, It does not recognize > > florin> > the RedHat CD1... using CD-RW for installer and CD-R support for > > florin> > RH disk, it still does not recognize (had reports that it worked > > florin> > with CD-R)... maybe it's because the device is a writer... out > > florin> > of ideas 4 now... (it's late). > > florin> > > florin> You definitely did something very wrong. Perhaps you didn't > > florin> checked the MD5 checksum after download? > > florin> That iso works for me and for everyone i know. > > > > It seem that I finally find the trouble... > > > > RedHat has released another iso for valhalla-i386-disc1.iso, on > > June 17... an extract from ftp.redhat.com > > > > -rw-r--r-- 1 0 0 668499968 Jun 17 18:57 valhalla-i386-disc1.iso > > -rw-r--r-- 1 0 0 669319168 Jun 14 04:49 valhalla-i386-disc2.iso > > -rw-r--r-- 1 0 0 517079040 Jun 14 04:50 valhalla-i386-disc3.iso > > > > looking at a previous iso (probably from June 14) > > cat /mnt/previous_iso/.disc1-i386 > > 1024014876.906127 > > Valhalla 7.3 disc1 > > > > cat /mnt/latest_iso/.disc1-i386 > > 1019242152.098183 > > Valhalla 7.3 disc1 > > > > I double checked md5sums and they were correct... > > > > SGI installer verifies (presumably) the timestamp on .disc1 file, > > that does not match the contents of the new iso.... > > > > Is this correct? If so, how can I fix it to work with the new iso? > > > > Thanks in advance. > > > > Best regards, > > > > -- > > Paulo Matos > > ----------------------------------- ---------------------------------- > > |Sys & Net Admin | Serviço de Informática | > > |Faculdade de Ciências e Tecnologia | Tel: +351-21-2948596 | > > |Universidade Nova de Lisboa | Fax: +351-21-2948548 | > > |P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt | > > ----------------------------------- ---------------------------------- > > > > From owner-linux-xfs@oss.sgi.com Tue Jul 9 06:54:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69DswRw014599 for ; Tue, 9 Jul 2002 06:54:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69Dsw10014598 for linux-xfs-outgoing; Tue, 9 Jul 2002 06:54:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from students.fct.unl.pt (students.fct.unl.pt [193.136.120.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69DsURw014477 for ; Tue, 9 Jul 2002 06:54:39 -0700 Received: from localhost (pjsm@localhost) by students.fct.unl.pt (8.11.6/8.11.6) with ESMTP id g69DwnZ13605; Tue, 9 Jul 2002 14:58:49 +0100 X-Authentication-Warning: students.fct.unl.pt: pjsm owned process doing -bs Date: Tue, 9 Jul 2002 14:58:49 +0100 (WEST) From: Paulo Matos To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: RH 7.3 installer problem with CD verification In-Reply-To: Message-ID: X-GPG-PUBLIC_KEY: http://students.fct.unl.pt/~pjsm/pjsm_fct.public.asc X-GPG-FINGRPRINT: 1024D/1DD3CA2F 5E95 9FD3 3435 A763 18E9 FB57 282B BCD7 1DD3 CA2F MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by students.fct.unl.pt id g69DwnZ13605 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g69DsfRw014523 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric! On Tue, 9 Jul 2002, Eric Sandeen wrote: sandeen> If Red Hat has 2 versions of 7.3 out there, then the answer is to use sandeen> the first version, the one that works with the XFS installer. :) sandeen> sandeen> You could also try changing the timestamp in the XFS installer to match the sandeen> new version, but I don't know what has changed, so you may well run into sandeen> trouble on that path. (If RPM versions have changed, then the hdlist file sandeen> on the XFS installer disc won't match, and it won't find the RPMs that it sandeen> needs) The changes are: .disc1-i386 (timestamp) -> affects .disc4-i386 TRANS.TBL -> names in 8:3 format have changed!!! -> and -> abiword-0.99.5-1.i386.rpm -> is now -> abiword-0.99.5-2.i386.rpm boot.cat RedHat/RPMS/abiword-0.99.5-2.i386.rpm -> was abiword-0.99.5-1.i386.rpm RedHat/base/comps -> small diffs RedHat/base/hdlist RedHat/base/hdlist2 RedHat/base/hdstg1.img RedHat/base/netstg1.img RedHat/base/stage2.img dosutils/autoboot/cdboot.img dosutils/autoboot/initrd.img images/boot.img images/bootnet.img images/drvblock.img images/drvnet.img images/oldcdrom.img images/pcmcia.img images/pcmciadd.img images/pxeboot/initrd.img images/pxeboot/initrd-everything.img images/{de,es,fr,it,ja}/boot.img images/{de,es,fr,it,ja}/bootnet.img images/{de,es,fr,it,ja}/pcmcia.img When they change the abiword package the changes are reflected on all these files? Some of them are obvious (TRANS.TBL, etc) but other like boot.cat, initrd*.img, pcmcia.img, drv*.img are not so obvious... -- Paulo Matos ----------------------------------- ---------------------------------- |Sys & Net Admin | Serviço de Informática | |Faculdade de Ciências e Tecnologia | Tel: +351-21-2948596 | |Universidade Nova de Lisboa | Fax: +351-21-2948548 | |P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt | ----------------------------------- ---------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jul 9 07:17:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69EH4Rw019185 for ; Tue, 9 Jul 2002 07:17:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69EH4nc019184 for linux-xfs-outgoing; Tue, 9 Jul 2002 07:17:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69EGxRw019081 for ; Tue, 9 Jul 2002 07:17:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA37716 for ; Tue, 9 Jul 2002 09:21:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA75289 for ; Tue, 9 Jul 2002 09:21:19 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g69EGXj01242; Tue, 9 Jul 2002 09:16:33 -0500 Message-Id: <200207091416.g69EGXj01242@jen.americas.sgi.com> Date: Tue, 9 Jul 2002 09:16:33 -0500 Subject: TAKE - small cleanup in vnode generation number code To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 9 07:20:44 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122683a linux/fs/xfs/linux/xfs_vnode.c - 1.86 - small cleanup in generation number code From owner-linux-xfs@oss.sgi.com Tue Jul 9 07:25:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69EPuRw021361 for ; Tue, 9 Jul 2002 07:25:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69EPudE021357 for linux-xfs-outgoing; Tue, 9 Jul 2002 07:25:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69EPpRw021296 for ; Tue, 9 Jul 2002 07:25:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA37359 for ; Tue, 9 Jul 2002 09:30:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA17748 for ; Tue, 9 Jul 2002 09:30:11 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g69EPOL03750; Tue, 9 Jul 2002 09:25:24 -0500 Message-Id: <200207091425.g69EPOL03750@jen.americas.sgi.com> Date: Tue, 9 Jul 2002 09:25:24 -0500 Subject: TAKE - rename pagebuf_iozero To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Small cleanup from Christoph Date: Tue Jul 9 07:29:40 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122684a linux/fs/xfs/linux/xfs_lrw.c - 1.153 - rename pagebuf_iozero to xfs_iozero and change error sign to be positive From owner-linux-xfs@oss.sgi.com Tue Jul 9 07:44:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69EijRw025162 for ; Tue, 9 Jul 2002 07:44:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69EijtG025161 for linux-xfs-outgoing; Tue, 9 Jul 2002 07:44:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from tigger.cc-concepts.com (64-40-83-10.dsl.mebtel.net [64.40.83.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69EibRw025091 for ; Tue, 9 Jul 2002 07:44:37 -0700 Received: from duke.edu (user-10-67.wireless.duke.edu [152.16.10.67]) (authenticated) by tigger.cc-concepts.com (8.11.6/8.11.6) with ESMTP id g69EmPZ03862; Tue, 9 Jul 2002 10:48:25 -0400 Message-ID: <3D2AF7B9.5050507@duke.edu> Date: Tue, 09 Jul 2002 10:48:25 -0400 From: Mike Baptiste Organization: Pratt School of Engineering, Duke University User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Shannon Hendrix CC: linux-xfs@oss.sgi.com Subject: Re: C compiler... References: <20020626145830.GB7973@widomaker.com> X-Enigmail-Version: 0.62.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've had trouble compiling 2.4.18 & XFS with anything less than 3.0.4 (ie 2.96), so I finally risked the switch. I've used 3.0.4 (XFS 1.0x) and now 3.1 (XFS 1.1) with no troubles on our main servers (RH 7.2 w/LVM) and on my laptop. Small set thats probably meaningless, I know, but so far, I'm very happy with it. But as always - YMMV MB Charles Shannon Hendrix wrote: > I note that the XFS patches suggest using egcs 2.91.66 to build > the kernel. However, some new distributions (like Slackware) don't > even ship with that compiler any more. While it's easy enough to get, > I believe the kernel is supposed to be stable on later releases now. > > What are your feelings on using other versions of gcc for XFS builds? > > What about GCC 3.1.latest? > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mike Baptiste 202 Hudson Hall, Box 90271, Durham, NC 27708 Director of Information Technology mike.baptiste@duke.edu Pratt School of Engineering @ Duke University Phone:919-660-5404 Download my Public GPG Key at http://duke.edu/~baptiste/mike.gpg From owner-linux-xfs@oss.sgi.com Tue Jul 9 09:58:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69GwjRw023686 for ; Tue, 9 Jul 2002 09:58:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69GwjJ5023685 for linux-xfs-outgoing; Tue, 9 Jul 2002 09:58:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69GwSRw023631 for ; Tue, 9 Jul 2002 09:58:29 -0700 Received: from wingnut.mpc.local ([172.16.200.29]) by moving-picture.com with esmtp (Exim 3.22 #1) id 17RyO0-00005w-00 for linux-xfs@oss.sgi.com; Tue, 09 Jul 2002 18:02:48 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by wingnut.mpc.local (8.11.6/8.8.6) id g69H2lX13106 for linux-xfs@oss.sgi.com; Tue, 9 Jul 2002 18:02:47 +0100 Message-Id: <200207091702.g69H2lX13106@wingnut.mpc.local> Content-Type: text/plain; charset="us-ascii" From: Huw Lynes To: linux-xfs@oss.sgi.com Subject: Re:NFS server stalls with 2.4.18 + XFS 1.1 Date: Tue, 9 Jul 2002 18:02:47 +0100 X-Mailer: KMail [version 1.3.1] References: <20020703185958.JPRF9213.imf16bis.bellsouth.net@taz> In-Reply-To: <20020703185958.JPRF9213.imf16bis.bellsouth.net@taz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g69GwURw023644 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 04 July james-p@moving-picture.com wrote: >We have noticed a problem with a couple of our NFS servers (running >RedHat 7.2 with a stock 2.4.18 kernel with XFS v1.1) whereby NFS access >slows to a crawl or stalls. > >The exported filesystem(s) are XFS with 8 nfsd's running - when we have >the problem the load average is about 8 - but CPU usage, disk access >and >network traffic are minimal. > >I found, by accident, that running the command 'sync' appears to 'fix' >the situation... We have just had the same problem again. Although this time there was an associated kernel oops. The output of ksymoops is as follows: Jul 9 12:45:20 santos kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000001 Jul 9 12:45:20 santos kernel: c01c5384 Jul 9 12:45:20 santos kernel: *pde = 00000000 Jul 9 12:45:20 santos kernel: Oops: 0000 Jul 9 12:45:20 santos kernel: CPU: 1 Jul 9 12:45:20 santos kernel: EIP: 0010:[xfs_syncsub+588/3128] Not tainted Jul 9 12:45:20 santos kernel: EIP: 0010:[] Not tainted Jul 9 12:45:20 santos kernel: EFLAGS: 00010286 Jul 9 12:45:20 santos kernel: eax: 00000000 ebx: e226f730 ecx: 00000008 edx: dc356904 Jul 9 12:45:20 santos kernel: esi: 00000001 edi: f2dffc40 ebp: ffffffff esp: f7ebff30 Jul 9 12:45:20 santos kernel: ds: 0018 es: 0018 ss: 0018 Jul 9 12:45:20 santos kernel: Process kupdated (pid: 7, stackpage=f7ebf000) Jul 9 12:45:20 santos kernel: Stack: f7a41400 f7a41448 f7ebe660 0008e000 dc356904 f7a41d18 00000010 00000001 Jul 9 12:45:20 santos kernel: f7a41d18 00000000 00000010 00000001 00000001 00000000 00000008 00000008 Jul 9 12:45:20 santos kernel: 00000040 00000000 00000000 00000000 d4fad000 c65e12e0 00000004 f7ebe000 Jul 9 12:45:21 santos kernel: Call Trace: [xfs_sync+21/28] [linvfs_statfs+59/128] [sync_supers+224/276] [sync_old_buffers+47/140] [kupdate+313/320] Jul 9 12:45:21 santos kernel: Call Trace: [] [] [] [] [] Jul 9 12:45:21 santos kernel: [] [] [] Jul 9 12:45:21 santos kernel: Code: f6 45 02 40 75 3b 8b 54 24 70 f6 82 30 02 00 00 10 74 0b f6 >>EIP; c01c5384 <===== Trace; c01c5131 Trace; c01db2b7 Trace; c013ed28 Trace; c013de67 Trace; c013e185 Trace; c0105000 <_stext+0/0> Trace; c01057d2 Trace; c01057db Code; c01c5384 00000000 <_EIP>: Code; c01c5384 <===== 0: f6 45 02 40 testb $0x40,0x2(%ebp) <===== Code; c01c5388 4: 75 3b jne 41 <_EIP+0x41> c01c53c5 Code; c01c538a 6: 8b 54 24 70 mov 0x70(%esp,1),%edx Code; c01c538e a: f6 82 30 02 00 00 10 testb $0x10,0x230(%edx) Code; c01c5395 11: 74 0b je 1e <_EIP+0x1e> c01c53a2 Code; c01c5397 13: f6 00 00 testb $0x0,(%eax) Is there anything helpful I should post along with this? Thanks, Huw -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From owner-linux-xfs@oss.sgi.com Tue Jul 9 13:00:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69K0sRw029930 for ; Tue, 9 Jul 2002 13:00:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69K0r13029929 for linux-xfs-outgoing; Tue, 9 Jul 2002 13:00:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69K0mRw029899 for ; Tue, 9 Jul 2002 13:00:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA40574 for ; Tue, 9 Jul 2002 15:05:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA11318 for ; Tue, 9 Jul 2002 15:05:08 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g69K0KA13837; Tue, 9 Jul 2002 15:00:20 -0500 Message-Id: <200207092000.g69K0KA13837@jen.americas.sgi.com> Date: Tue, 9 Jul 2002 15:00:20 -0500 Subject: TAKE - clean up log reads during mount/recovery To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In working on getting xfs to do only aligned I/O for EVMS we found mount and recovery could still be non-aligned, this fixes it, or at least fixes some cases, there may be more yet. Date: Tue Jul 9 13:03:38 PDT 2002 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:122727a linux/fs/xfs/xfs_log_recover.c - 1.236 - when allocating a buffer for recovery reading the log, use a power of 2 From owner-linux-xfs@oss.sgi.com Tue Jul 9 13:18:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69KImRw030912 for ; Tue, 9 Jul 2002 13:18:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69KImC4030911 for linux-xfs-outgoing; Tue, 9 Jul 2002 13:18:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69KIPRw030860 for ; Tue, 9 Jul 2002 13:18:31 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA38140 for ; Tue, 9 Jul 2002 15:22: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 PAA58733 for ; Tue, 9 Jul 2002 15:22:45 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g69KMhB29767; Tue, 9 Jul 2002 15:22:43 -0500 Message-Id: <200207092022.g69KMhB29767@stout.americas.sgi.com> Date: Tue, 9 Jul 2002 15:22:43 -0500 Subject: TAKE - Crash diet for xfs stack usage. X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk linvfs_remount and linvfs_read_super had the humongous xfs_args struct on the stack; allocate it instead. Also, since I've been looking at xfs_bmapi() anyway, and it has fairly high stack usage, trim down one of the structs it puts on the stack. Date: Tue Jul 9 13:20:34 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122728a linux/fs/xfs/xfs_bmap.h - 1.77 linux/fs/xfs/xfs_bmap.c - 1.285 - Change xfs_bmalloca_t to use chars instead of ints to reduce stack usage; fix up associated functions. linux/fs/xfs/linux/xfs_super.c - 1.187 - Ease up on stack; allocate xfs_args struct for linvfs_read_super and linvfs_remount From owner-linux-xfs@oss.sgi.com Tue Jul 9 13:52:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69Kq4Rw032490 for ; Tue, 9 Jul 2002 13:52:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69Kq3gF032489 for linux-xfs-outgoing; Tue, 9 Jul 2002 13:52:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69KpvRw032458 for ; Tue, 9 Jul 2002 13:51:58 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA40888; Tue, 9 Jul 2002 15:56:14 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA11060; Tue, 9 Jul 2002 15:56:14 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g69KpPx23349; Tue, 9 Jul 2002 15:51:25 -0500 Subject: Re: XFS force shutdown : EFSCORRUPTED From: Steve Lord To: Hiroyuki Nakano Cc: linux-xfs@oss.sgi.com In-Reply-To: <00a301c22194$9bb063e0$3e68010a@bsd.tnes.nec.co.jp> References: <014201c21e70$611e47a0$3e68010a@bsd.tnes.nec.co.jp> <1025270852.1090.4.camel@n236> <00a301c22194$9bb063e0$3e68010a@bsd.tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 09 Jul 2002 15:51:24 -0500 Message-Id: <1026247884.24900.43.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-07-02 at 01:49, Hiroyuki Nakano wrote: > Hi Steve, > > I wanted to confirm XFS commands are executed to normaly > on mounted device. So I tried to access to mounted device. > Now I see commands are no problem to executed on mounted > device. > > Thanks a lot. > > -nak > If you try the latest CVS kernel, I would be interested in hearing if the problem is still present. I made some changes which I think will fix it. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jul 9 13:54:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69Ks5Rw032608 for ; Tue, 9 Jul 2002 13:54:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69Ks5ih032607 for linux-xfs-outgoing; Tue, 9 Jul 2002 13:54:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69KrARw032502 for ; Tue, 9 Jul 2002 13:53:10 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA43508 for ; Tue, 9 Jul 2002 15:57:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA86519 for ; Tue, 9 Jul 2002 15:57:30 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g69Kqfe23393; Tue, 9 Jul 2002 15:52:41 -0500 Message-Id: <200207092052.g69Kqfe23393@jen.americas.sgi.com> Date: Tue, 9 Jul 2002 15:52:41 -0500 Subject: TAKE - merge up to 2.5.25 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you can live with the state of the IDE subsystem, here is the latest development kernel. Steve Date: Tue Jul 9 13:54:54 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122737a linux/drivers/input/joystick/guillemot.c - 1.1 linux/drivers/char/defkeymap.c_shipped - 1.1 linux/drivers/input/joystick/iforce/iforce.h - 1.1 linux/drivers/input/keyboard/maple_keyb.c - 1.1 linux/drivers/input/keyboard/atkbd.c - 1.1 linux/drivers/tc/lk201-map.c_shipped - 1.1 linux/drivers/acorn/char/defkeymap-acorn.c_shipped - 1.1 linux/drivers/input/tsdev.c - 1.1 linux/drivers/input/touchscreen/gunze.c - 1.1 linux/drivers/input/touchscreen/Makefile - 1.1 linux/drivers/input/touchscreen/Config.in - 1.1 linux/drivers/input/touchscreen/Config.help - 1.1 linux/drivers/input/serio/rpckbd.c - 1.1 linux/drivers/input/serio/parkbd.c - 1.1 linux/drivers/input/serio/i8042.h - 1.1 linux/drivers/input/serio/i8042.c - 1.1 linux/drivers/input/serio/ct82c710.c - 1.1 linux/drivers/input/evbug.c - 1.1 linux/arch/i386/boot/compressed/vmlinux.scr - 1.1 linux/drivers/input/gameport/fm801-gp.c - 1.1 linux/drivers/input/gameport/vortex.c - 1.1 linux/drivers/input/power.c - 1.1 linux/drivers/input/mouse/sermouse.c - 1.1 linux/drivers/input/mouse/rpcmouse.c - 1.1 linux/drivers/input/mouse/psmouse.c - 1.1 linux/drivers/input/mouse/pc110pad.c - 1.1 linux/drivers/input/mouse/maplemouse.c - 1.1 linux/drivers/input/joystick/iforce/Makefile - 1.1 linux/drivers/input/mouse/logibm.c - 1.1 linux/drivers/input/joystick/iforce/iforce-ff.c - 1.1 linux/drivers/input/mouse/inport.c - 1.1 linux/drivers/input/mouse/amimouse.c - 1.1 linux/drivers/input/mouse/Makefile - 1.1 linux/drivers/input/mouse/Config.in - 1.1 linux/drivers/input/joystick/iforce/iforce-main.c - 1.1 linux/drivers/input/mouse/Config.help - 1.1 linux/drivers/input/keyboard/xtkbd.c - 1.1 linux/drivers/input/keyboard/sunkbd.c - 1.1 linux/drivers/input/keyboard/ps2serkbd.c - 1.1 linux/drivers/input/joystick/iforce/iforce-packets.c - 1.1 linux/drivers/input/joystick/iforce/iforce-serio.c - 1.1 linux/drivers/input/keyboard/amikbd.c - 1.1 linux/drivers/input/keyboard/Makefile - 1.1 linux/drivers/input/keyboard/Config.in - 1.1 linux/drivers/input/keyboard/Config.help - 1.1 linux/drivers/input/joystick/twidjoy.c - 1.1 linux/drivers/usb/core/file.c - 1.1 linux/drivers/char/qtronixmap.c_shipped - 1.1 linux/drivers/input/joystick/iforce/iforce-usb.c - 1.1 linux/net/socket.c - 1.37 linux/mm/vmscan.c - 1.104 linux/mm/swapfile.c - 1.61 linux/mm/swap_state.c - 1.42 linux/mm/slab.c - 1.35 linux/mm/page_io.c - 1.27 linux/mm/page_alloc.c - 1.83 linux/mm/mmap.c - 1.54 linux/mm/memory.c - 1.85 linux/mm/filemap.c - 1.125 linux/kernel/sysctl.c - 1.54 linux/kernel/sys.c - 1.35 linux/kernel/softirq.c - 1.23 linux/kernel/signal.c - 1.35 linux/kernel/sched.c - 1.74 linux/kernel/ksyms.c - 1.152 linux/kernel/itimer.c - 1.7 linux/kernel/fork.c - 1.62 linux/kernel/exit.c - 1.48 linux/kernel/acct.c - 1.20 linux/include/linux/times.h - 1.3 linux/include/linux/time.h - 1.7 linux/include/linux/sysctl.h - 1.52 linux/include/linux/smb.h - 1.8 linux/include/linux/sched.h - 1.75 linux/include/linux/nfsd/nfsfh.h - 1.13 linux/include/linux/nfsd/export.h - 1.13 linux/include/linux/mm.h - 1.90 linux/include/linux/list.h - 1.14 linux/include/linux/kdev_t.h - 1.7 linux/include/linux/interrupt.h - 1.21 linux/include/linux/genhd.h - 1.20 linux/include/linux/fs.h - 1.180 linux/include/linux/ext2_fs_sb.h - 1.7 linux/include/linux/devpts_fs.h - 1.4 linux/include/linux/cdrom.h - 1.22 linux/include/asm-ppc/uaccess.h - 1.11 linux/include/asm-ppc/system.h - 1.22 linux/include/asm-ppc/param.h - 1.6 linux/include/asm-ppc/page.h - 1.16 linux/include/asm-i386/param.h - 1.4 linux/fs/ufs/super.c - 1.32 linux/fs/stat.c - 1.27 linux/fs/smbfs/inode.c - 1.37 linux/fs/qnx4/inode.c - 1.37 linux/fs/proc/array.c - 1.45 linux/fs/open.c - 1.41 linux/fs/ntfs/super.c - 1.18 linux/fs/ntfs/inode.h - 1.8 linux/fs/ntfs/inode.c - 1.20 linux/fs/ntfs/dir.h - 1.8 linux/fs/ntfs/dir.c - 1.15 linux/fs/ntfs/Makefile - 1.21 linux/fs/nfsd/vfs.c - 1.53 linux/fs/nfsd/nfsfh.c - 1.43 linux/fs/nfsd/nfs3xdr.c - 1.29 linux/fs/nfsd/export.c - 1.38 linux/fs/nfs/write.c - 1.41 linux/fs/nfs/inode.c - 1.47 linux/fs/locks.c - 1.27 linux/fs/inode.c - 1.79 linux/fs/fcntl.c - 1.21 linux/fs/ext2/super.c - 1.35 linux/fs/ext2/ialloc.c - 1.28 linux/fs/ext2/balloc.c - 1.23 linux/fs/devpts/root.c - 1.16 linux/fs/devpts/inode.c - 1.18 linux/fs/devpts/devpts_i.h - 1.5 linux/fs/devpts/Makefile - 1.5 linux/fs/coda/inode.c - 1.27 linux/fs/buffer.c - 1.126 linux/fs/block_dev.c - 1.50 linux/fs/binfmt_elf.c - 1.43 linux/fs/Makefile - 1.60 linux/drivers/scsi/u14-34f.c - 1.23 linux/drivers/scsi/st.h - 1.14 linux/drivers/scsi/st.c - 1.46 linux/drivers/scsi/sr_ioctl.c - 1.25 linux/drivers/scsi/sr.c - 1.46 linux/drivers/scsi/sg.c - 1.32 linux/drivers/scsi/sd.c - 1.63 linux/drivers/scsi/scsi_syms.c - 1.19 linux/drivers/scsi/scsi_error.c - 1.27 linux/drivers/scsi/scsi_debug.c - 1.21 linux/drivers/scsi/scsi.h - 1.30 linux/drivers/scsi/scsi.c - 1.57 linux/drivers/scsi/inia100.h - 1.10 linux/drivers/scsi/inia100.c - 1.19 linux/drivers/scsi/ide-scsi.c - 1.39 linux/drivers/scsi/i60uscsi.h - 1.8 linux/drivers/scsi/i60uscsi.c - 1.8 linux/drivers/scsi/hosts.h - 1.22 linux/drivers/scsi/hosts.c - 1.30 linux/drivers/scsi/eata.c - 1.25 linux/drivers/scsi/constants.c - 1.12 linux/drivers/scsi/aha1542.c - 1.26 linux/drivers/net/hamradio/soundmodem/Makefile - 1.7 linux/drivers/net/3c59x.c - 1.35 linux/drivers/char/tty_io.c - 1.46 linux/drivers/char/pty.c - 1.13 linux/drivers/char/Makefile - 1.64 linux/drivers/cdrom/cdrom.c - 1.42 linux/drivers/block/ll_rw_blk.c - 1.107 linux/drivers/acorn/char/Makefile - 1.13 linux/arch/sparc64/kernel/signal32.c - 1.25 linux/arch/sparc64/kernel/signal.c - 1.23 linux/arch/sparc64/Makefile - 1.19 linux/arch/sparc/kernel/signal.c - 1.25 linux/arch/sparc/boot/Makefile - 1.5 linux/arch/sparc/Makefile - 1.12 linux/arch/ppc/mm/init.c - 1.43 linux/arch/ppc/lib/string.S - 1.9 linux/arch/ppc/kernel/traps.c - 1.26 linux/arch/ppc/kernel/syscalls.c - 1.14 linux/arch/ppc/kernel/prom.c - 1.30 linux/arch/ppc/kernel/process.c - 1.37 linux/arch/ppc/kernel/ppc_ksyms.c - 1.45 linux/arch/ppc/kernel/pci.c - 1.27 linux/arch/ppc/kernel/open_pic.c - 1.26 linux/arch/ppc/kernel/mk_defs.c - 1.18 linux/arch/ppc/kernel/misc.S - 1.41 linux/arch/ppc/kernel/head.S - 1.34 linux/arch/ppc/config.in - 1.53 linux/arch/ppc/Makefile - 1.26 linux/arch/mips/Makefile - 1.12 linux/arch/m68k/Makefile - 1.9 linux/arch/i386/mm/fault.c - 1.24 linux/arch/i386/kernel/apm.c - 1.48 linux/arch/i386/boot/compressed/Makefile - 1.11 linux/arch/i386/boot/Makefile - 1.16 linux/arch/i386/Makefile - 1.28 linux/arch/arm/boot/compressed/Makefile - 1.23 linux/arch/arm/boot/Makefile - 1.17 linux/arch/arm/Makefile - 1.30 linux/arch/alpha/Makefile - 1.16 linux/Rules.make - 1.28 linux/Makefile - 1.206 linux/Documentation/filesystems/ntfs.txt - 1.17 linux/fs/hpfs/super.c - 1.19 linux/drivers/tc/Makefile - 1.5 linux/net/khttpd/Makefile - 1.7 linux/fs/partitions/check.c - 1.44 linux/arch/ppc/kernel/entry.S - 1.28 linux/arch/sh/boot/Makefile - 1.7 linux/arch/sh/Makefile - 1.10 linux/fs/udf/super.c - 1.33 linux/drivers/char/drm/gamma_drv.c - 1.13 linux/drivers/char/drm/gamma_dma.c - 1.10 linux/drivers/char/drm/drm.h - 1.10 linux/fs/proc/proc_misc.c - 1.36 linux/drivers/scsi/sun3_scsi.c - 1.12 linux/arch/ppc/kernel/head_4xx.S - 1.9 linux/kernel/timer.c - 1.26 linux/drivers/scsi/scsi_merge.c - 1.40 linux/drivers/scsi/scsi_lib.c - 1.47 linux/include/linux/input.h - 1.17 linux/arch/ppc/kernel/ppc4xx_pic.c - 1.5 linux/drivers/ieee1394/ieee1394_core.c - 1.19 linux/drivers/scsi/scsi_scan.c - 1.26 linux/arch/ia64/Makefile - 1.15 linux/drivers/scsi/qla1280.c - 1.17 linux/include/linux/raid/md_k.h - 1.23 linux/include/linux/raid/md.h - 1.15 linux/include/linux/raid/linear.h - 1.4 linux/drivers/scsi/sun3_NCR5380.c - 1.4 linux/drivers/video/matrox/matroxfb_crtc2.c - 1.10 linux/drivers/video/matrox/matroxfb_base.c - 1.18 linux/arch/mips64/Makefile - 1.10 linux/include/linux/usb.h - 1.40 linux/drivers/ide/ide-cd.c - 1.39 linux/Documentation/DocBook/Makefile - 1.33 linux/Documentation/DocBook/kernel-api.tmpl - 1.18 linux/fs/ramfs/inode.c - 1.26 linux/arch/ppc/8260_io/Config.in - 1.5 linux/include/linux/raid/raid5.h - 1.8 linux/include/linux/raid/raid1.h - 1.10 linux/arch/s390/boot/Makefile - 1.10 linux/arch/s390/Makefile - 1.9 linux/fs/xfs/xfsidbg.c - 1.190 linux/fs/xfs/xfs_mount.c - 1.291 linux/fs/xfs/linux/xfs_lrw.c - 1.153 linux/kdb/modules/kdbm_vm.c - 1.22 linux/kdb/modules/kdbm_pg.c - 1.62 linux/Documentation/filesystems/Locking - 1.18 linux/drivers/char/drm/r128_drv.h - 1.8 linux/drivers/char/drm/r128_drv.c - 1.8 linux/drivers/char/drm/r128_drm.h - 1.5 linux/drivers/char/drm/mga_state.c - 1.8 linux/drivers/char/drm/mga_drv.c - 1.7 linux/drivers/char/drm/mga_drm.h - 1.4 linux/drivers/char/drm/mga_dma.c - 1.6 linux/drivers/char/drm/i810_drv.c - 1.7 linux/drivers/char/drm/i810_drm.h - 1.4 linux/drivers/char/drm/i810_dma.c - 1.16 linux/drivers/usb/storage/usb.h - 1.13 linux/drivers/usb/storage/usb.c - 1.23 linux/drivers/usb/storage/transport.c - 1.23 linux/fs/jffs/inode-v23.c - 1.28 linux/drivers/acorn/char/defkeymap-acorn.c - 1.5 linux/arch/sh/boot/compressed/Makefile - 1.4 linux/arch/ppc/configs/est8260_defconfig - 1.14 linux/drivers/input/mousedev.c - 1.10 linux/drivers/input/keybdev.c - 1.9 linux/drivers/input/joydev.c - 1.10 linux/drivers/input/input.c - 1.9 linux/drivers/input/evdev.c - 1.10 linux/drivers/input/Makefile - 1.6 linux/drivers/input/Config.in - 1.4 linux/drivers/md/raid1.c - 1.22 linux/drivers/md/raid5.c - 1.29 linux/drivers/md/linear.c - 1.10 linux/drivers/md/md.c - 1.49 linux/mm/oom_kill.c - 1.15 linux/arch/parisc/Makefile - 1.4 linux/mm/shmem.c - 1.41 linux/drivers/scsi/osst.c - 1.15 linux/drivers/char/drm/r128_state.c - 1.4 linux/drivers/char/drm/r128_cce.c - 1.5 linux/drivers/char/drm/radeon_cp.c - 1.7 linux/drivers/char/drm/radeon_drm.h - 1.4 linux/drivers/char/drm/radeon_drv.c - 1.4 linux/drivers/char/drm/radeon_drv.h - 1.5 linux/drivers/char/drm/radeon_state.c - 1.4 linux/fs/reiserfs/buffer2.c - 1.13 linux/include/linux/reiserfs_fs.h - 1.27 linux/include/linux/reiserfs_fs_sb.h - 1.14 linux/arch/cris/Makefile - 1.12 linux/arch/cris/boot/compressed/Makefile - 1.4 linux/arch/s390x/boot/Makefile - 1.9 linux/arch/s390x/Makefile - 1.8 linux/arch/cris/boot/rescue/Makefile - 1.3 linux/fs/freevxfs/vxfs_super.c - 1.10 linux/arch/ppc/boot/prep/Makefile - 1.8 linux/arch/ppc/boot/pmac/Makefile - 1.6 linux/arch/ppc/boot/chrp/Makefile - 1.6 linux/drivers/usb/usb-skeleton.c - 1.13 linux/drivers/message/fusion/Makefile - 1.5 linux/drivers/char/drm/mga_warp.c - 1.2 linux/drivers/char/drm/drm_context.h - 1.5 linux/arch/ppc/mm/4xx_mmu.c - 1.4 linux/arch/ppc/mm/cachemap.c - 1.5 linux/arch/ppc/kernel/l2cr.S - 1.4 linux/arch/ppc/kernel/cputable.c - 1.6 linux/arch/mips/philips/nino/ramdisk/Makefile - 1.2 linux/drivers/scsi/53c700.c - 1.8 linux/drivers/scsi/53c700.h - 1.5 linux/include/linux/raid/multipath.h - 1.4 linux/drivers/md/multipath.c - 1.10 linux/include/asm-ppc/commproc.h - 1.2 linux/fs/jbd/journal.c - 1.14 linux/fs/ext3/ialloc.c - 1.13 linux/fs/ext3/inode.c - 1.15 linux/fs/ext3/super.c - 1.19 linux/include/linux/jbd.h - 1.9 linux/include/linux/ext3_fs_sb.h - 1.3 linux/fs/jbd/transaction.c - 1.11 linux/fs/ext3/balloc.c - 1.8 linux/fs/jbd/commit.c - 1.7 linux/fs/jbd/checkpoint.c - 1.5 linux/include/linux/bio.h - 1.11 linux/fs/driverfs/inode.c - 1.15 linux/fs/bio.c - 1.16 linux/include/linux/gfp.h - 1.2 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.17 linux/arch/ppc/8260_io/Config.help - 1.2 linux/arch/ppc/Config.help - 1.9 linux/drivers/input/Config.help - 1.3 linux/drivers/input/joystick/gamecon.c - 1.3 linux/drivers/input/joystick/db9.c - 1.3 linux/drivers/input/joystick/adi.c - 1.3 linux/drivers/input/joystick/Makefile - 1.3 linux/drivers/input/joystick/Config.in - 1.2 linux/drivers/input/joystick/Config.help - 1.2 linux/drivers/input/joystick/iforce.c - 1.3 linux/drivers/input/gameport/pcigame.c - 1.3 linux/drivers/input/gameport/gameport.c - 1.3 linux/drivers/input/gameport/Makefile - 1.3 linux/drivers/input/gameport/Config.in - 1.2 linux/drivers/input/gameport/Config.help - 1.2 linux/drivers/input/joystick/magellan.c - 1.3 linux/drivers/input/serio/Config.help - 1.2 linux/drivers/input/serio/Config.in - 1.2 linux/drivers/input/serio/Makefile - 1.3 linux/Documentation/filesystems/porting - 1.12 linux/arch/ppc/boot/simple/Makefile - 1.3 linux/sound/oss/maestro.c - 1.3 linux/arch/ppc/platforms/chrp_setup.c - 1.6 linux/arch/ppc/platforms/ep405.c - 1.3 linux/arch/ppc/platforms/lopec_setup.c - 1.6 linux/arch/ppc/platforms/mbx.h - 1.2 linux/arch/ppc/platforms/pmac_nvram.c - 1.3 linux/arch/ppc/platforms/pmac_pic.c - 1.4 linux/arch/ppc/platforms/prep_pci.c - 1.3 linux/arch/ppc/platforms/prep_setup.c - 1.6 linux/arch/ppc/platforms/rpxclassic.h - 1.3 linux/arch/ppc/platforms/rpxlite.h - 1.3 linux/arch/ppc/platforms/spd8xx.h - 1.2 linux/arch/ppc/platforms/tqm8xx.h - 1.2 linux/arch/x86_64/Makefile - 1.6 linux/arch/x86_64/boot/Makefile - 1.6 linux/arch/x86_64/boot/compressed/Makefile - 1.2 linux/include/asm-ppc/ppc_asm.h - 1.3 linux/include/asm-ppc/open_pic.h - 1.3 linux/arch/ppc64/Makefile - 1.5 linux/arch/ppc64/boot/Makefile - 1.3 linux/fs/jfs/jfs_incore.h - 1.6 linux/fs/jfs/jfs_logmgr.c - 1.10 linux/fs/jfs/jfs_mount.c - 1.6 linux/fs/jfs/jfs_txnmgr.c - 1.8 linux/drivers/net/e100/e100.h - 1.5 linux/fs/libfs.c - 1.5 linux/include/asm-ppc/tlbflush.h - 1.3 linux/drivers/usb/class/bluetty.c - 1.4 linux/drivers/usb/class/printer.c - 1.6 linux/drivers/usb/core/Makefile - 1.6 linux/drivers/usb/core/inode.c - 1.4 linux/drivers/usb/core/usb.c - 1.8 linux/drivers/usb/host/Config.help - 1.3 linux/drivers/usb/host/Config.in - 1.6 linux/drivers/usb/host/ohci-dbg.c - 1.4 linux/drivers/usb/host/ohci-hcd.c - 1.7 linux/drivers/usb/image/mdc800.c - 1.5 linux/drivers/usb/image/scanner.c - 1.7 linux/drivers/usb/input/hiddev.c - 1.5 linux/drivers/usb/media/dabusb.c - 1.6 linux/drivers/usb/net/rtl8150.c - 1.5 linux/drivers/usb/net/pegasus.h - 1.5 linux/drivers/usb/net/pegasus.c - 1.6 linux/mm/pdflush.c - 1.4 linux/drivers/usb/misc/auerswald.c - 1.5 linux/drivers/usb/misc/rio500.c - 1.3 linux/drivers/usb/misc/brlvger.c - 1.4 linux/drivers/isdn/capi/capifs.c - 1.3 linux/fs/ntfs/attrib.c - 1.5 linux/fs/ntfs/volume.h - 1.4 linux/fs/ntfs/ntfs.h - 1.4 linux/fs/ntfs/namei.c - 1.5 linux/fs/ntfs/mst.c - 1.2 linux/fs/ntfs/mft.c - 1.4 linux/fs/ntfs/ChangeLog - 1.5 linux/fs/ntfs/aops.c - 1.5 linux/drivers/usb/host/uhci-hcd.c - 1.4 linux/drivers/usb/host/usb-uhci-hcd.c - 1.3 linux/drivers/pci/pool.c - 1.2 linux/fs/fs-writeback.c - 1.4 linux/drivers/usb/host/usb-uhci-q.c - 1.3 linux/mm/page-writeback.c - 1.5 linux/include/linux/buffer_head.h - 1.6 linux/include/linux/writeback.h - 1.5 linux/kernel/suspend.c - 1.6 linux/Documentation/swsusp.txt - 1.2 linux/drivers/ide/probe.c - 1.5 linux/drivers/char/drm/sis_drm.h - 1.2 linux/drivers/char/drm/i830_drv.c - 1.2 linux/drivers/char/drm/i830_drm.h - 1.2 linux/drivers/char/drm/i830_dma.c - 1.2 linux/drivers/char/drm/gamma_drm.h - 1.2 linux/fs/mpage.c - 1.3 linux/drivers/usb/input/aiptek.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jul 9 13:59:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69Kx4Rw000565 for ; Tue, 9 Jul 2002 13:59:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69Kx3dB000564 for linux-xfs-outgoing; Tue, 9 Jul 2002 13:59:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69KwxRw000515 for ; Tue, 9 Jul 2002 13:58:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA45072 for ; Tue, 9 Jul 2002 16:03:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA15682 for ; Tue, 9 Jul 2002 16:03:20 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g69KwVb23453; Tue, 9 Jul 2002 15:58:31 -0500 Message-Id: <200207092058.g69KwVb23453@jen.americas.sgi.com> Date: Tue, 9 Jul 2002 15:58:31 -0500 Subject: TAKE - simplify xfs getblock code To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, this is the last chunk of code I have lurking for now. Date: Tue Jul 9 14:02:23 PDT 2002 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:122739a linux/fs/xfs/linux/xfs_iops.c - 1.158 - remove some page zeroing from the read path of getblock. From owner-linux-xfs@oss.sgi.com Tue Jul 9 14:34:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69LY0Rw001909 for ; Tue, 9 Jul 2002 14:34:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69LY0qG001908 for linux-xfs-outgoing; Tue, 9 Jul 2002 14:34:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69LXqRw001867 for ; Tue, 9 Jul 2002 14:33:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA39904; Tue, 9 Jul 2002 16:38:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA97543; Tue, 9 Jul 2002 16:38:13 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g69LXNe01463; Tue, 9 Jul 2002 16:33:23 -0500 Subject: Re: about the mmap problem From: Steve Lord To: Juha K Kallio Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020620223333.GA23109@banix> References: <20020620223333.GA23109@banix> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 09 Jul 2002 16:33:23 -0500 Message-Id: <1026250403.1379.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-20 at 17:33, Juha K Kallio wrote: > Is the problem really fixed? This doesn't look like it.. > > root@jaenoe:/ > /usr/src/xfs-cmd/mapcheck boot > boot/map > 13 files scanned 1 files fixed > root@jaenoe:/ > lilo > Added linux * > Added linux.old > root@jaenoe:/ > /usr/src/xfs-cmd/mapcheck boot > boot/map > 13 files scanned 1 files fixed OK, I think I found one more corner case of this when a file gets truncated down to a smaller size, but I do not think lilo does that. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jul 9 21:13:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6A4DJRw014442 for ; Tue, 9 Jul 2002 21:13:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6A4D4n4014436 for linux-xfs-outgoing; Tue, 9 Jul 2002 21:13:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6A4CVRw014392 for ; Tue, 9 Jul 2002 21:12:46 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 VAA07423 for ; Tue, 9 Jul 2002 21:16:32 -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 OAA05933; Wed, 10 Jul 2002 14:12:30 +1000 (EST) Date: Wed, 10 Jul 2002 14:12:30 +1000 (EST) From: Nathan Scott Message-Id: <200207100412.OAA05933@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - acl-2.0.15 X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 9 21:12:35 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122762a cmd/acl/VERSION - 1.32 cmd/acl/doc/CHANGES - 1.37 cmd/acl/debian/changelog - 1.27 - bump version, document changes. cmd/acl/doc/PORTING - 1.5 - fix some typos - refering to "attr" instead of "acl". cmd/acl/configure.in - 1.18 cmd/acl/libacl/byteorder.h - 1.3 cmd/acl/include/config.h.in - 1.2 - Fix configure warning (autoconf 2.13) - namely: "AC_TRY_RUN called without default to allow cross compiling" cmd/acl/man/man1/chacl.1 - 1.6 cmd/acl/man/man5/acl.5 - 1.13 - fix minor typos. cmd/acl/debian/rules - 1.9 - fix a build issue. From owner-linux-xfs@oss.sgi.com Tue Jul 9 22:47:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6A5l7Rw015641 for ; Tue, 9 Jul 2002 22:47:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6A5l6Dk015640 for linux-xfs-outgoing; Tue, 9 Jul 2002 22:47:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6A5kxRw015612 for ; Tue, 9 Jul 2002 22:46:59 -0700 Received: from Traveller.attbi.com ([12.237.135.160]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020710055122.ZDTI8262.rwcrmhc52.attbi.com@Traveller.attbi.com> for ; Wed, 10 Jul 2002 05:51:22 +0000 Received: from Traveller.attbi.com (localhost.attbi.com [127.0.0.1]) by Traveller.attbi.com (8.12.2/8.12.2) with ESMTP id g6A5pYc7003058 for ; Wed, 10 Jul 2002 00:51:37 -0500 Received: from localhost (localhost [[UNIX: localhost]]) by Traveller.attbi.com (8.12.2/8.12.1/Submit) id g6A5pX5G003057 for linux-xfs@oss.sgi.com; Wed, 10 Jul 2002 00:51:33 -0500 Message-Id: <200207100551.g6A5pX5G003057@Traveller.attbi.com> Content-Type: text/plain; charset="iso-8859-1" From: Kelledin To: linux-xfs@oss.sgi.com Subject: XFS and grub-0.92 Date: Wed, 10 Jul 2002 00:51:33 -0500 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (Sorry if this is a dupe message, but apparently bug-grub@gnu.org is down, and this screwed with the first send. I couldn't be quite sure that this one got through, so I'm resending it). Lately, I've found a problem that I'm pretty sure is a grub problem. It happens to coincide with a problem mentioned in the SGI XFS FAQ, concerning the occurrence of the following syslogged errors: XFS: bad magic number XFS: SB validate failed The problem occurs when I try to run "root(hd0,13); setup (hd0,13)" in the grub shell. "root(hd0,13)" seems to work fine (reports an XFS filesystem with magic number 0x83), but "setup(hd0,13)" doesn't--in particular, the "embed" commands fail, and when I try to run them manually, they complain that they cannot mount the partition. FYI, (hd0,13) is /dev/sda14, and it's an XFS filesystem. What's even more annoying is that in the process of failing, grub seems to damage the filesystem on /dev/sda14. The next time I try to mount /dev/sda14, it reports "wrong fs type, bad magic number..."--the typical generic error message. It's about this time that I get the "XFS: bad magic number" etc. messages in my syslogs. I have to run xfs_repair -L to get the fs back to where I can mount it again. Most of the files seem to be intact... This is especially odd, since XFS+grub works just fine on another box. Yet lilo works where grub fails...well, at least I have options. Please cc all replies to me, as I'm not subscribed to the list. -- Kelledin "If a server crashes in a server farm and no one pings it, does it still cost four figures to fix?" From owner-linux-xfs@oss.sgi.com Tue Jul 9 23:15:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6A6FORw023139 for ; Tue, 9 Jul 2002 23:15:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6A6FOBg023138 for linux-xfs-outgoing; Tue, 9 Jul 2002 23:15:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6A6FARw023109 for ; Tue, 9 Jul 2002 23:15:10 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 5A094C70B44; Wed, 10 Jul 2002 16:19:31 +1000 (EST) Date: Wed, 10 Jul 2002 16:19:31 +1000 From: Ian Cumming To: Kelledin Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and grub-0.92 Message-ID: <20020710061931.GA18472@ids.org.au> References: <200207100551.g6A5pX5G003057@Traveller.attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200207100551.g6A5pX5G003057@Traveller.attbi.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Kelledin, I've found this problem too. I tried to install grub onto the root partition of a drive, and was not able to boot (with the same error). It appears that you cannot install grub onto the root partition without corrupting the XFS fs. However, I can install grub into the MBR of the drive, and successfully boot from the root partition in this manner. My knowledge of this problem is very limited, because I could not afford to break my system again by investigating it! With this in mind, I can only offer an anecdotal intepretation of the problem, howerver I am sure that others in this list can offer a far better explanation. Here is the system documentation I have for grub, which might be of use to you. I am running Debian Testing, with XFS 1.1. - apt-get install grub - edit /sbin/update-grub - comment out "savedefault" lines (option does not work on XFS) - follow instructions in /usr/share/doc/grub/README.Debian - grub-install /dev/hda (note, do not put /dev/hda5! This will corrupt your FS!) - update-grub - edit /boot/grub/menu.lst - add password - set # kopt=root=/dev/hda5 # ro - set # groot=(hd0,4) - set # lockalternative=true - update-grub (builds entries in menu.lst) - edit /etc/kernel-pkg.conf, add: (as instructed in /usr/share/doc/grub/README.Debian) - postinst_hook = /sbin/update-grub - postrm_hook = /sbin/update-grub - do_bootloader = no hope this helps, Ian. On Wed, Jul 10, 2002 at 12:51:33AM -0500, Kelledin wrote: > (Sorry if this is a dupe message, but apparently bug-grub@gnu.org is down, > and this screwed with the first send. I couldn't be quite sure that this one > got through, so I'm resending it). > > Lately, I've found a problem that I'm pretty sure is a grub problem. It > happens to coincide with a problem mentioned in the SGI XFS FAQ, concerning > the occurrence of the following syslogged errors: > > XFS: bad magic number > XFS: SB validate failed > > The problem occurs when I try to run "root(hd0,13); setup (hd0,13)" in the > grub shell. "root(hd0,13)" seems to work fine (reports an XFS filesystem > with magic number 0x83), but "setup(hd0,13)" doesn't--in particular, the > "embed" commands fail, and when I try to run them manually, they complain > that they cannot mount the partition. FYI, (hd0,13) is /dev/sda14, and it's > an XFS filesystem. > > What's even more annoying is that in the process of failing, grub seems to > damage the filesystem on /dev/sda14. The next time I try to mount > /dev/sda14, it reports "wrong fs type, bad magic number..."--the typical > generic error message. It's about this time that I get the "XFS: bad magic > number" etc. messages in my syslogs. I have to run xfs_repair -L to get the > fs back to where I can mount it again. Most of the files seem to be intact... > > This is especially odd, since XFS+grub works just fine on another box. Yet > lilo works where grub fails...well, at least I have options. > > Please cc all replies to me, as I'm not subscribed to the list. > > -- > Kelledin > "If a server crashes in a server farm and no one pings it, does it still cost > four figures to fix?" -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 From owner-linux-xfs@oss.sgi.com Wed Jul 10 00:14:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6A7E4Rw023690 for ; Wed, 10 Jul 2002 00:14:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6A7E4TI023689 for linux-xfs-outgoing; Wed, 10 Jul 2002 00:14:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6A7DqRw023659 for ; Wed, 10 Jul 2002 00:13:52 -0700 Received: from erbenson.alaska.net (18-pm33.nwc.alaska.net [209.112.159.18]) by iris.slb.nwc.acsalaska.net (8.12.5/8.12.5) with ESMTP id g6A7IIE4032459 for ; Tue, 9 Jul 2002 23:18:18 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id B46E63977 for ; Tue, 9 Jul 2002 23:18:17 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 57ACD10293; Tue, 9 Jul 2002 23:18:17 -0800 (AKDT) Date: Tue, 9 Jul 2002 23:18:17 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS and grub-0.92 Message-ID: <20020709231817.B32081@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200207100551.g6A5pX5G003057@Traveller.attbi.com> <20020710061931.GA18472@ids.org.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020710061931.GA18472@ids.org.au>; from ian@ids.org.au on Wed, Jul 10, 2002 at 04:19:31PM +1000 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2002 at 04:19:31PM +1000, Ian Cumming wrote: > Hi Kelledin, >=20 > I've found this problem too. I tried to install grub onto the root > partition of a drive, and was not able to boot (with the same error). thats because you just scribbled the XFS superblock. > It appears that you cannot install grub onto the root partition without > corrupting the XFS fs. However, I can install grub into the MBR of the > drive, and successfully boot from the root partition in this manner. that is correct. XFS puts its superblock right at block zero of the partition instead of block 2 like ext2 (which leaves 1024 bytes of unused space at the start of the partition for things like bootloaders).=20 > My knowledge of this problem is very limited, because I could not afford > to break my system again by investigating it! With this in mind, I can > only offer an anecdotal intepretation of the problem, howerver I am sure > that others in this list can offer a far better explanation. you must install the first stage bootloader in the MBR, you must not install it on the partition if that partition is XFS, you WILL destroy the XFS superblock. this is the same `bug' people kept reporting in lilo until someone finally patched it (im not sure that patch ever made it upstream) to check for XFS and refuse to proceed if its detected. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0r37kACgkQJKx7GixEevx/eACfcJ+hQrnPxb04fitTpkgU93vc qqgAnRovR+h3K4ctOPz50eNOf+3fJpqD =M5GW -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- From owner-linux-xfs@oss.sgi.com Wed Jul 10 00:38:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6A7ceRw027874 for ; Wed, 10 Jul 2002 00:38:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6A7ce1O027873 for linux-xfs-outgoing; Wed, 10 Jul 2002 00:38:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6A7cYRw027845 for ; Wed, 10 Jul 2002 00:38:34 -0700 Received: from Traveller.attbi.com ([12.237.135.160]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020710074257.PHLC29588.sccrmhc01.attbi.com@Traveller.attbi.com>; Wed, 10 Jul 2002 07:42:57 +0000 Received: from Traveller.attbi.com (localhost.attbi.com [127.0.0.1]) by Traveller.attbi.com (8.12.2/8.12.2) with ESMTP id g6A7hCc7003201; Wed, 10 Jul 2002 02:43:15 -0500 Received: from localhost (localhost [[UNIX: localhost]]) by Traveller.attbi.com (8.12.2/8.12.1/Submit) id g6A7hBiJ003200; Wed, 10 Jul 2002 02:43:11 -0500 Message-Id: <200207100743.g6A7hBiJ003200@Traveller.attbi.com> Content-Type: text/plain; charset="iso-8859-1" From: Kelledin To: Ian Cumming Subject: Re: XFS and grub-0.92 Date: Wed, 10 Jul 2002 02:43:11 -0500 X-Mailer: KMail [version 1.3.2] References: <200207100551.g6A5pX5G003057@Traveller.attbi.com> <20020710061931.GA18472@ids.org.au> In-Reply-To: <20020710061931.GA18472@ids.org.au> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I've found this problem too. I tried to install grub onto the root > partition of a drive, and was not able to boot (with the same error). > > It appears that you cannot install grub onto the root partition without > corrupting the XFS fs. However, I can install grub into the MBR of the > drive, and successfully boot from the root partition in this manner. > > My knowledge of this problem is very limited, because I could not afford > to break my system again by investigating it! With this in mind, I can > only offer an anecdotal intepretation of the problem, howerver I am sure > that others in this list can offer a far better explanation. Come to think of it, this is exactly what my experience bears out. The one box I have with XFS+grub working has grub on the MBR, and the one where it doesn't work...well, we've been through that. I just went through the XFS FAQ again and found something else...particularly concerning LILO. It has the same problem as grub--it can't be installed on the bootsector of a root partition, because it overwrites the XFS superblock. This is apparently a limitation of XFS; only reason it worked with lilo is because I had lilo's bootsector residing on floppy. -- Kelledin "If a server crashes in a server farm and no one pings it, does it still cost four figures to fix?" From owner-linux-xfs@oss.sgi.com Wed Jul 10 01:17:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6A8H9Rw028396 for ; Wed, 10 Jul 2002 01:17:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6A8H9kO028395 for linux-xfs-outgoing; Wed, 10 Jul 2002 01:17:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from etoile.infra.idealx.com (sete.idealx.com [213.41.87.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6A8H2Rw028367 for ; Wed, 10 Jul 2002 01:17:03 -0700 Received: (qmail 19187 invoked by uid 500); 10 Jul 2002 08:21:28 -0000 From: "Jérôme Tournier" Date: Wed, 10 Jul 2002 10:21:28 +0200 To: linux-xfs@oss.sgi.com Subject: kernel-headers Message-ID: <20020710102128.A19183@etoile.ird.idealx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I downloaded the kernel for RedHat 7.3 but can't find the kernel-headers RPM package. I compiled the packages from the kernel sources src.rpm but it does not generate the kernel-headers one. Why it is not defined in the spec ? Thanks i downloaded the RPM from ftp://oss.sgi.com/projects/xfs/download/latest/installer/installer/i386/RH7.3-SGI-XFS-1.1/RedHat/RPMS/ -- Jérôme From owner-linux-xfs@oss.sgi.com Wed Jul 10 01:50:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6A8ogRw028817 for ; Wed, 10 Jul 2002 01:50:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6A8ogdE028816 for linux-xfs-outgoing; Wed, 10 Jul 2002 01:50:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6A8oRRw028786 for ; Wed, 10 Jul 2002 01:50:28 -0700 Received: from koschikode.com (pktomo.altus.de [192.168.0.62]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 12EE8F562; Wed, 10 Jul 2002 10:54:52 +0200 (CEST) Message-ID: <3D2BF65B.5030802@koschikode.com> Date: Wed, 10 Jul 2002 10:54:51 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?J=E9r=F4me_Tournier?= Cc: linux-xfs@oss.sgi.com Subject: Re: kernel-headers References: <20020710102128.A19183@etoile.ird.idealx.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jérôme Tournier wrote: > Hi, > I downloaded the kernel for RedHat 7.3 but can't find the kernel-headers RPM > package. I compiled the packages from the kernel sources src.rpm but it does not > generate the kernel-headers one. Why it is not defined in the spec ? The kernel headers are now in a package called glibc-kernheaders-2.4. Looks like they are now completely independant from the kernel. Cheers, Juri -- If each of us have one object, and we exchange them, then each of us still has one object. If each of us have one idea, and we exchange them, then each of us now has two ideas. From owner-linux-xfs@oss.sgi.com Wed Jul 10 02:22:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6A9MbRw031466 for ; Wed, 10 Jul 2002 02:22:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6A9Mbnf031465 for linux-xfs-outgoing; Wed, 10 Jul 2002 02:22:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6A9MWRw031433 for ; Wed, 10 Jul 2002 02:22:33 -0700 Received: from online.no (213-187-165-28.dd.nextgentel.com [213.187.165.28]) by mail.broadpark.no (Postfix) with ESMTP id BAF2E7DF1 for ; Wed, 10 Jul 2002 11:26:54 +0200 (MEST) Message-ID: <3D2BFC15.574702F8@online.no> Date: Wed, 10 Jul 2002 11:19:18 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5acustom i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: plans for new release,update redate 2.4.18-5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What are there plans for a new XFS release, and are there any plans for an update Linux 2.4.18-5 with xfs patch in? Is SGI lobbying Redhat to include XFS in its next release as option like JFS? Have you started to feed linux with xfs patch in small bits? From owner-linux-xfs@oss.sgi.com Wed Jul 10 03:05:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AA51Rw020520 for ; Wed, 10 Jul 2002 03:05:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AA510F020519 for linux-xfs-outgoing; Wed, 10 Jul 2002 03:05:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AA4uRw020479 for ; Wed, 10 Jul 2002 03:04:56 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA30853; Wed, 10 Jul 2002 05:09:19 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-38.corp.sgi.com [134.15.64.38]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id FAA44549; Wed, 10 Jul 2002 05:09:18 -0500 (CDT) Subject: Re: XFS and grub-0.92 From: Stephen Lord To: Kelledin Cc: Ian Cumming , linux-xfs@oss.sgi.com In-Reply-To: <200207100743.g6A7hBiJ003200@Traveller.attbi.com> References: <200207100551.g6A5pX5G003057@Traveller.attbi.com> <20020710061931.GA18472@ids.org.au> <200207100743.g6A7hBiJ003200@Traveller.attbi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Jul 2002 05:06:38 -0500 Message-Id: <1026295600.1229.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-10 at 02:43, Kelledin wrote: > I just went through the XFS FAQ again and found something else...particularly > concerning LILO. It has the same problem as grub--it can't be installed on > the bootsector of a root partition, because it overwrites the XFS superblock. > This is apparently a limitation of XFS; only reason it worked with lilo is > because I had lilo's bootsector residing on floppy. The issue is that the XFS on disk format is the Irix format which starts at block zero. Changing the format was not really an option. Steve From owner-linux-xfs@oss.sgi.com Wed Jul 10 03:50:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AAosRw021027 for ; Wed, 10 Jul 2002 03:50:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AAosXf021026 for linux-xfs-outgoing; Wed, 10 Jul 2002 03:50:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AAogRw020995 for ; Wed, 10 Jul 2002 03:50:43 -0700 Received: from hamburg.fcb.com ([170.200.66.61]) by hammail1.truenorth.com (Netscape Messaging Server 4.15 hammail1 May 24 2002 10:21:14) with ESMTP id GZ14ZM00.7IJ for ; Wed, 10 Jul 2002 12:54:58 +0200 Message-ID: <3D2C1289.96B90856@hamburg.fcb.com> Date: Wed, 10 Jul 2002 12:55:05 +0200 From: Harald Wagener Organization: FCB Wilkens X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: plans for new release,update redate 2.4.18-5 References: <3D2BFC15.574702F8@online.no> Content-Type: multipart/mixed; boundary="------------A82CB27F46E45C82CC7CBCDE" X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------A82CB27F46E45C82CC7CBCDE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Knut J Bjuland wrote: > > What are there plans for a new XFS release, Releases are made as an add on iso image whith which You can install RedHat on a PC. The other way to obtain an xfs-aware linux kernel is to use a cvs version, or to use some kernel branch that already has xfs inside > and are there any plans for > an update Linux 2.4.18-5 with xfs patch in? Definitely there is a 2.4.18 version in cvs. I don't know if it's relative to 2.4.18-5, which seems to be a redhat kernel. At this time, RedHat folks would be the ones to be asked for xfs inclusion (by You, that is).... > Is SGI lobbying Redhat to > include XFS in its next release as option like JFS? Not that I know of, but I am not with SGI. > Have you started to > feed linux with xfs patch in small bits? Not that I know of, but I am not with SGI. As far as I know, this cannot be easily done, although a lot of code cleanup is done these days. The mailing list archives have all the meaty details. Regards, Harald -- Harald Wagener*An der Alster 42*20099 Hamburg*http://www.fcb-wilkens.com --------------A82CB27F46E45C82CC7CBCDE Content-Type: text/x-vcard; charset=us-ascii; name="hwagener.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Harald Wagener Content-Disposition: attachment; filename="hwagener.vcf" begin:vcard n:Wagener;Harald x-mozilla-html:FALSE org:FCB;EDV adr:;;;;;; version:2.1 email;internet:hwagener@hamburg.fcb.com title:Systemadministrator x-mozilla-cpt:;-17568 fn:Harald Wagener end:vcard --------------A82CB27F46E45C82CC7CBCDE-- From owner-linux-xfs@oss.sgi.com Wed Jul 10 04:11:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ABBXRw021741 for ; Wed, 10 Jul 2002 04:11:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ABBXaS021740 for linux-xfs-outgoing; Wed, 10 Jul 2002 04:11:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ABBMRw021709 for ; Wed, 10 Jul 2002 04:11:23 -0700 Received: from erbenson.alaska.net (18-pm33.nwc.alaska.net [209.112.159.18]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g6ABFon26348 for ; Wed, 10 Jul 2002 03:15:50 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 8EF6B3977 for ; Wed, 10 Jul 2002 03:15:49 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 393C410293; Wed, 10 Jul 2002 03:15:49 -0800 (AKDT) Date: Wed, 10 Jul 2002 03:15:49 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: plans for new release,update redate 2.4.18-5 Message-ID: <20020710031549.C32081@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3D2BFC15.574702F8@online.no> <3D2C1289.96B90856@hamburg.fcb.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LwW0XdcUbUexiWVK" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D2C1289.96B90856@hamburg.fcb.com>; from hwagener@hamburg.fcb.com on Wed, Jul 10, 2002 at 12:55:05PM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --LwW0XdcUbUexiWVK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2002 at 12:55:05PM +0200, Harald Wagener wrote: > Knut J Bjuland wrote: > >=20 > > What are there plans for a new XFS release,=20 >=20 > Releases are made as an add on iso image whith which You can install RedH= at on no they are not. the releases have nothing to do with redhat. releases are in the form of a diff patch against the kernel, not some redhat iso. > Definitely there is a 2.4.18 version in cvs. I don't know if it's relativ= e to > 2.4.18-5, which seems to be a redhat kernel. At this time, RedHat folks w= ould > be the ones to be asked for xfs inclusion (by You, that is).... not anymore, cvs is at 2.4.19-rc1 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --LwW0XdcUbUexiWVK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0sF2UACgkQJKx7GixEevxwmQCghX7P6q+LGTk+DNyPW1bvvAbv wSsAn3kH52fRg2yLW952rjYrFxPf/aHn =SZ/O -----END PGP SIGNATURE----- --LwW0XdcUbUexiWVK-- From owner-linux-xfs@oss.sgi.com Wed Jul 10 04:33:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ABXKRw028488 for ; Wed, 10 Jul 2002 04:33:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ABXKY5028487 for linux-xfs-outgoing; Wed, 10 Jul 2002 04:33:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ABX9Rw028456 for ; Wed, 10 Jul 2002 04:33:09 -0700 Received: from hamburg.fcb.com ([170.200.66.61]) by hammail1.truenorth.com (Netscape Messaging Server 4.15 hammail1 May 24 2002 10:21:14) with ESMTP id GZ16YD00.KJ9; Wed, 10 Jul 2002 13:37:25 +0200 Message-ID: <3D2C1C7C.AE277DD4@hamburg.fcb.com> Date: Wed, 10 Jul 2002 13:37:32 +0200 From: Harald Wagener Organization: FCB Wilkens X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: plans for new release,update redate 2.4.18-5 References: <3D2BFC15.574702F8@online.no> <3D2C1289.96B90856@hamburg.fcb.com> <20020710031549.C32081@plato.local.lan> Content-Type: multipart/mixed; boundary="------------0A2B197667BEC9B4BE8DE33B" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------0A2B197667BEC9B4BE8DE33B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ethan Benson wrote: > > On Wed, Jul 10, 2002 at 12:55:05PM +0200, Harald Wagener wrote: > > Knut J Bjuland wrote: > > > > > > What are there plans for a new XFS release, > > > > Releases are made as an add on iso image whith which You can install RedHat on > > no they are not. the releases have nothing to do with redhat. > releases are in the form of a diff patch against the kernel, not some > redhat iso. Ethan, of course You are right. But I was under the impression the OP wanted to know about an easily installed version. So I answered his question under that light, although my answer is wrong in a strict sense. But we had XFS 1.0, 1.0.1, and 1.1 as releases in the way I described it, no? > > Definitely there is a 2.4.18 version in cvs. I don't know if it's relative to > > 2.4.18-5, which seems to be a redhat kernel. At this time, RedHat folks would > > be the ones to be asked for xfs inclusion (by You, that is).... > > not anymore, cvs is at 2.4.19-rc1 But I thought the point of cvs would be that You can go back to another point in development history? So, a 2.4.18 version is Out There (rather, in there)... Regards, Harald -- Harald Wagener*An der Alster 42*20099 Hamburg*http://www.fcb-wilkens.com --------------0A2B197667BEC9B4BE8DE33B Content-Type: text/x-vcard; charset=us-ascii; name="hwagener.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Harald Wagener Content-Disposition: attachment; filename="hwagener.vcf" begin:vcard n:Wagener;Harald x-mozilla-html:FALSE org:FCB;EDV adr:;;;;;; version:2.1 email;internet:hwagener@hamburg.fcb.com title:Systemadministrator x-mozilla-cpt:;-17568 fn:Harald Wagener end:vcard --------------0A2B197667BEC9B4BE8DE33B-- From owner-linux-xfs@oss.sgi.com Wed Jul 10 04:56:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ABuCRw028847 for ; Wed, 10 Jul 2002 04:56:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ABuCA8028846 for linux-xfs-outgoing; Wed, 10 Jul 2002 04:56:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ns.caxopen.de (IDENT:root@caxopen-gw.caxopen.com [194.55.1.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ABu4Rw028812 for ; Wed, 10 Jul 2002 04:56:05 -0700 Received: from caxopen.de (rE+h36Z23d3BeU1DzHYpc8OSziawsfsH@minos.intern.net [192.168.1.28]) by ns.caxopen.de (8.8.7/8.8.7) with ESMTP id OAA07040 for ; Wed, 10 Jul 2002 14:02:21 +0200 Message-ID: <3D2C21DF.9080702@caxopen.de> Date: Wed, 10 Jul 2002 14:00:31 +0200 From: Andreas Korn Reply-To: korn@caxopen.de Organization: CAxOPEN GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: WARNIG: NFS3-server broken in RH-7.3 XFS Installer Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I had a newly install box with RH-7.3 and the XFS installer disk running as nfs-server (NFS3). The kernel was the precompiled kernel from the installer (2.4.18-4SGI_XFS_1.1). The disks had xfs filesystem. The nfs server would occasionally hang for some time (several minutes) and sometimes recover. During this time the kupdated process used all available CPU time and the nfsd processes had been put to sleep (or maybe deadlocked). Everything else was ok. After this I ran bonnie on some NFS mounts and I would hang shortly after all buffers on the server were used up. bonnie exited with an I/O error. The server showed the same behavior but never recovered. I had hangs with lokally mounted nfs, too. After switching to kernel 2.4.19-rc1 with the appropriate xfs-patch all was well again. On another box with plain 2.4.18 + xfs-1.1 the problem also didn't occur. Only with the kernel from the installer. This is only intended as a warning for all who may want to use similar setup. Andreas -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger! From owner-linux-xfs@oss.sgi.com Wed Jul 10 05:42:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ACgqRw029651 for ; Wed, 10 Jul 2002 05:42:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ACgqTL029650 for linux-xfs-outgoing; Wed, 10 Jul 2002 05:42:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ACghRw029611 for ; Wed, 10 Jul 2002 05:42:43 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id 90D29C23C; Wed, 10 Jul 2002 14:47:06 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA11052; Wed, 10 Jul 2002 14: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 BCB5557306; Wed, 10 Jul 2002 14:46:47 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 2E13125835; Wed, 10 Jul 2002 14:46:47 +0200 (CEST) Message-ID: <3D2C2CB7.521173BF@ch.sauter-bc.com> Date: Wed, 10 Jul 2002 14:46:47 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: korn@caxopen.de Cc: linux-xfs Subject: Re: WARNIG: NFS3-server broken in RH-7.3 XFS Installer References: <3D2C21DF.9080702@caxopen.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andreas Korn schrieb: > > I had a newly install box with RH-7.3 and the XFS installer disk running > as nfs-server (NFS3). The kernel was the precompiled kernel from the > installer (2.4.18-4SGI_XFS_1.1). The disks had xfs filesystem. The nfs > server would occasionally hang for some time (several minutes) and > sometimes recover. During this time the kupdated process used all > available CPU time and the nfsd processes had been put to sleep (or > maybe deadlocked). Everything else was ok. After this I ran bonnie on > some NFS mounts and I would hang shortly after all buffers on the server > were used up. bonnie exited with an I/O error. The server showed the > same behavior but never recovered. I had hangs with lokally mounted > nfs, too. > After switching to kernel 2.4.19-rc1 with the appropriate xfs-patch all > was well again. On another box with plain 2.4.18 + xfs-1.1 the problem > also didn't occur. Only with the kernel from the installer. > There is a new RedHat kernel in the errata with NFS fixes, maybe this one would run okay. Unfortunately AFAIK nobody has XFS enabled it yet. http://rhn.redhat.com/errata/RHBA-2002-110.html Simon > This is only intended as a warning for all who may want to use similar > setup. > > Andreas > > -- > Do not meddle in the affairs of wizards, > for they are subtle and quick to anger! From owner-linux-xfs@oss.sgi.com Wed Jul 10 06:09:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AD9YRw030227 for ; Wed, 10 Jul 2002 06:09:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AD9YBK030226 for linux-xfs-outgoing; Wed, 10 Jul 2002 06:09:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AD9PRw030198 for ; Wed, 10 Jul 2002 06:09:26 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA48543; Wed, 10 Jul 2002 08:13:49 -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 IAA29168; Wed, 10 Jul 2002 08:13:48 -0500 (CDT) Date: Wed, 10 Jul 2002 08:13:41 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Knut J Bjuland cc: linux-xfs@oss.sgi.com Subject: Re: plans for new release,update redate 2.4.18-5 In-Reply-To: <3D2BFC15.574702F8@online.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 10 Jul 2002, Knut J Bjuland wrote: > What are there plans for a new XFS release, There will be a new release. :) We talked about this yesterday; there are so many new features & fixes in CVS vs. the last relese, it's probably time for a new one. We'd like to wait until 2.4.19 is out. > and are there any plans for > an update (Red Hat) Linux 2.4.18-5 with xfs patch in? I have not done it yet; it's probably a fairly trivial task (given that the XFS patch for RH's 2.4.18-4 is out there) and I would gladly take a contributed update. I have less time these days to play catch-up with Red Hat. > Is SGI lobbying Redhat to > include XFS in its next release as option like JFS? It would be better if users asked them to include it. At this point it seems that they have no intention of including XFS. Every other major distro has already done so, though, so if you need XFS in your distribution, you have several very good options. > Have you started to > feed linux with xfs patch in small bits? Steve is in good contact with the kernel folks; in some sense this has already started (witness the EA/ACL code). The bulk of XFS is not available in "little bits" though, and will just have to go in in a chunk. -Eric From owner-linux-xfs@oss.sgi.com Wed Jul 10 06:18:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ADIvRw030606 for ; Wed, 10 Jul 2002 06:18:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ADIv61030605 for linux-xfs-outgoing; Wed, 10 Jul 2002 06:18:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ADIqRw030576 for ; Wed, 10 Jul 2002 06:18:53 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA31723; Wed, 10 Jul 2002 08:23:17 -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 IAA28548; Wed, 10 Jul 2002 08:23:16 -0500 (CDT) Date: Wed, 10 Jul 2002 08:23:08 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Knut J Bjuland cc: linux-xfs@oss.sgi.com Subject: Re: plans for new release,update redate 2.4.18-5 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 10 Jul 2002, Eric Sandeen wrote: > Steve is in good contact with the kernel folks; in some sense this has > already started (witness the EA code). The bulk of XFS is not available > in "little bits" though, and will just have to go in in a chunk. Oh, I should have been more clear that it was Nathan who was the SGI driving force behind the EA code push... -Eric From owner-linux-xfs@oss.sgi.com Wed Jul 10 07:20:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AEKQRw031786 for ; Wed, 10 Jul 2002 07:20:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AEKQqv031785 for linux-xfs-outgoing; Wed, 10 Jul 2002 07:20:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AEKKRw031757 for ; Wed, 10 Jul 2002 07:20:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA45469 for ; Wed, 10 Jul 2002 09:24:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA97387 for ; Wed, 10 Jul 2002 09:24:44 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6AEJmL04307; Wed, 10 Jul 2002 09:19:48 -0500 Message-Id: <200207101419.g6AEJmL04307@jen.americas.sgi.com> Date: Wed, 10 Jul 2002 09:19:48 -0500 Subject: TAKE - only include iobuf.h where needed To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Maybe we need to find a way to make these messages come from Christoph. Date: Wed Jul 10 07:23:21 PDT 2002 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:122766a linux/fs/xfs/linux/xfs_iops.c - 1.159 linux/fs/xfs/linux/xfs_ioctl.c - 1.66 linux/fs/xfs/pagebuf/page_buf.h - 1.24 From owner-linux-xfs@oss.sgi.com Wed Jul 10 07:41:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AEfLRw032158 for ; Wed, 10 Jul 2002 07:41:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AEfLje032157 for linux-xfs-outgoing; Wed, 10 Jul 2002 07:41:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AEfCRw032127 for ; Wed, 10 Jul 2002 07:41:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA40996 for ; Wed, 10 Jul 2002 09:45:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA07483 for ; Wed, 10 Jul 2002 09:45:36 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6AEeef04544; Wed, 10 Jul 2002 09:40:40 -0500 Message-Id: <200207101440.g6AEeef04544@jen.americas.sgi.com> Date: Wed, 10 Jul 2002 09:40:40 -0500 Subject: TAKE - more cleanups To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More cleanups from Christoph use unlock_page instead of UnlockPage Date: Wed Jul 10 07:25:35 PDT 2002 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:122767a linux/fs/xfs/linux/xfs_lrw.c - 1.154 linux/fs/xfs/linux/xfs_iops.c - 1.160 linux/fs/xfs/pagebuf/page_buf_io.c - 1.49 linux/fs/xfs/pagebuf/page_buf.c - 1.36 Subject: TAKE - do not pass file->f_flags into check frozen Date: Wed Jul 10 07:26:57 PDT 2002 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:122768a linux/fs/xfs/linux/xfs_lrw.c - 1.155 Subject: TAKE - do not pass cwd into rmdir Date: Wed Jul 10 07:44:55 PDT 2002 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:122770a linux/fs/xfs/xfs_vnodeops.c - 1.535 linux/fs/xfs/linux/xfs_iops.c - 1.161 linux/fs/xfs/linux/xfs_vnode.h - 1.44 From owner-linux-xfs@oss.sgi.com Wed Jul 10 08:00:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AF0bRw032512 for ; Wed, 10 Jul 2002 08:00:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AF0bTW032510 for linux-xfs-outgoing; Wed, 10 Jul 2002 08:00:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AF0TRw032480 for ; Wed, 10 Jul 2002 08:00:30 -0700 Received: from arcus.vexcel.com (arcus.vexcel.com [192.92.90.44]) by biobio.vexcel.com (8.12.1/8.12.1) with ESMTP id g6AF4r74003091 for ; Wed, 10 Jul 2002 09:04:53 -0600 (MDT) Received: from vexcel.com (localhost.localdomain [127.0.0.1]) by arcus.vexcel.com (8.11.6/8.11.6) with ESMTP id g6AF4mx01170 for ; Wed, 10 Jul 2002 09:04:52 -0600 Message-ID: <3D2C4D10.C9F37CE9@vexcel.com> Date: Wed, 10 Jul 2002 09:04:48 -0600 From: Vincent Cassi X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: memory leak when write in a file (with O_DIRECT flag). Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have a small program that take a buffer and copy it in a file. If (and only if) the flag O_DIRECT is given to the open command, a memory leak appeares. The /proc/meminfo file, show the free memory going down each time that the program is running. The average of the memory leak is 160 kBytes with a buffer of 80 Meg Bytes. The buffer is alligned and mlocked before the write. The system used: Mandrake: 8.2 XFS: 2.0.0-1 mdk linux: 2.4.18 What I'm doing wrong ??? Thanks for any help. Vincent From owner-linux-xfs@oss.sgi.com Wed Jul 10 08:12:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AFCpRw000366 for ; Wed, 10 Jul 2002 08:12:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AFCpVH000365 for linux-xfs-outgoing; Wed, 10 Jul 2002 08:12:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from elpems01.customercenter.net (elpems01.customercenter.net [208.235.248.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AFChRw000329 for ; Wed, 10 Jul 2002 08:12:43 -0700 Received: from espems04.nc.customercenter.net by elpems01.customercenter.net (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6AFH7h24963 for ; Wed, 10 Jul 2002 11:17:07 -0400 Received: from atlrelay.nc.checkfree.com (atlrelay.nc.checkfree.com [10.132.1.73]) by espems04.nc.customercenter.net (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6AFH7R16065 for ; Wed, 10 Jul 2002 11:17:07 -0400 (EDT) To: linux-xfs@oss.sgi.com Subject: Enterprise kernel 7.2 redhat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: CRivera@checkfree.com Date: Wed, 10 Jul 2002 11:16:56 -0400 X-MIMETrack: Serialize by Router on ATLRELAY/CheckFree(Release 5.0.10 |March 22, 2002) at 07/10/2002 11:17:00 AM, Serialize complete at 07/10/2002 11:17:00 AM X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 X-Spam-Level: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We just recently received some Dell PowerEdge 6650's and loaded them with your 2.4.9-31 XFS 1.0.2 enterprise kernel (from your 7.2 loader). After finishing the installation when we checked the amount of CPU's it showed up as 1, when in fact this server had two (two 1.5 ghz Xeon MP processors), this in turn should show up as 4 processors because of the hyper-threading. We then installed Red Hat 7.3 with the 2.4.18 kernel and also Red Hat 7.2 with the 2.4.7-10 kernel and they both worked fine and showed 4 processors. Can you give me some clue as to why this happens on your 2.4.9-31 kernel? We really take advantage of your XFS file system but this has forced us to start using ReiserFs which is now natively supported in the kernel. Thanks, Carlos Carlos Rivera Sr. Systems Engineer - DSE crivera@checkfree.com Phone: 678-375-3407 Cell: 404-409-5359 Pager: 877-383-4489 Fax: 678-375-3436 The #1 Way to Pay Online http://www.checkfree.com/paybillsonline [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Jul 10 08:12:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AFCfRw000332 for ; Wed, 10 Jul 2002 08:12:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AFCfXL000331 for linux-xfs-outgoing; Wed, 10 Jul 2002 08:12:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AFCXRw032766 for ; Wed, 10 Jul 2002 08:12:33 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA45125 for ; Wed, 10 Jul 2002 10:16:57 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA43954 for ; Wed, 10 Jul 2002 10:16:57 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA28030 for linux-xfs@oss.sgi.com; Wed, 10 Jul 2002 10:16:57 -0500 (CDT) Date: Wed, 10 Jul 2002 10:16:57 -0500 (CDT) From: Dean Roehrich Message-Id: <200207101516.KAA28030@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - rearrange dmapi mmap event trigger X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jul 10 08:16:19 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122771a linux/mm/mprotect.c - 1.21 - Remove call to f_op->dmapi_map_event(). Add call to f_op->mprotect(). linux/include/linux/fs.h - 1.153 - Remove dmapi_map_event from file_operations. Add mprotect to file_operations. linux/fs/xfs/xfs_dmapi.h - 1.26 - xfs_dmapi_mmap_event() prototype linux/fs/xfs/xfs_dmapi.c - 1.65 - Add xfs_dmapi_mmap_event(). This is the reincarnation of linvfs_dmapi_map_event(). linux/fs/xfs/linux/xfs_dmistubs.c - 1.17 - xfs_dmapi_mmap_event() stub linux/fs/xfs/linux/xfs_file.c - 1.70 - Remove linvfs_dmapi_map_event(). Add linvfs_mprotect(). Change linvfs_generic_file_mmap() to check for dmapi permission _before_ doing the generic_file_mmap()...not much point in doing it after. From owner-linux-xfs@oss.sgi.com Wed Jul 10 08:23:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AFNBRw000708 for ; Wed, 10 Jul 2002 08:23:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AFNBbw000707 for linux-xfs-outgoing; Wed, 10 Jul 2002 08:23:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AFN2Rw000676 for ; Wed, 10 Jul 2002 08:23:03 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA48486; Wed, 10 Jul 2002 10:27:25 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA28492; Wed, 10 Jul 2002 10:27:24 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6AFMS205495; Wed, 10 Jul 2002 10:22:28 -0500 Subject: Re: memory leak when write in a file (with O_DIRECT flag). From: Steve Lord To: Vincent Cassi Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D2C4D10.C9F37CE9@vexcel.com> References: <3D2C4D10.C9F37CE9@vexcel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Jul 2002 10:22:28 -0500 Message-Id: <1026314548.2644.14.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-10 at 10:04, Vincent Cassi wrote: > Hi, > > I have a small program that take a buffer and copy it in a file. > If (and only if) the flag O_DIRECT is given to the open command, a > memory leak appeares. > The /proc/meminfo file, show the free memory going down each time that > the program is running. > > The average of the memory leak is 160 kBytes with a buffer of 80 Meg > Bytes. > The buffer is alligned and mlocked before the write. > The system used: Mandrake: 8.2 > XFS: 2.0.0-1 mdk > linux: 2.4.18 > > What I'm doing wrong ??? > Thanks for any help. > > Vincent Is there any chance you can try a cvs kernel, there have been major changes in this area since 2.4.18. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jul 10 08:51:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AFpvRw004886 for ; Wed, 10 Jul 2002 08:51:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AFpvjI004885 for linux-xfs-outgoing; Wed, 10 Jul 2002 08:51:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AFpoRw004857 for ; Wed, 10 Jul 2002 08:51:51 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA53438; Wed, 10 Jul 2002 10:56:14 -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 KAA97182; Wed, 10 Jul 2002 10:56:14 -0500 (CDT) Subject: Re: Enterprise kernel 7.2 redhat From: Eric Sandeen To: CRivera@checkfree.com Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 10 Jul 2002 10:56:05 -0500 Message-Id: <1026316566.27313.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Carlos - The 1.0.2 release (and RH 7.2 installer) has 2.4.9-13, not 2.4.9-31, so I'm not sure which one you are actually looking at? the 2.4.9-31 kernels do have CONFIG_SMP enabled, as do the 2.4.9-13 kernels. If you're using XFS 1.0.2/2.4.9-13, I'd suggest upgrading to the XFS 1.1/2.4.9-31 kernel anyway, and see how that goes. -Eric On Wed, 2002-07-10 at 10:16, CRivera@checkfree.com wrote: > We just recently received some Dell PowerEdge 6650's and loaded them with > your 2.4.9-31 XFS 1.0.2 enterprise kernel (from your 7.2 loader). After > finishing the installation when we checked the amount of CPU's it showed > up as 1, when in fact this server had two (two 1.5 ghz Xeon MP > processors), this in turn should show up as 4 processors because of the > hyper-threading. > > We then installed Red Hat 7.3 with the 2.4.18 kernel and also Red Hat 7.2 > with the 2.4.7-10 kernel and they both worked fine and showed 4 > processors. Can you give me some clue as to why this happens on your > 2.4.9-31 kernel? We really take advantage of your XFS file system but > this has forced us to start using ReiserFs which is now natively supported > in the kernel. From owner-linux-xfs@oss.sgi.com Wed Jul 10 10:15:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AHFvRw005891 for ; Wed, 10 Jul 2002 10:15:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AHFvIN005890 for linux-xfs-outgoing; Wed, 10 Jul 2002 10:15:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AHFqRw005861 for ; Wed, 10 Jul 2002 10:15:52 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA59456 for ; Wed, 10 Jul 2002 12:20:17 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA75919 for ; Wed, 10 Jul 2002 12:20:16 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id MAA37442 for linux-xfs@oss.sgi.com; Wed, 10 Jul 2002 12:20:16 -0500 (CDT) Date: Wed, 10 Jul 2002 12:20:16 -0500 (CDT) From: Dean Roehrich Message-Id: <200207101720.MAA37442@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - add iobuf.h to xfs_dmapi.c X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jul 10 10:20:04 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122778a linux/fs/xfs/xfs_dmapi.c - 1.66 - add iobuf.h From owner-linux-xfs@oss.sgi.com Wed Jul 10 10:16:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AHGvRw005930 for ; Wed, 10 Jul 2002 10:16:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AHGvmC005929 for linux-xfs-outgoing; Wed, 10 Jul 2002 10:16:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AHGqRw005896 for ; Wed, 10 Jul 2002 10:16:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA63929 for ; Wed, 10 Jul 2002 12:21:17 -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 MAA27033 for ; Wed, 10 Jul 2002 12:21:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6AHL8015677; Wed, 10 Jul 2002 12:21:08 -0500 Message-Id: <200207101721.g6AHL8015677@stout.americas.sgi.com> Date: Wed, 10 Jul 2002 12:21:08 -0500 Subject: TAKE - userspace sync-up X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk userspace sync-up Date: Wed Jul 10 10:20:55 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-preempt The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122779a cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.13 cmd/xfsprogs/include/xfs_bmap.h - 1.6 cmd/xfsprogs/libxfs/xfs.h - 1.21 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.14 cmd/xfsprogs/include/xfs_cap.h - 1.3 From owner-linux-xfs@oss.sgi.com Wed Jul 10 10:42:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AHgWRw006446 for ; Wed, 10 Jul 2002 10:42:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AHgWZu006445 for linux-xfs-outgoing; Wed, 10 Jul 2002 10:42:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AHgQRw006417 for ; Wed, 10 Jul 2002 10:42:26 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6AHkoog014274; Wed, 10 Jul 2002 19:46:50 +0200 (CEST) Message-Id: <4.3.2.7.2.20020710193825.032fc008@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Jul 2002 19:42:51 +0200 To: CRivera@checkfree.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Enterprise kernel 7.2 redhat In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:16 10-7-2002 -0400, CRivera@checkfree.com wrote: >We then installed Red Hat 7.3 with the 2.4.18 kernel and also Red Hat 7.2 >with the 2.4.7-10 kernel and they both worked fine and showed 4 >processors. Can you give me some clue as to why this happens on your >2.4.9-31 kernel? We really take advantage of your XFS file system but >this has forced us to start using ReiserFs which is now natively supported >in the kernel. These kernels need a nudge in the right direction. Give the acpismp=force boot option. This is discussed on the linux-poweredge mailing list before. I also believe it is listed on the http://domsch.com/linux/ page. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 10 12:03:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AJ31Rw007865 for ; Wed, 10 Jul 2002 12:03:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AJ31TG007864 for linux-xfs-outgoing; Wed, 10 Jul 2002 12:03:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AJ2PRw007834 for ; Wed, 10 Jul 2002 12:02:26 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA66680 for ; Wed, 10 Jul 2002 14:06:50 -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 OAA42593 for ; Wed, 10 Jul 2002 14:06:50 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6AJ6eq17553; Wed, 10 Jul 2002 14:06:40 -0500 Message-Id: <200207101906.g6AJ6eq17553@stout.americas.sgi.com> Date: Wed, 10 Jul 2002 14:06:40 -0500 Subject: TAKE - whitespace cleanup X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another in in my series of technically challenging mods, this one comes hot on the heels of the ever-popular "Copyright Update" changes! This gets us a little closer to following Greg K-H's kernel style suggestions; next up - 386 #ifdefs. ;-) All this one does is strip trailing whitespace, and convert spaces to tabs where it can. >From now on, watch those terminal cut-n-pastes! (To those dialup CVS users who have to pull all these down, sorry! Steve made me do it!) Date: Wed Jul 10 12:00:42 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122792a linux/fs/xfs/xfs_trans_space.h - 1.10 linux/fs/xfs/xfs_trans_dquot.c - 1.37 linux/fs/xfs/xfsidbg.c - 1.188 linux/fs/xfs/xfs_log.h - 1.62 linux/fs/xfs/xfs_log.c - 1.250 linux/fs/xfs/xfs_quota_priv.h - 1.22 linux/fs/xfs/xfs_inum.h - 1.19 linux/fs/xfs/xfs_ialloc.h - 1.40 linux/fs/xfs/xfs_ialloc.c - 1.158 linux/fs/xfs/xfs_macros.c - 1.43 linux/fs/xfs/xfs_macros.h - 1.18 linux/fs/xfs/xfs_ag.h - 1.45 linux/fs/xfs/xfs_rw.h - 1.66 linux/fs/xfs/xfs_rw.c - 1.359 linux/fs/xfs/xfs_extfree_item.h - 1.14 linux/fs/xfs/xfs_extfree_item.c - 1.48 linux/fs/xfs/xfs_buf.h - 1.90 linux/fs/xfs/xfs_buf_item.h - 1.35 linux/fs/xfs/xfs_buf_item.c - 1.123 linux/fs/xfs/xfs_trans_inode.c - 1.38 linux/fs/xfs/xfs_trans_priv.h - 1.23 linux/fs/xfs/xfs_attr_sf.h - 1.16 linux/fs/xfs/xfs_log_priv.h - 1.84 linux/fs/xfs/xfs_da_btree.c - 1.129 linux/fs/xfs/xfs_da_btree.h - 1.44 linux/fs/xfs/xfs_bit.h - 1.14 linux/fs/xfs/xfs_bit.c - 1.18 linux/fs/xfs/xfs_sb.h - 1.53 linux/fs/xfs/xfs_trans_ail.c - 1.64 linux/fs/xfs/xfs_vnodeops.c - 1.536 linux/fs/xfs/xfs_dir2_block.c - 1.25 linux/fs/xfs/xfs_dir2_block.h - 1.9 linux/fs/xfs/xfs_attr_fetch.c - 1.11 linux/fs/xfs/xfs_dir.h - 1.38 linux/fs/xfs/xfs_dir.c - 1.137 linux/fs/xfs/xfs_dqblk.h - 1.8 linux/fs/xfs/xfs_rtalloc.h - 1.22 linux/fs/xfs/xfs_rtalloc.c - 1.74 linux/fs/xfs/xfs_itable.c - 1.107 linux/fs/xfs/xfs_itable.h - 1.37 linux/fs/xfs/xfs_ialloc_btree.h - 1.21 linux/fs/xfs/xfs_ialloc_btree.c - 1.67 linux/fs/xfs/xfs_dmapi.h - 1.27 linux/fs/xfs/xfs_dmapi.c - 1.67 linux/fs/xfs/xfs_inode_item.c - 1.100 linux/fs/xfs/xfs_inode_item.h - 1.39 linux/fs/xfs/Makefile - 1.147 linux/fs/xfs/xfs_iocore.c - 1.31 linux/fs/xfs/xfs_qm_syscalls.c - 1.64 linux/fs/xfs/xfs_log_recover.h - 1.16 linux/fs/xfs/xfs_log_recover.c - 1.237 linux/fs/xfs/xfs_trans_item.c - 1.32 linux/fs/xfs/xfs_dquot_item.h - 1.8 linux/fs/xfs/xfs_dquot_item.c - 1.28 linux/fs/xfs/xfs_vfsops.c - 1.357 linux/fs/xfs/xfs_dfrag.c - 1.32 linux/fs/xfs/xfs_dfrag.h - 1.6 linux/fs/xfs/xfs_iget.c - 1.163 linux/fs/xfs/xfs_clnt.h - 1.31 linux/fs/xfs/xfs_bmap_btree.h - 1.51 linux/fs/xfs/xfs_bmap_btree.c - 1.123 linux/fs/xfs/xfs_dir2_sf.h - 1.13 linux/fs/xfs/xfs_dir2_sf.c - 1.28 linux/fs/xfs/xfs_dquot.h - 1.22 linux/fs/xfs/xfs_dquot.c - 1.66 linux/fs/xfs/xfs_dir_leaf.c - 1.103 linux/fs/xfs/xfs_dir_leaf.h - 1.35 linux/fs/xfs/xfs_mount.h - 1.147 linux/fs/xfs/xfs_mount.c - 1.288 linux/fs/xfs/xfs_btree.c - 1.98 linux/fs/xfs/xfs_btree.h - 1.53 linux/fs/xfs/xfs_qm.h - 1.24 linux/fs/xfs/xfs_qm.c - 1.78 linux/fs/xfs/xfs_dir2_data.c - 1.18 linux/fs/xfs/xfs_dir2_data.h - 1.7 linux/fs/xfs/xfs_trans_extfree.c - 1.20 linux/fs/xfs/xfs_inode.c - 1.343 linux/fs/xfs/xfs_inode.h - 1.162 linux/fs/xfs/xfs_dir2_trace.c - 1.12 linux/fs/xfs/xfs_dir2_trace.h - 1.6 linux/fs/xfs/xfs_dir2_leaf.c - 1.27 linux/fs/xfs/xfs_dir2_leaf.h - 1.10 linux/fs/xfs/xfs_attr_leaf.h - 1.29 linux/fs/xfs/xfs_attr_leaf.c - 1.63 linux/fs/xfs/xfs_types.h - 1.57 linux/fs/xfs/xfs_trans.c - 1.132 linux/fs/xfs/xfs_trans.h - 1.112 linux/fs/xfs/xfs_error.c - 1.33 linux/fs/xfs/xfs_error.h - 1.26 linux/fs/xfs/xfs_utils.c - 1.48 linux/fs/xfs/xfs_utils.h - 1.21 linux/fs/xfs/xfs_dir_sf.h - 1.20 linux/fs/xfs/xfs_alloc.c - 1.153 linux/fs/xfs/xfs_alloc.h - 1.52 linux/fs/xfs/xfs_fsops.h - 1.22 linux/fs/xfs/xfs_fsops.c - 1.80 linux/fs/xfs/xfs_imap.h - 1.8 linux/fs/xfs/xfs_bmap.h - 1.78 linux/fs/xfs/xfs_bmap.c - 1.286 linux/fs/xfs/xfsdmapistubs.c - 1.12 linux/fs/xfs/xfs_alloc_btree.h - 1.21 linux/fs/xfs/xfs_alloc_btree.c - 1.70 linux/fs/xfs/xfs_quota.h - 1.28 linux/fs/xfs/xfs_trans_buf.c - 1.101 linux/fs/xfs/xfs_cxfs.h - 1.11 linux/fs/xfs/xfs_dir2_node.c - 1.24 linux/fs/xfs/xfs_dir2_node.h - 1.6 linux/fs/xfs/xfs_rename.c - 1.37 linux/fs/xfs/xfs_attr.c - 1.92 linux/fs/xfs/xfs_attr.h - 1.22 linux/fs/xfs/xfs_dir2.h - 1.11 linux/fs/xfs/xfs_dir2.c - 1.34 linux/fs/xfs/xfs_dinode.h - 1.61 linux/fs/xfs/linux/xfs_lrw.h - 1.25 linux/fs/xfs/linux/xfs_lrw.c - 1.156 linux/fs/xfs/linux/xfs_vfs.c - 1.36 linux/fs/xfs/linux/xfs_dmistubs.c - 1.18 linux/fs/xfs/linux/xfs_globals.c - 1.30 linux/fs/xfs/linux/xfs_linux.h - 1.77 linux/fs/xfs/linux/Makefile - 1.54 linux/fs/xfs/linux/xfs_file.c - 1.71 linux/fs/xfs/linux/xfs_vnode.c - 1.87 linux/fs/xfs/linux/xfs_fs_subr.c - 1.32 linux/fs/xfs/linux/xfs_super.h - 1.23 linux/fs/xfs/linux/xfs_super.c - 1.188 linux/fs/xfs/linux/xfs_behavior.c - 1.13 linux/fs/xfs/linux/xfs_iops.c - 1.162 linux/fs/xfs/linux/xfs_iops.h - 1.14 linux/include/linux/xfs_fs_i.h - 1.10 linux/include/linux/xfs_fs.h - 1.35 linux/fs/xfs/linux/xfs_cred.h - 1.19 linux/fs/xfs/linux/xfs_cred.c - 1.11 linux/fs/xfs/xfs_arch.h - 1.34 linux/fs/xfs/linux/xfs_ioctl.c - 1.67 linux/include/linux/behavior.h - 1.4 linux/include/linux/vnode.h - 1.7 linux/include/linux/dmapi.h - 1.11 linux/include/linux/dmapi_kern.h - 1.13 linux/fs/xfs/linux/xfs_globals.h - 1.11 linux/fs/xfs/xfs.h - 1.25 linux/fs/xfs/linux/xfs_vnode.h - 1.45 linux/fs/xfs/linux/xfs_vfs.h - 1.20 linux/fs/xfs/linux/xfs_fs_subr.h - 1.7 linux/fs/xfs/linux/xfs_behavior.h - 1.6 linux/fs/xfs/support/uuid.h - 1.5 linux/fs/xfs/support/atomic.h - 1.6 linux/fs/xfs/support/debug.c - 1.7 linux/fs/xfs/support/uuid.c - 1.5 linux/fs/xfs/support/types.h - 1.7 linux/fs/xfs/support/time.h - 1.5 linux/fs/xfs/support/sv.h - 1.9 linux/fs/xfs/support/spin.h - 1.8 linux/fs/xfs/support/sema.h - 1.7 linux/fs/xfs/support/qsort.h - 1.5 linux/fs/xfs/support/qsort.c - 1.5 linux/fs/xfs/support/mutex.h - 1.9 linux/fs/xfs/support/mrlock.h - 1.7 linux/fs/xfs/support/mrlock.c - 1.9 linux/fs/xfs/support/ktrace.h - 1.6 linux/fs/xfs/support/move.h - 1.8 linux/fs/xfs/linux/xfs_stats.c - 1.6 linux/fs/xfs/linux/xfs_stats.h - 1.2 linux/fs/xfs/support/Makefile - 1.11 linux/fs/xfs/support/arch.h - 1.6 linux/fs/xfs/support/move.c - 1.6 linux/fs/xfs/support/kmem.h - 1.8 linux/fs/xfs/support/debug.h - 1.5 linux/fs/xfs/support/kmem.c - 1.12 linux/fs/xfs/support/ktrace.c - 1.8 linux/fs/xfs/xfs_acl.h - 1.18 linux/fs/xfs/xfs_acl.c - 1.31 linux/fs/xfs/Makefile.in - 1.20 linux/fs/xfs/linux/Makefile.in - 1.9 linux/fs/xfs/linux/xfs_sysctl.h - 1.4 linux/fs/xfs/linux/xfs_sysctl.c - 1.5 linux/fs/xfs_dmapi/xfsjunk.c - 1.11 linux/fs/xfs_dmapi/Makefile.in - 1.7 linux/fs/xfs_dmapi/dmapi_session.c - 1.10 linux/fs/xfs_dmapi/dmapi_right.c - 1.6 linux/fs/xfs_dmapi/dmapi_register.c - 1.15 linux/fs/xfs_dmapi/dmapi_region.c - 1.2 linux/fs/xfs_dmapi/dmapi_private.h - 1.12 linux/fs/xfs_dmapi/dmapi_mountinfo.c - 1.6 linux/fs/xfs_dmapi/dmapi_io.c - 1.2 linux/fs/xfs_dmapi/dmapi_hole.c - 1.2 linux/fs/xfs_dmapi/dmapi_handle.c - 1.2 linux/fs/xfs_dmapi/dmapi_event.c - 1.5 linux/fs/xfs_dmapi/dmapi_dmattr.c - 1.2 linux/fs/xfs_dmapi/dmapi_config.c - 1.3 linux/fs/xfs_dmapi/dmapi_bulkattr.c - 1.2 linux/fs/xfs_dmapi/dmapi_attr.c - 1.2 linux/fs/xfs_dmapi/Makefile - 1.6 linux/fs/xfs_dmapi/dmapi_sysent.c - 1.8 linux/fs/xfs/pagebuf/Makefile.in - 1.8 linux/fs/xfs/pagebuf/page_buf_io.c - 1.50 linux/fs/xfs/pagebuf/Makefile - 1.11 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.17 linux/fs/xfs/pagebuf/page_buf.c - 1.37 linux/fs/xfs/pagebuf/page_buf_trace.h - 1.4 linux/fs/xfs/pagebuf/page_buf.h - 1.25 linux/fs/xfs/xfs_mac.h - 1.5 linux/fs/xfs/xfs_mac.c - 1.4 linux/fs/xfs/linux/xfs_xattr.c - 1.17 linux/fs/xfs/linux/xfs_xattr.h - 1.6 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.11 linux/fs/xfs/support/Makefile.in - 1.4 linux/fs/xfs/xfs_cap.h - 1.5 linux/fs/xfs/xfs_cap.c - 1.4 From owner-linux-xfs@oss.sgi.com Wed Jul 10 12:28:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AJSCRw008545 for ; Wed, 10 Jul 2002 12:28:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AJSCG8008544 for linux-xfs-outgoing; Wed, 10 Jul 2002 12:28:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AJRvRw008513 for ; Wed, 10 Jul 2002 12:27:58 -0700 Received: from erbenson.alaska.net (156-pm11.nwc.alaska.net [209.112.140.156]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g6AJWQn68404 for ; Wed, 10 Jul 2002 11:32:26 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 5A9F93939 for ; Wed, 10 Jul 2002 11:32:25 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 1D72D10293; Wed, 10 Jul 2002 11:32:25 -0800 (AKDT) Date: Wed, 10 Jul 2002 11:32:25 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: plans for new release,update redate 2.4.18-5 Message-ID: <20020710113225.D32081@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3D2BFC15.574702F8@online.no> <3D2C1289.96B90856@hamburg.fcb.com> <20020710031549.C32081@plato.local.lan> <3D2C1C7C.AE277DD4@hamburg.fcb.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rz+pwK2yUstbofK6" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D2C1C7C.AE277DD4@hamburg.fcb.com>; from hwagener@hamburg.fcb.com on Wed, Jul 10, 2002 at 01:37:32PM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --rz+pwK2yUstbofK6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2002 at 01:37:32PM +0200, Harald Wagener wrote: > Ethan Benson wrote: > >=20 > > On Wed, Jul 10, 2002 at 12:55:05PM +0200, Harald Wagener wrote: > > > Knut J Bjuland wrote: > > > > > > > > What are there plans for a new XFS release, > > > > > > Releases are made as an add on iso image whith which You can install = RedHat on > >=20 > > no they are not. the releases have nothing to do with redhat. > > releases are in the form of a diff patch against the kernel, not some > > redhat iso. >=20 > Ethan, of course You are right. But I was under the impression the OP wan= ted > to know about an easily installed version. So I answered his question und= er > that light, although my answer is wrong in a strict sense.=20 > But we had XFS 1.0, 1.0.1, and 1.1 as releases in the way I described it,= no? 1.1 didn't get an installer for quite a while after its release, and i think others had to contribute it this time. > > > Definitely there is a 2.4.18 version in cvs. I don't know if it's rel= ative to > > > 2.4.18-5, which seems to be a redhat kernel. At this time, RedHat fol= ks would > > > be the ones to be asked for xfs inclusion (by You, that is).... > >=20 > > not anymore, cvs is at 2.4.19-rc1 >=20 > But I thought the point of cvs would be that You can go back to another p= oint > in development history? So, a 2.4.18 version is Out There (rather, in > there)... that would be difficult since SGI does not actually use CVS, they use a very interesting, but unspecific version control system that exports to CVS, this means that there are no tags to efficiently let you checkout an older version of the entire tree, you can inspect the history of all the files whcih haven't been renamed/removed and see every past revision but there is no way AFAIK to checkout a 2.4.18 version from CVS. (you can still get the patches from oss.sgi.com but thats it). also afaict the way the SGI version control system exports to CVS is to just deletes files which are moved/renamed or deleted, rather then moving them to a cvs attic, i may be wrong on this, it just appears so since whenever they remove/move/rename a file cvs just reports that `it no longer exists in the repository' instead of `is no longer pertenant' --=20 Ethan Benson http://www.alaska.net/~erbenson/ --rz+pwK2yUstbofK6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0si8gACgkQJKx7GixEevxeqACeNfuWZ3R0X297WZLvDgTeeK3E k3kAmwU+uPf0SbfeasnwXtrOJzEnt2Rx =ttBL -----END PGP SIGNATURE----- --rz+pwK2yUstbofK6-- From owner-linux-xfs@oss.sgi.com Wed Jul 10 12:36:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AJadRw008743 for ; Wed, 10 Jul 2002 12:36:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AJad7v008742 for linux-xfs-outgoing; Wed, 10 Jul 2002 12:36:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AJaWRw008714 for ; Wed, 10 Jul 2002 12:36:33 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA63611; Wed, 10 Jul 2002 14:40:58 -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 OAA73728; Wed, 10 Jul 2002 14:40:57 -0500 (CDT) Subject: Re: plans for new release,update redate 2.4.18-5 From: Eric Sandeen To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020710113225.D32081@plato.local.lan> References: <3D2BFC15.574702F8@online.no> <3D2C1289.96B90856@hamburg.fcb.com> <20020710031549.C32081@plato.local.lan> <3D2C1C7C.AE277DD4@hamburg.fcb.com> <20020710113225.D32081@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 10 Jul 2002 14:40:47 -0500 Message-Id: <1026330047.27313.36.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-10 at 14:32, Ethan Benson wrote: > that would be difficult since SGI does not actually use CVS, they use > a very interesting, but unspecific version control system that exports > to CVS, this means that there are no tags to efficiently let you > checkout an older version of the entire tree, you can inspect the > history of all the files whcih haven't been renamed/removed and see > every past revision but there is no way AFAIK to checkout a 2.4.18 > version from CVS. (you can still get the patches from oss.sgi.com but > thats it). Well, you can look at the timestamps on the Makefile, to see when it bumped from 2.4.17 to 2.4.18, and then do a cvs checkout by date... > also afaict the way the SGI version control system exports to CVS is > to just deletes files which are moved/renamed or deleted, rather then > moving them to a cvs attic, i may be wrong on this, it just appears so > since whenever they remove/move/rename a file cvs just reports that > `it no longer exists in the repository' instead of `is no longer > pertenant' That's true; there is no such thing as an attic in our CVS repository. :( I agree that it's a pain. -Eric From owner-linux-xfs@oss.sgi.com Wed Jul 10 12:47:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AJlvRw009550 for ; Wed, 10 Jul 2002 12:47:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AJlvPf009541 for linux-xfs-outgoing; Wed, 10 Jul 2002 12:47:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AJljRw007392 for ; Wed, 10 Jul 2002 12:47:45 -0700 Received: from erbenson.alaska.net (156-pm11.nwc.alaska.net [209.112.140.156]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g6AJqEn83683 for ; Wed, 10 Jul 2002 11:52:14 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id CA64C3939 for ; Wed, 10 Jul 2002 11:52:12 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id D895C10293; Wed, 10 Jul 2002 11:52:12 -0800 (AKDT) Date: Wed, 10 Jul 2002 11:52:12 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: plans for new release,update redate 2.4.18-5 Message-ID: <20020710115212.F32081@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3D2BFC15.574702F8@online.no> <3D2C1289.96B90856@hamburg.fcb.com> <20020710031549.C32081@plato.local.lan> <3D2C1C7C.AE277DD4@hamburg.fcb.com> <20020710113225.D32081@plato.local.lan> <1026330047.27313.36.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dWYAkE0V1FpFQHQ3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1026330047.27313.36.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, Jul 10, 2002 at 02:40:47PM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --dWYAkE0V1FpFQHQ3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2002 at 02:40:47PM -0500, Eric Sandeen wrote: > On Wed, 2002-07-10 at 14:32, Ethan Benson wrote: >=20 > > that would be difficult since SGI does not actually use CVS, they use > > a very interesting, but unspecific version control system that exports > > to CVS, this means that there are no tags to efficiently let you > > checkout an older version of the entire tree, you can inspect the > > history of all the files whcih haven't been renamed/removed and see > > every past revision but there is no way AFAIK to checkout a 2.4.18 > > version from CVS. (you can still get the patches from oss.sgi.com but > > thats it). >=20 > Well, you can look at the timestamps on the Makefile, to see when it > bumped from 2.4.17 to 2.4.18, and then do a cvs checkout by date...=20 doesn't really let you checkout the last 2.4.18 before it turned 2.4.19 where many many changes occured in between.. though its likly even if you were using cvs that this would not have been tagged anyway. > That's true; there is no such thing as an attic in our CVS repository.=20 > :( I agree that it's a pain. given how crippled and broken cvs is im amazed that your exporter does as well as it does. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --dWYAkE0V1FpFQHQ3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0skGwACgkQJKx7GixEevylcQCeKvXC+T4At6ScgF8i0k7Am69y Xx4An06syeDLVLHhA7MLMCOvhA1BafzH =9VUi -----END PGP SIGNATURE----- --dWYAkE0V1FpFQHQ3-- From owner-linux-xfs@oss.sgi.com Wed Jul 10 12:48:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AJmwRw017163 for ; Wed, 10 Jul 2002 12:48:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AJmwfD017162 for linux-xfs-outgoing; Wed, 10 Jul 2002 12:48:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AJmmRw017129 for ; Wed, 10 Jul 2002 12:48:48 -0700 Received: from erbenson.alaska.net (156-pm11.nwc.alaska.net [209.112.140.156]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g6AJrGn84407 for ; Wed, 10 Jul 2002 11:53:16 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 3D3593939 for ; Wed, 10 Jul 2002 11:53:15 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 738C410293; Wed, 10 Jul 2002 11:53:15 -0800 (AKDT) Received: from erbenson.alaska.net (venabili.local.lan [192.168.0.10]) by plato.local.lan (Postfix) with ESMTP id 921EC10291 for ; Wed, 10 Jul 2002 04:53:22 -0800 (AKDT) Received: from localhost (localhost [127.0.0.1]) by erbenson.alaska.net (Postfix) with ESMTP id D71B53977 for ; Wed, 10 Jul 2002 04:53:21 -0800 (AKDT) Received: from localhost by localhost with POP3 (fetchmail-5.3.3) for eb@plato.local.lan (single-drop); Wed, 10 Jul 2002 04:53:21 -0800 (AKDT) Received: from malik.slb.nwc.acsalaska.net (malik.prv.nwc.acsalaska.net [10.0.0.41]) by ims01.prv.nwc.acsalaska.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GZ10031LADTEU@ims01.prv.nwc.acsalaska.net> for erbenson%alaska.net@ims-ms-daemon (ORCPT erbenson@alaska.net); Wed, 10 Jul 2002 04:51:29 -0800 (AKDT) Received: from konza.flinthills.com (konza.flinthills.com [64.39.200.1]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g6ACpSO95964 for ; Wed, 10 Jul 2002 04:51:29 -0800 (AKDT envelope-from djw@flinthills.com) Received: from saiya-jin.flinthills.com (fh-dialup-201167.flinthills.com [64.39.201.167]) by konza.flinthills.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6ACpQ8u003744 for ; Wed, 10 Jul 2002 07:51:27 -0500 (CDT) Date: Wed, 10 Jul 2002 07:51:23 -0500 From: Derek J Witt Subject: Re: XFS and grub-0.92 In-reply-to: <20020709231817.B32081@plato.local.lan> X-Sender: djw@pop.flinthills.com To: Ethan Benson Message-id: <5.1.1.6.0.20020710074313.00a97180@pop.flinthills.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <20020710061931.GA18472@ids.org.au> <200207100551.g6A5pX5G003057@Traveller.attbi.com> <20020710061931.GA18472@ids.org.au> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Good morning, everyone. A few months back I wrote a patch that will check the partition type of one's root partition (according to the command line or lilo.conf). It checks the first 4 bytes of the partition. If 'XFSB' is found, lilo will then abort with an error. I also created another parameter for those wanting to 'force' lilo to install. In that case, LILO will then display a message that the user must be prepared to run xfs_repair from a boot disc. I also submitted that patch to LILO's maintainer. He said he will include this in his next release of LILO. Back then, LILO was at 22.1 (afaik). It may be included in one form or another in the beta version. But the bottom line here, if it's an XFS partition, do not install a boot loader on that partition's sector 0. This is in the FAQ ;-) I've done that same mistake until it kicked in (took me three tries). -- Derek Witt, djw@flinthills.com At 02:18 10-07-02, you wrote: >On Wed, Jul 10, 2002 at 04:19:31PM +1000, Ian Cumming wrote: > > Hi Kelledin, > > > > I've found this problem too. I tried to install grub onto the root > > partition of a drive, and was not able to boot (with the same error). > >thats because you just scribbled the XFS superblock. > > > It appears that you cannot install grub onto the root partition without > > corrupting the XFS fs. However, I can install grub into the MBR of the > > drive, and successfully boot from the root partition in this manner. > >that is correct. XFS puts its superblock right at block zero of the >partition instead of block 2 like ext2 (which leaves 1024 bytes of >unused space at the start of the partition for things like >bootloaders). > > > My knowledge of this problem is very limited, because I could not afford > > to break my system again by investigating it! With this in mind, I can > > only offer an anecdotal intepretation of the problem, howerver I am sure > > that others in this list can offer a far better explanation. > >you must install the first stage bootloader in the MBR, you must not >install it on the partition if that partition is XFS, you WILL destroy >the XFS superblock. > >this is the same `bug' people kept reporting in lilo until someone >finally patched it (im not sure that patch ever made it upstream) to >check for XFS and refuse to proceed if its detected. > >-- >Ethan Benson >http://www.alaska.net/~erbenson/ From owner-linux-xfs@oss.sgi.com Wed Jul 10 14:20:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ALKSRw020682 for ; Wed, 10 Jul 2002 14:20:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ALKSWY020681 for linux-xfs-outgoing; Wed, 10 Jul 2002 14:20:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ALKMRw020648 for ; Wed, 10 Jul 2002 14:20:22 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA64402 for ; Wed, 10 Jul 2002 16:24:47 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA25702 for ; Wed, 10 Jul 2002 16:24:47 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA72806 for linux-xfs@oss.sgi.com; Wed, 10 Jul 2002 16:24:47 -0500 (CDT) Date: Wed, 10 Jul 2002 16:24:47 -0500 (CDT) From: Dean Roehrich Message-Id: <200207102124.QAA72806@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi: introduce vnode ptr into dm_tokdata_t X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is the first of a series of patches to get the dmapi core to use bhv's and bhv locks correctly. These patches are being carried over from work currently going on for Irix, in PV 860655. Date: Wed Jul 10 14:24:33 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122813a linux/fs/xfs_dmapi/dmapi_right.c - 1.7 linux/fs/xfs_dmapi/dmapi_private.h - 1.13 linux/fs/xfs_dmapi/dmapi_event.c - 1.6 - No Message Supplied From owner-linux-xfs@oss.sgi.com Wed Jul 10 14:41:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ALfsRw021035 for ; Wed, 10 Jul 2002 14:41:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ALfsFN021034 for linux-xfs-outgoing; Wed, 10 Jul 2002 14:41:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ALfoRw021004 for ; Wed, 10 Jul 2002 14:41:50 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA63507 for ; Wed, 10 Jul 2002 16:46:15 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA11322 for ; Wed, 10 Jul 2002 16:46:15 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA97697 for linux-xfs@oss.sgi.com; Wed, 10 Jul 2002 16:46:15 -0500 (CDT) Date: Wed, 10 Jul 2002 16:46:15 -0500 (CDT) From: Dean Roehrich Message-Id: <200207102146.QAA97697@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi: Change VN_HOLD/VN_RELE/iput to use the new vnode pointer X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jul 10 14:46:05 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122818a linux/fs/xfs_dmapi/dmapi_right.c - 1.8 - Change VN_HOLD/VN_RELE to use the new vnode pointer. From owner-linux-xfs@oss.sgi.com Wed Jul 10 15:01:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AM18Rw021617 for ; Wed, 10 Jul 2002 15:01:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AM185i021616 for linux-xfs-outgoing; Wed, 10 Jul 2002 15:01:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AM12Rw021584 for ; Wed, 10 Jul 2002 15:01:02 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA66520 for ; Wed, 10 Jul 2002 17:05:27 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA91326 for ; Wed, 10 Jul 2002 17:05:27 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id RAA00191 for linux-xfs@oss.sgi.com; Wed, 10 Jul 2002 17:05:27 -0500 (CDT) Date: Wed, 10 Jul 2002 17:05:27 -0500 (CDT) From: Dean Roehrich Message-Id: <200207102205.RAA00191@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi: change dm_fsys_vector to use new vnode pointer X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jul 10 15:05:13 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122821a linux/fs/xfs_dmapi/dmapi_right.c - 1.9 linux/fs/xfs_dmapi/dmapi_register.c - 1.16 linux/fs/xfs_dmapi/dmapi_region.c - 1.3 linux/fs/xfs_dmapi/dmapi_private.h - 1.14 linux/fs/xfs_dmapi/dmapi_mountinfo.c - 1.7 linux/fs/xfs_dmapi/dmapi_io.c - 1.3 linux/fs/xfs_dmapi/dmapi_hole.c - 1.3 linux/fs/xfs_dmapi/dmapi_handle.c - 1.3 linux/fs/xfs_dmapi/dmapi_event.c - 1.7 linux/fs/xfs_dmapi/dmapi_dmattr.c - 1.3 linux/fs/xfs_dmapi/dmapi_config.c - 1.4 linux/fs/xfs_dmapi/dmapi_bulkattr.c - 1.3 linux/fs/xfs_dmapi/dmapi_attr.c - 1.3 - No Message Supplied From owner-linux-xfs@oss.sgi.com Wed Jul 10 17:09:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B090Rw025198 for ; Wed, 10 Jul 2002 17:09:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B0909B025197 for linux-xfs-outgoing; Wed, 10 Jul 2002 17:09:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B08lRw025167 for ; Wed, 10 Jul 2002 17:08:48 -0700 Received: (qmail 23679 invoked by uid 500); 11 Jul 2002 00:13:02 -0000 Subject: Re: Enterprise kernel 7.2 redhat From: Austin Gonyou To: CRivera@checkfree.com Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-84rsKhYPTaCDOrZFmMAm" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 10 Jul 2002 19:13:02 -0500 Message-Id: <1026346382.22703.49.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-84rsKhYPTaCDOrZFmMAm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable My affinity..for this..as I'm doing a VLDB with 6650s and RH 7.2 sgi-xfs 1.0.2 is to use a new kernel from the -aa tree. the 2.4.9 doesn't have the latest VM stuff and such..the -aa tree works very well in this regard. I can lend any help if necessary. I've got a 4P box..1.6Ghz 1MBL3 and I saw 4 on boot. To get P4 support though..you'll need to get a new kernel, or just recompile. The -AA tree is supersweet. On Wed, 2002-07-10 at 10:16, CRivera@checkfree.com wrote: > We just recently received some Dell PowerEdge 6650's and loaded them > with=20 > your 2.4.9-31 XFS 1.0.2 enterprise kernel (from your 7.2 loader).=20 > After=20 > finishing the installation when we checked the amount of CPU's it > showed=20 > up as 1, when in fact this server had two (two 1.5 ghz Xeon MP=20 > processors), this in turn should show up as 4 processors because of > the=20 > hyper-threading.=20 >=20 > We then installed Red Hat 7.3 with the 2.4.18 kernel and also Red Hat > 7.2=20 > with the 2.4.7-10 kernel and they both worked fine and showed 4=20 > processors. Can you give me some clue as to why this happens on your=20 > 2.4.9-31 kernel? We really take advantage of your XFS file system but > this has forced us to start using ReiserFs which is now natively > supported=20 > in the kernel. >=20 > Thanks, >=20 > Carlos >=20 >=20 > Carlos Rivera > Sr. Systems Engineer - DSE > crivera@checkfree.com > Phone: 678-375-3407 > Cell: 404-409-5359 > Pager: 877-383-4489 > Fax: 678-375-3436 >=20 > The #1 Way to Pay Online > http://www.checkfree.com/paybillsonline >=20 >=20 > [[HTML alternate version deleted]] --=20 Austin Gonyou Coremetrics, Inc. --=-84rsKhYPTaCDOrZFmMAm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9LM2O94g6ZVmFMoIRAmCcAKCFI1+g/lJtwG8cIHq9v2CtSK7azwCeOLPN uXxFdJ9DOg7WGVlE8hqbLtk= =pYqK -----END PGP SIGNATURE----- --=-84rsKhYPTaCDOrZFmMAm-- From owner-linux-xfs@oss.sgi.com Wed Jul 10 20:25:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B3PXRw002887 for ; Wed, 10 Jul 2002 20:25:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B3PXh2002886 for linux-xfs-outgoing; Wed, 10 Jul 2002 20:25:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B3P5Rw002855 for ; Wed, 10 Jul 2002 20:25:05 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 UAA06534 for ; Wed, 10 Jul 2002 20:29:35 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA29324; Thu, 11 Jul 2002 13:28:04 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) with ESMTP id g6B3QmEH001281; Thu, 11 Jul 2002 13:26:48 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) id g6B3Qj6g001279; Thu, 11 Jul 2002 13:26:45 +1000 Date: Thu, 11 Jul 2002 13:26:45 +1000 From: Nathan Scott To: Knut J Bjuland , Andreas Gruenbacher , Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: plans for new release,update redate 2.4.18-5 Message-ID: <20020711032645.GD455@frodo> References: <3D2BFC15.574702F8@online.no> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-8.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi, On Wed, Jul 10, 2002 at 08:13:41AM -0500, Eric Sandeen wrote: > On Wed, 10 Jul 2002, Knut J Bjuland wrote: > > ... > > Have you started to > > feed linux with xfs patch in small bits? > > Steve is in good contact with the kernel folks; in some sense this has > already started (witness the EA/ACL code). The bulk of XFS is not available > in "little bits" though, and will just have to go in in a chunk. Just to clarify - there is no ACL code in the kernel yet. So far we have EA VFS and system call changes in and also some quota changes. ACL support shouldn't be too hard to get, I think; Andreas and I just need to iterate a few more times on exactly what it is we should send. The attached patch is my current "small is beautiful" version of VFS POSIX ACL support and is everything we need from an XFS point of view, but is not quite what Andreas wants, IIRC. I'm a bit sidetracked on capabilities code to follow up on this right now though. cheers. -- Nathan --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="posix_acl.patch2.5" diff -Naur 2.5.24-pristine/fs/Config.help 2.5.24-posix_acl/fs/Config.help --- 2.5.24-pristine/fs/Config.help Thu May 30 09:18:38 2002 +++ 2.5.24-posix_acl/fs/Config.help Wed Jun 26 13:28:28 2002 @@ -1,3 +1,13 @@ +POSIX Access Control Lists +CONFIG_FS_POSIX_ACL + POSIX Access Control Lists (ACLs) support permissions for users and + groups beyond the owner/group/world scheme. + + To learn more about Access Control Lists, visit the POSIX ACLs for + Linux website . If you wish to use ACLs + you will also need the getfacl(1) and setfacl(1) utilities, along + with some additional patches from the website. If unsure, say N. + CONFIG_QUOTA If you say Y here, you will be able to set per user limits for disk usage (also called disk quotas). Currently, it works for the diff -Naur 2.5.24-pristine/fs/Config.in 2.5.24-posix_acl/fs/Config.in --- 2.5.24-pristine/fs/Config.in Fri Jun 21 10:00:47 2002 +++ 2.5.24-posix_acl/fs/Config.in Wed Jun 26 13:22:58 2002 @@ -4,6 +4,8 @@ mainmenu_option next_comment comment 'File systems' +bool 'POSIX Access Control Lists' CONFIG_FS_POSIX_ACL + bool 'Quota support' CONFIG_QUOTA dep_tristate ' Old quota format support' CONFIG_QFMT_V1 $CONFIG_QUOTA dep_tristate ' VFS v0 quota format support' CONFIG_QFMT_V2 $CONFIG_QUOTA diff -Naur 2.5.24-pristine/fs/namei.c 2.5.24-posix_acl/fs/namei.c --- 2.5.24-pristine/fs/namei.c Wed Jun 19 13:55:28 2002 +++ 2.5.24-posix_acl/fs/namei.c Wed Jun 26 13:22:58 2002 @@ -1251,6 +1251,8 @@ /* Negative dentry, just create the file */ if (!dentry->d_inode) { + if (!IS_POSIXACL(dir->d_inode)) + mode &= ~current->fs->umask; error = vfs_create(dir->d_inode, dentry, mode & ~current->fs->umask); up(&dir->d_inode->i_sem); @@ -1405,7 +1407,8 @@ dentry = lookup_create(&nd, 0); error = PTR_ERR(dentry); - mode &= ~current->fs->umask; + if (!IS_POSIXACL(nd.dentry->d_inode)) + mode &= ~current->fs->umask; if (!IS_ERR(dentry)) { switch (mode & S_IFMT) { case 0: case S_IFREG: @@ -1465,8 +1468,9 @@ dentry = lookup_create(&nd, 1); error = PTR_ERR(dentry); if (!IS_ERR(dentry)) { - error = vfs_mkdir(nd.dentry->d_inode, dentry, - mode & ~current->fs->umask); + if (!IS_POSIXACL(nd.dentry->d_inode)) + mode &= ~current->fs->umask; + error = vfs_mkdir(nd.dentry->d_inode, dentry, mode); dput(dentry); } up(&nd.dentry->d_inode->i_sem); diff -Naur 2.5.24-pristine/include/linux/fs.h 2.5.24-posix_acl/include/linux/fs.h --- 2.5.24-pristine/include/linux/fs.h Wed Jun 19 13:55:31 2002 +++ 2.5.24-posix_acl/include/linux/fs.h Wed Jun 26 13:24:21 2002 @@ -134,6 +134,7 @@ #define S_DEAD 32 /* removed, but still open directory */ #define S_NOQUOTA 64 /* Inode is not counted to quota */ #define S_DIRSYNC 128 /* Directory modifications are synchronous */ +#define S_POSIXACL 256 /* Defer application of the umask */ /* * Note that nosuid etc flags are inode-specific: setting some file-system @@ -165,6 +166,7 @@ #define IS_NODIRATIME(inode) __IS_FLG(inode, MS_NODIRATIME) #define IS_DEADDIR(inode) ((inode)->i_flags & S_DEAD) +#define IS_POSIXACL(inode) ((inode)->i_flags & S_POSIXACL) /* the read-only stuff doesn't really belong here, but any other place is probably as bad and I don't want to create yet another include file. */ diff -Naur 2.5.24-pristine/include/linux/posix_acl_xattr.h 2.5.24-posix_acl/include/linux/posix_acl_xattr.h --- 2.5.24-pristine/include/linux/posix_acl_xattr.h Thu Jan 1 10:00:00 1970 +++ 2.5.24-posix_acl/include/linux/posix_acl_xattr.h Wed Jun 26 13:22:58 2002 @@ -0,0 +1,67 @@ +/* + File: linux/posix_acl_xattr.h + + Extended attribute system call representation of Access Control Lists. + + Copyright (C) 2000 by Andreas Gruenbacher + */ +#ifndef _POSIX_ACL_XATTR_H +#define _POSIX_ACL_XATTR_H + + +/* Extended attribute names */ +#define POSIX_ACL_XATTR_ACCESS "system.posix_acl_access" +#define POSIX_ACL_XATTR_DEFAULT "system.posix_acl_default" + +/* Supported ACL a_version fields */ +#define POSIX_ACL_XATTR_VERSION 0x0002 + + +/* An undefined entry e_id value */ +#define ACL_UNDEFINED_ID (-1) + +/* ACL entry e_tag field values */ +#define ACL_USER_OBJ (0x01) +#define ACL_USER (0x02) +#define ACL_GROUP_OBJ (0x04) +#define ACL_GROUP (0x08) +#define ACL_MASK (0x10) +#define ACL_OTHER (0x20) + +/* ACL entry e_perm bitfield values */ +#define ACL_READ (0x04) +#define ACL_WRITE (0x02) +#define ACL_EXECUTE (0x01) + + +typedef struct { + __u16 e_tag; + __u16 e_perm; + __u32 e_id; +} posix_acl_xattr_entry; + +typedef struct { + __u32 a_version; + posix_acl_xattr_entry a_entries[0]; +} posix_acl_xattr_header; + + +static inline size_t +posix_acl_xattr_size(int count) +{ + return (sizeof(posix_acl_xattr_header) + + (count * sizeof(posix_acl_xattr_entry))); +} + +static inline int +posix_acl_xattr_count(size_t size) +{ + if (size < sizeof(posix_acl_xattr_header)) + return -1; + size -= sizeof(posix_acl_xattr_header); + if (size % sizeof(posix_acl_xattr_entry)) + return -1; + return size / sizeof(posix_acl_xattr_entry); +} + +#endif /* _POSIX_ACL_XATTR_H */ --K8nIJk4ghYZn606h-- From owner-linux-xfs@oss.sgi.com Thu Jul 11 02:36:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B9aTRw022862 for ; Thu, 11 Jul 2002 02:36:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B9aS0T022861 for linux-xfs-outgoing; Thu, 11 Jul 2002 02:36:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hotmail.com (oe62.law10.hotmail.com [64.4.14.197]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B9aORw022831 for ; Thu, 11 Jul 2002 02:36:24 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jul 2002 02:40:52 -0700 X-Originating-IP: [217.59.125.133] From: "Malcolm Reid" To: "Linux-XFS mailing list" Subject: DMAPI and CVS Date: Thu, 11 Jul 2002 11:45:18 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: X-OriginalArrivalTime: 11 Jul 2002 09:40:52.0751 (UTC) FILETIME=[0C2681F0:01C228BF] X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have been unable to build the CVS kernel with DMAPI support - using menuconfig, I can only select DMAPI as module, however it is saved as yes. With xconfig I can only click on yes, even though module is an option. No matter what I do , DMAPI does not work. What am I doing wrong? Thanks [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jul 11 02:54:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B9sTRw023279 for ; Thu, 11 Jul 2002 02:54:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B9sTE7023278 for linux-xfs-outgoing; Thu, 11 Jul 2002 02:54:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B9sNRw023250 for ; Thu, 11 Jul 2002 02:54:23 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id LAA09213 for ; Thu, 11 Jul 2002 11:58:55 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17Sait-0001Wk-00 for ; Thu, 11 Jul 2002 11:58:55 +0200 Date: Thu, 11 Jul 2002 11:58:55 +0200 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: running really short an DMA buffers Message-ID: <20020711115855.G4854@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 Lines: 19 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm running Dual PIII 450MHz with 512MB Ram as an nfs server. System is Debian Woody. Kernel is cvs, checked out on June, 14th. The machine ooopsd two weeks ago, but I wasn't able to reproduce with kbd, because another guy rebooted it. I only saw a huge amount of "Warning - running *really* short on DMA buffers" kernel-messages. Now these messages come again. Anything to be concerned of? Some Details: two filesystems on top of lvm 1.0.3 (each 200GB) are exported via NFS. The filesystems are mounted with "logbufs=8". Is this value too high with "only" 512MB of RAM? thanks in advance Christian From owner-linux-xfs@oss.sgi.com Thu Jul 11 03:25:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BAPeRw023864 for ; Thu, 11 Jul 2002 03:25:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BAPeQo023863 for linux-xfs-outgoing; Thu, 11 Jul 2002 03:25:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BAPTRw023832 for ; Thu, 11 Jul 2002 03:25:30 -0700 Received: from starfleet.thompson.us (slip-32-101-12-128.wi.us.prserv.net[32.101.12.128]) by prserv.net (out2) with ESMTP id <2002071110300120203gcubfe>; Thu, 11 Jul 2002 10:30:01 +0000 Received: from thangorodrim.thompson.us (thangorodrim [192.168.0.5]) by starfleet.thompson.us (8.11.6/8.11.6) with ESMTP id g6B2BPk07082 for ; Wed, 10 Jul 2002 21:11:25 -0500 Received: by thangorodrim.thompson.us (Postfix, from userid 502) id 80321DC128; Wed, 10 Jul 2002 21:10:25 -0500 (CDT) Date: Wed, 10 Jul 2002 21:10:25 -0500 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: Enterprise kernel 7.2 redhat Message-ID: <20020711021025.GB18760@thangorodrim.thompson.us> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: smtp.thompson.us X-System: Dual 450MHz Xeons with 256MB PC100 ECC-SDRAM X-Machine: IBM Intellistation Z Pro 6865-22U X-Operating-System: Red Hat Linux 7.2 with kernel 2.4.18-grsec-1.9.4 Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 26 2002 21:28:16) X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,KNOWN_BAD_DIALUPS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2002 at 11:16:56AM -0400, CRivera@checkfree.com wrote: > We just recently received some Dell PowerEdge 6650's and loaded them with= =20 > your 2.4.9-31 XFS 1.0.2 enterprise kernel (from your 7.2 loader). After= =20 > finishing the installation when we checked the amount of CPU's it showed= =20 > up as 1, when in fact this server had two (two 1.5 ghz Xeon MP=20 > processors), this in turn should show up as 4 processors because of the= =20 > hyper-threading.=20 You will have to install an SMP kernel (i.e. one with the CONFIG_SMP kernel option enabled) in order for more than one CPU to be recognized. While you could install a generic kernel, I would recommend compiling your own kernel, as that allows much more fine-grained control, and a much greater level of optimization. --=20 -- Skylar Thompson (skylar@attglobal.net) --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9LOkRYyzijMrwBxERAkBIAJ9K5exFgKvJBigRyU84WyZUCh8eygCfZMmf BfceY1fHTlfnKjM/V22JqiA= =ewat -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-linux-xfs@oss.sgi.com Thu Jul 11 03:37:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BAbnRw024171 for ; Thu, 11 Jul 2002 03:37:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BAbnnM024170 for linux-xfs-outgoing; Thu, 11 Jul 2002 03:37:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BAbdRw024141 for ; Thu, 11 Jul 2002 03:37:40 -0700 Received: (qmail 17901 invoked by uid 1000); 11 Jul 2002 10:54:19 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Jul 2002 10:54:19 -0000 Date: Thu, 11 Jul 2002 13:54:19 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: md + xfs (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I dont know what to think about a piece of kernels log after one of our machines was rebooted hard (unplugging it I mean). The machine is running 2.4.9-31 SGI_XFS 1.1 , having a RAID 1 md0 with 2 images, and a XFS partition on top of it. I would expect to see a "XFS Starting Recovery" message but as you can see bellow only the raid does some sync , the FS thinks it was a clean boot. Should I worry about possible data coruption ? Thanks md: md0: raid array is not clean -- starting background reconstruction md0: max total readahead window set to 124k md0: 1 data-disks, max readahead per data-disk: 124k raid1: device sdb3 operational as mirror 1 raid1: device sda3 operational as mirror 0 raid1: raid set md0 not clean; reconstructing mirrors raid1: raid set md0 active with 2 out of 2 mirrors md: syncing RAID array md0 md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc. md: using maximum available idle IO bandwith (but not more than 100000 KB/sec) for reconstruction. md: using 124k window, over a total of 16089024 blocks. md: updating md0 RAID superblock on device md: sdb3 [events: 00000018](write) sdb3's sb offset: 16089024 md: sda3 [events: 00000018](write) sda3's sb offset: 16089024 md: ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 32768) ip_tables: (c)2000 Netfilter core team NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 204k freed Adding Swap: 265032k swap-space (priority -1) Adding Swap: 265032k swap-space (priority -2) XFS mounting filesystem md(9,0) md: md0: sync done. ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Thu Jul 11 04:03:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BB3QRw024992 for ; Thu, 11 Jul 2002 04:03:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BB3Qmn024991 for linux-xfs-outgoing; Thu, 11 Jul 2002 04:03:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BB3JRw024962 for ; Thu, 11 Jul 2002 04:03:20 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6BB7puh006025; Thu, 11 Jul 2002 13:07:52 +0200 (CEST) Message-Id: <4.3.2.7.2.20020711130213.032b0780@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Jul 2002 13:06:32 +0200 To: Mihai RUSU , Linux XFS List From: Seth Mos Subject: Re: md + xfs (fwd) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:54 11-7-2002 +0300, Mihai RUSU wrote: >Hi > >I dont know what to think about a piece of kernels log after one of our >machines was rebooted hard (unplugging it I mean). >The machine is running 2.4.9-31 SGI_XFS 1.1 , having a RAID 1 md0 with 2 >images, and a XFS partition on top of it. I would expect to see a "XFS >Starting Recovery" message but as you can see bellow only the raid does >some sync , the FS thinks it was a clean boot. Should I worry about >possible data coruption ? I think that the raid device has a older state in which the filesystem was clean. But this one is rather awkward. I don't think it is normally possible. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jul 11 04:32:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BBWlRw025561 for ; Thu, 11 Jul 2002 04:32:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BBWlfk025560 for linux-xfs-outgoing; Thu, 11 Jul 2002 04:32:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BBWeRw025528 for ; Thu, 11 Jul 2002 04:32:41 -0700 Received: (qmail 18067 invoked by uid 1000); 11 Jul 2002 11:49:20 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Jul 2002 11:49:20 -0000 Date: Thu, 11 Jul 2002 14:49:20 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Seth Mos cc: Linux XFS List Subject: Re: md + xfs (fwd) In-Reply-To: <4.3.2.7.2.20020711130213.032b0780@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Seth Mos wrote: > > I think that the raid device has a older state in which the filesystem was > clean. But this one is rather awkward. I don't think it is normally possible. > That is why I asked here in the first place. I was not sure about how RAID1 on linux works but it seems to me that when a crash occured it choses one of the RAID1 images and rebuilds from that, but I am afraid that maybe in that state only the databytes that tell XFS it is clean, where set right, and other fs structures are corupt. I should xfscheck that partition but I would really prefer to do that when all other fails (beeing a production server). ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Thu Jul 11 05:16:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BCG3Rw026153 for ; Thu, 11 Jul 2002 05:16:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BCG3Le026152 for linux-xfs-outgoing; Thu, 11 Jul 2002 05:16:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BCFtRw026124 for ; Thu, 11 Jul 2002 05:15:56 -0700 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g6BCKNx13456 for linux-xfs@oss.sgi.com.KAV; Thu, 11 Jul 2002 14:20:23 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g6BCKN313449; Thu, 11 Jul 2002 14:20:23 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g6BCLjL11479; Thu, 11 Jul 2002 14:21:45 +0200 Subject: Re: Enterprise kernel 7.2 redhat From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Skylar Thompson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020711021025.GB18760@thangorodrim.thompson.us> References: <20020711021025.GB18760@thangorodrim.thompson.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 11 Jul 2002 14:21:44 +0200 Message-Id: <1026390105.9503.87.camel@venus> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-07-11 at 04:10, Skylar Thompson wrote: > On Wed, Jul 10, 2002 at 11:16:56AM -0400, CRivera@checkfree.com wrote: > > We just recently received some Dell PowerEdge 6650's and loaded them with > > your 2.4.9-31 XFS 1.0.2 enterprise kernel (from your 7.2 loader). After > > finishing the installation when we checked the amount of CPU's it showed > > up as 1, when in fact this server had two (two 1.5 ghz Xeon MP > > processors), this in turn should show up as 4 processors because of the > > hyper-threading. > > You will have to install an SMP kernel (i.e. one with the CONFIG_SMP kernel > option enabled) in order for more than one CPU to be recognized. While you AFAIK RH Enterprise kernels are configured as SMP. Regards, Olaf From owner-linux-xfs@oss.sgi.com Thu Jul 11 06:30:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BDUtRw030541 for ; Thu, 11 Jul 2002 06:30:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BDUtMi030540 for linux-xfs-outgoing; Thu, 11 Jul 2002 06:30:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BDUZRw030512 for ; Thu, 11 Jul 2002 06:30:36 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id AD1F9C23C; Thu, 11 Jul 2002 15:16:25 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id PAA27410; Thu, 11 Jul 2002 15:16:24 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 9047B57306; Thu, 11 Jul 2002 14:02:16 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 9679525835; Thu, 11 Jul 2002 14:02:15 +0200 (CEST) Message-ID: <3D2D73C7.1AC7D9CA@ch.sauter-bc.com> Date: Thu, 11 Jul 2002 14:02:15 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Mihai RUSU Cc: Seth Mos , Linux XFS List Subject: Re: md + xfs (fwd) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mihai RUSU schrieb: > > On Thu, 11 Jul 2002, Seth Mos wrote: > > > > > I think that the raid device has a older state in which the filesystem was > > clean. But this one is rather awkward. I don't think it is normally possible. > > When booting a RedHat system with softraid, the linuxrc script looks something like this: #!/bin/nash echo "Loading raid1 module" insmod /lib/raid1.o mount -t proc /proc /proc echo Mounting /proc filesystem echo Creating root device mkrootdev /dev/root raidautorun /dev/md0 echo 0x0100 > /proc/sys/kernel/real-root-dev umount /proc echo Mounting root filesystem mount --ro -t xfs /dev/root /sysroot pivot_root /sysroot /sysroot/initrd The mount command is a builtin command of /bin/nash, maybe this explains the different behaviour. I hope one of the gurus can explain it to us. Simon > > That is why I asked here in the first place. I was not sure about how > RAID1 on linux works but it seems to me that when a crash occured it > choses one of the RAID1 images and rebuilds from that, but I am afraid > that maybe in that state only the databytes that tell XFS it is clean, > where set right, and other fs structures are corupt. > > I should xfscheck that partition but I would really prefer to do that when > all other fails (beeing a production server). > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Thu Jul 11 07:23:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BENWRw001209 for ; Thu, 11 Jul 2002 07:23:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BENWMT001208 for linux-xfs-outgoing; Thu, 11 Jul 2002 07:23:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf24bis.bellsouth.net (mail024.mail.bellsouth.net [205.152.58.64]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BENNRw001179 for ; Thu, 11 Jul 2002 07:23:25 -0700 Received: from TAZ2 ([66.156.5.159]) by imf24bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020711142751.TPFW1238.imf24bis.bellsouth.net@TAZ2>; Thu, 11 Jul 2002 10:27:51 -0400 Date: Thu, 11 Jul 2002 10:26:54 -0700 From: Greg Freemyer Subject: re[2]: plans for new release,update redate 2.4.18-5 To: Nathan Scott , Knut J Bjuland , Andreas Gruenbacher , Eric Sandeen cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020711142751.TPFW1238.imf24bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6BENPRw001180 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Just to clarify - there is no ACL code in the kernel yet. So far we >> have EA VFS and system call changes in and also some quota changes. >> ACL support shouldn't be too hard to get, I think; Andreas and I just >> need to iterate a few more times on exactly what it is we should send. >> The attached patch is my current "small is beautiful" version of VFS >> POSIX ACL support and is everything we need from an XFS point of view, >> but is not quite what Andreas wants, IIRC. I'm a bit sidetracked on >> capabilities code to follow up on this right now though. I know 2.4.18 has the reserved syscalls. IIRC, true EA/ACL support was hoped to be in 2.4.19. Is this no longer the case? Or was it just EA support that was hoped to go into 2.4.19 Greg Freemyer Internet Engineer Deployment and Integration Specialist HP ASE - Tru64 v4, v5 HP Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Thu Jul 11 07:34:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BEY6Rw004569 for ; Thu, 11 Jul 2002 07:34:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BEY6ON004568 for linux-xfs-outgoing; Thu, 11 Jul 2002 07:34:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BEY1Rw004540 for ; Thu, 11 Jul 2002 07:34:02 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 17Sf5K-000175-00; Thu, 11 Jul 2002 15:38:22 +0100 Date: Thu, 11 Jul 2002 15:38:22 +0100 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Greg Freemyer , Nathan Scott , Knut J Bjuland , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: re[2]: plans for new release,update redate 2.4.18-5 Message-ID: <20020711153822.A4278@infradead.org> References: <20020711142751.TPFW1238.imf24bis.bellsouth.net@TAZ2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ag@bestbits.at on Thu, Jul 11, 2002 at 04:32:31PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jul 11, 2002 at 04:32:31PM +0200, Andreas Gruenbacher wrote: > > Is this no longer the case? Or was it just EA support that was hoped to > > go into 2.4.19 > > 2.4.19 will most likely only have EA support. I doubt that. Marcelo promised to merge EA support for 2.4.20, not 2.4.19. Especially as we are at 2.4.19-rc1 now. From owner-linux-xfs@oss.sgi.com Thu Jul 11 07:28:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BESHRw001286 for ; Thu, 11 Jul 2002 07:28:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BESHQL001285 for linux-xfs-outgoing; Thu, 11 Jul 2002 07:28:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from muriel.parsec.at ([80.120.166.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BESARw001253 for ; Thu, 11 Jul 2002 07:28:10 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g6BEWV509499; Thu, 11 Jul 2002 16:32:31 +0200 Date: Thu, 11 Jul 2002 16:32:31 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Greg Freemyer cc: Nathan Scott , Knut J Bjuland , Eric Sandeen , Subject: re[2]: plans for new release,update redate 2.4.18-5 In-Reply-To: <20020711142751.TPFW1238.imf24bis.bellsouth.net@TAZ2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Greg Freemyer wrote: > >> Just to clarify - there is no ACL code in the kernel yet. So far we > >> have EA VFS and system call changes in and also some quota changes. > > >> ACL support shouldn't be too hard to get, I think; Andreas and I just > >> need to iterate a few more times on exactly what it is we should send. > >> The attached patch is my current "small is beautiful" version of VFS > >> POSIX ACL support and is everything we need from an XFS point of view, > >> but is not quite what Andreas wants, IIRC. I'm a bit sidetracked on > >> capabilities code to follow up on this right now though. > > I know 2.4.18 has the reserved syscalls. > > IIRC, true EA/ACL support was hoped to be in 2.4.19. > > Is this no longer the case? Or was it just EA support that was hoped to > go into 2.4.19 2.4.19 will most likely only have EA support. --Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~ag/ From owner-linux-xfs@oss.sgi.com Thu Jul 11 07:36:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BEaJRw004791 for ; Thu, 11 Jul 2002 07:36:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BEaJkO004790 for linux-xfs-outgoing; Thu, 11 Jul 2002 07:36:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from muriel.parsec.at ([80.120.166.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BEaDRw004724 for ; Thu, 11 Jul 2002 07:36:14 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g6BEeY609572; Thu, 11 Jul 2002 16:40:34 +0200 Date: Thu, 11 Jul 2002 16:40:34 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Christoph Hellwig cc: Greg Freemyer , Nathan Scott , Knut J Bjuland , Eric Sandeen , Subject: Re: re[2]: plans for new release,update redate 2.4.18-5 In-Reply-To: <20020711153822.A4278@infradead.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Christoph Hellwig wrote: > On Thu, Jul 11, 2002 at 04:32:31PM +0200, Andreas Gruenbacher wrote: > > > Is this no longer the case? Or was it just EA support that was hoped to > > > go into 2.4.19 > > > > 2.4.19 will most likely only have EA support. > > I doubt that. Marcelo promised to merge EA support for 2.4.20, not 2.4.19. > Especially as we are at 2.4.19-rc1 now. Corrected. 2.4.20 will most likely only have EA support. 2.4.19 won't have either. --Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~ag/ From owner-linux-xfs@oss.sgi.com Thu Jul 11 07:55:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BEtARw005371 for ; Thu, 11 Jul 2002 07:55:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BEtAtn005370 for linux-xfs-outgoing; Thu, 11 Jul 2002 07:55:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BEt5Rw005342 for ; Thu, 11 Jul 2002 07:55:06 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA72356; Thu, 11 Jul 2002 09:59:34 -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 JAA64864; Thu, 11 Jul 2002 09:59:34 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA39850; Thu, 11 Jul 2002 09:59:33 -0500 (CDT) Message-Id: <200207111459.JAA39850@slobber.americas.sgi.com> To: "Malcolm Reid" cc: "Linux-XFS mailing list" Subject: Re: DMAPI and CVS Date: Thu, 11 Jul 2002 09:59:33 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "Malcolm Reid" >I have been unable to build the CVS kernel with DMAPI support - using menuconf >ig, I can only select DMAPI as module, however it is saved as yes. With xconfi >g I can only click on yes, even though module is an option. No matter what I d >o , DMAPI does not work. What am I doing wrong? Thanks What's in your .config? Grep for _XFS and DMAPI. The fs/Config.in will enforce that dmapi be built the same way xfs is built; i.e., both as modules, or both as built-ins. Dean From owner-linux-xfs@oss.sgi.com Thu Jul 11 08:00:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BF0IRw005604 for ; Thu, 11 Jul 2002 08:00:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BF0I3x005603 for linux-xfs-outgoing; Thu, 11 Jul 2002 08:00:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BF0CRw005570 for ; Thu, 11 Jul 2002 08:00:12 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA71236 for ; Thu, 11 Jul 2002 10:04:41 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA40529 for ; Thu, 11 Jul 2002 10:04:40 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA60298 for linux-xfs@oss.sgi.com; Thu, 11 Jul 2002 10:04:40 -0500 (CDT) Date: Thu, 11 Jul 2002 10:04:40 -0500 (CDT) From: Dean Roehrich Message-Id: <200207111504.KAA60298@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - rework mprotect handling (again) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Patch from Christoph Hellwig. Summary: * ->mprotect is not an operation on the fd but the vma, make it a VM operation instead of file operation * remove file argument from ->mprotect - it's always vma->vm_file * define HAVE_VMOP_MPROTECT and make ->mprotect conditional on it * simplify ->mmap, calling generic_file_mmap is pointless. * rename linvfs_generic_file_mmap to linvfs_file_mmap * add missing externs in xfs_dmapi.h Date: Thu Jul 11 08:04:20 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122842a linux/mm/mprotect.c - 1.22 linux/include/linux/mm.h - 1.84 linux/include/linux/fs.h - 1.154 linux/fs/xfs/xfs_dmapi.h - 1.28 linux/fs/xfs/xfs_dmapi.c - 1.68 linux/fs/xfs/linux/xfs_dmistubs.c - 1.19 linux/fs/xfs/linux/xfs_file.c - 1.72 From owner-linux-xfs@oss.sgi.com Thu Jul 11 08:37:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BFbNRw006457 for ; Thu, 11 Jul 2002 08:37:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BFbNwr006456 for linux-xfs-outgoing; Thu, 11 Jul 2002 08:37:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BFbFRw006428 for ; Thu, 11 Jul 2002 08:37:16 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA77016 for ; Thu, 11 Jul 2002 10:41:44 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA03109 for ; Thu, 11 Jul 2002 10:41:44 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA45513 for linux-xfs@oss.sgi.com; Thu, 11 Jul 2002 10:41:44 -0500 (CDT) Date: Thu, 11 Jul 2002 10:41:44 -0500 (CDT) From: Dean Roehrich Message-Id: <200207111541.KAA45513@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi: add bhv locking at top of fsys_vector calls X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jul 11 08:41:31 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122845a linux/fs/xfs_dmapi/dmapi_right.c - 1.10 linux/fs/xfs_dmapi/dmapi_register.c - 1.17 linux/fs/xfs_dmapi/dmapi_region.c - 1.4 linux/fs/xfs_dmapi/dmapi_io.c - 1.4 linux/fs/xfs_dmapi/dmapi_hole.c - 1.4 linux/fs/xfs_dmapi/dmapi_handle.c - 1.4 linux/fs/xfs_dmapi/dmapi_dmattr.c - 1.4 linux/fs/xfs_dmapi/dmapi_config.c - 1.5 linux/fs/xfs_dmapi/dmapi_bulkattr.c - 1.4 linux/fs/xfs_dmapi/dmapi_attr.c - 1.4 From owner-linux-xfs@oss.sgi.com Thu Jul 11 08:53:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BFriRw006815 for ; Thu, 11 Jul 2002 08:53:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BFribA006814 for linux-xfs-outgoing; Thu, 11 Jul 2002 08:53:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BFrcRw006784 for ; Thu, 11 Jul 2002 08:53:39 -0700 Received: (from lord@localhost) by localhost.localdomain (8.11.6/8.11.6) id g6BFrWA11058 for linux-xfs@oss.sgi.com; Thu, 11 Jul 2002 10:53:32 -0500 Date: Thu, 11 Jul 2002 10:53:32 -0500 From: Stephen Lord Message-Id: <200207111553.g6BFrWA11058@localhost.localdomain> Subject: TAKE - clean up the check frozen interface To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another cleanup from Christoph, and remove the extra write superblock from the unfreeze path. Date: Thu Jul 11 08:51:54 PDT 2002 Workarea: cf-vpn-sw-corp-64-4.corp.sgi.com:/home/lord/src/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:122847a linux/fs/xfs/xfs_mount.h - 1.148 linux/fs/xfs/xfs_mount.c - 1.289 linux/fs/xfs/xfs_trans.c - 1.133 linux/fs/xfs/xfs_fsops.c - 1.81 linux/fs/xfs/linux/xfs_lrw.c - 1.157 From owner-linux-xfs@oss.sgi.com Thu Jul 11 09:17:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BGHxRw007681 for ; Thu, 11 Jul 2002 09:17:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BGHxdx007680 for linux-xfs-outgoing; Thu, 11 Jul 2002 09:17:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BGHrRw007651 for ; Thu, 11 Jul 2002 09:17:54 -0700 Received: (from lord@localhost) by localhost.localdomain (8.11.6/8.11.6) id g6BGHrH12301 for linux-xfs@oss.sgi.com; Thu, 11 Jul 2002 11:17:53 -0500 Date: Thu, 11 Jul 2002 11:17:53 -0500 From: Stephen Lord Message-Id: <200207111617.g6BGHrH12301@localhost.localdomain> Subject: TAKE - remove VOP_CLOSE To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jul 11 09:20:51 PDT 2002 Workarea: cf-vpn-sw-corp-64-4.corp.sgi.com:/home/lord/src/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:122851a linux/fs/xfs/xfs_vnodeops.c - 1.537 linux/fs/xfs/linux/xfs_vnode.h - 1.46 From owner-linux-xfs@oss.sgi.com Thu Jul 11 09:21:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BGLTRw007763 for ; Thu, 11 Jul 2002 09:21:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BGLTrj007762 for linux-xfs-outgoing; Thu, 11 Jul 2002 09:21:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BGLLRw007726 for ; Thu, 11 Jul 2002 09:21:22 -0700 Received: (qmail 20275 invoked by uid 1000); 11 Jul 2002 16:37:59 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Jul 2002 16:37:59 -0000 Date: Thu, 11 Jul 2002 19:37:59 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Simon Matter cc: Seth Mos , Linux XFS List Subject: Re: md + xfs (fwd) In-Reply-To: <3D2D73C7.1AC7D9CA@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Simon Matter wrote: > When booting a RedHat system with softraid, the linuxrc script looks > something like this: > > #!/bin/nash > > echo "Loading raid1 module" > insmod /lib/raid1.o > mount -t proc /proc /proc > echo Mounting /proc filesystem > echo Creating root device > mkrootdev /dev/root > raidautorun /dev/md0 > echo 0x0100 > /proc/sys/kernel/real-root-dev > umount /proc > echo Mounting root filesystem > mount --ro -t xfs /dev/root /sysroot > pivot_root /sysroot /sysroot/initrd > > The mount command is a builtin command of /bin/nash, maybe this explains > the different behaviour. I hope one of the gurus can explain it to us. > > Simon I must add that the system is Slackware 8.0 based. The MD support is compiled in kernel (no modules support). The partitions are of type RAID autodetect so linux can detect them at boot time. Also the / and /home partitions are NOT on the md0 divice. Only /var is. ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Thu Jul 11 09:40:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BGevRw008283 for ; Thu, 11 Jul 2002 09:40:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BGevxh008282 for linux-xfs-outgoing; Thu, 11 Jul 2002 09:40:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BGepRw008254 for ; Thu, 11 Jul 2002 09:40:52 -0700 Received: (from lord@localhost) by localhost.localdomain (8.11.6/8.11.6) id g6BGeoq13725 for linux-xfs@oss.sgi.com; Thu, 11 Jul 2002 11:40:50 -0500 Date: Thu, 11 Jul 2002 11:40:50 -0500 From: Stephen Lord Message-Id: <200207111640.g6BGeoq13725@localhost.localdomain> Subject: TAKE - rationalize mount arguments To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jul 11 09:43:58 PDT 2002 Workarea: cf-vpn-sw-corp-64-4.corp.sgi.com:/home/lord/src/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:122852a linux/fs/xfs/xfs_vfsops.c - 1.358 linux/fs/xfs/xfs_clnt.h - 1.32 linux/fs/xfs/xfs_mount.h - 1.149 linux/fs/xfs/linux/xfs_super.c - 1.189 linux/fs/xfs/linux/xfs_vfs.h - 1.21 From owner-linux-xfs@oss.sgi.com Thu Jul 11 10:15:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BHF0Rw009177 for ; Thu, 11 Jul 2002 10:15:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BHF0HU009176 for linux-xfs-outgoing; Thu, 11 Jul 2002 10:15:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BHEsRw009146 for ; Thu, 11 Jul 2002 10:14:54 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA71556 for ; Thu, 11 Jul 2002 12:19:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA70358 for ; Thu, 11 Jul 2002 12:19:23 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6BHEGh01406; Thu, 11 Jul 2002 12:14:16 -0500 Message-Id: <200207111714.g6BHEGh01406@jen.americas.sgi.com> Date: Thu, 11 Jul 2002 12:14:16 -0500 Subject: TAKE - change ih_lock to a read/write spin lock To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This removes an mrlock from xfs and replaces it with a lighter weight lock. Date: Thu Jul 11 10:18:33 PDT 2002 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:122855a linux/fs/xfs/xfs_vnodeops.c - 1.538 linux/fs/xfs/xfs_iget.c - 1.164 linux/fs/xfs/xfs_inode.h - 1.163 From owner-linux-xfs@oss.sgi.com Thu Jul 11 10:27:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BHRARw011629 for ; Thu, 11 Jul 2002 10:27:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BHRAuS011628 for linux-xfs-outgoing; Thu, 11 Jul 2002 10:27:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BHR2Rw011600 for ; Thu, 11 Jul 2002 10:27:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA67207 for ; Thu, 11 Jul 2002 12:31:31 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA28542 for ; Thu, 11 Jul 2002 12:31:31 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6BHQOF01503; Thu, 11 Jul 2002 12:26:24 -0500 Message-Id: <200207111726.g6BHQOF01503@jen.americas.sgi.com> Date: Thu, 11 Jul 2002 12:26:24 -0500 Subject: TAKE - cleanup request layout checking, add EVMS To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Rationalize how we work out the allowed sizes of requests, we now do the checks at mount time, and a much simpler test at IO time. Also add knowledge of EVMS and fix some code added on monday. I would appreciate reports from MD and LVM users. Steve Date: Thu Jul 11 10:29:33 PDT 2002 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:122857a linux/fs/xfs/pagebuf/page_buf_locking.c - 1.18 - Do determination of allowed request layouts at mount time rather than at request time. Probably about a million less tests this way. linux/fs/xfs/pagebuf/page_buf.c - 1.38 - More cleanup of page locking during read, also rationalize the code in the I/O path which understands the layour restrictions of specific device types. linux/fs/xfs/pagebuf/page_buf.h - 1.26 - add new flags field to pb_target structure From owner-linux-xfs@oss.sgi.com Thu Jul 11 11:20:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BIKZRw012311 for ; Thu, 11 Jul 2002 11:20:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BIKZoX012310 for linux-xfs-outgoing; Thu, 11 Jul 2002 11:20:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BIKRRw012282 for ; Thu, 11 Jul 2002 11:20:28 -0700 Received: (from lord@localhost) by localhost.localdomain (8.11.6/8.11.6) id g6BIKNI16235 for linux-xfs@oss.sgi.com; Thu, 11 Jul 2002 13:20:23 -0500 Date: Thu, 11 Jul 2002 13:20:23 -0500 From: Stephen Lord Message-Id: <200207111820.g6BIKNI16235@localhost.localdomain> Subject: TAKE - remove VOP_FCNTL & code shrink the create/mkdir/mknod path To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More cleanups from Christoph. Date: Thu Jul 11 11:02:19 PDT 2002 Workarea: cf-vpn-sw-corp-64-4.corp.sgi.com:/home/lord/src/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:122860a linux/fs/xfs/linux/xfs_vnode.h - 1.47 Subject: TAKE - code shrink the create/mkdir/mknod path Date: Thu Jul 11 11:22:30 PDT 2002 Workarea: cf-vpn-sw-corp-64-4.corp.sgi.com:/home/lord/src/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:122863a linux/fs/xfs/linux/xfs_iops.c - 1.163 linux/fs/xfs/linux/xfs_vnode.h - 1.48 From owner-linux-xfs@oss.sgi.com Thu Jul 11 11:27:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BIRnRw013100 for ; Thu, 11 Jul 2002 11:27:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BIRnrq013099 for linux-xfs-outgoing; Thu, 11 Jul 2002 11:27:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BIReRw012477 for ; Thu, 11 Jul 2002 11:27:41 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA42368; Thu, 11 Jul 2002 13:32:09 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-4.corp.sgi.com [134.15.64.4]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA99677; Thu, 11 Jul 2002 13:32:08 -0500 (CDT) Subject: Re: md + xfs (fwd) From: Stephen Lord To: Mihai RUSU Cc: Simon Matter , Seth Mos , Linux XFS List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 11 Jul 2002 13:27:33 -0500 Message-Id: <1026412055.4639.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-07-11 at 11:37, Mihai RUSU wrote: > On Thu, 11 Jul 2002, Simon Matter wrote: > > > When booting a RedHat system with softraid, the linuxrc script looks > > something like this: > > > > #!/bin/nash > > > > echo "Loading raid1 module" > > insmod /lib/raid1.o > > mount -t proc /proc /proc > > echo Mounting /proc filesystem > > echo Creating root device > > mkrootdev /dev/root > > raidautorun /dev/md0 > > echo 0x0100 > /proc/sys/kernel/real-root-dev > > umount /proc > > echo Mounting root filesystem > > mount --ro -t xfs /dev/root /sysroot > > pivot_root /sysroot /sysroot/initrd > > > > The mount command is a builtin command of /bin/nash, maybe this explains > > the different behaviour. I hope one of the gurus can explain it to us. > > > > Simon > > I must add that the system is Slackware 8.0 based. The MD support is > compiled in kernel (no modules support). The partitions are of type RAID > autodetect so linux can detect them at boot time. Also the / and /home > partitions are NOT on the md0 divice. Only /var is. > I do not really have any suggestions for you as to why the log appeared clean, maybe you really were not mounted when the power was pulled. As for the filesystem, all you can do is run xfs_check when you get a chance. Steve From owner-linux-xfs@oss.sgi.com Thu Jul 11 12:44:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BJiERw021403 for ; Thu, 11 Jul 2002 12:44:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BJiEEO021402 for linux-xfs-outgoing; Thu, 11 Jul 2002 12:44:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BJi9Rw021373 for ; Thu, 11 Jul 2002 12:44:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA38046 for ; Thu, 11 Jul 2002 14:48:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA70240 for ; Thu, 11 Jul 2002 14:48:38 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6BJhUu07525; Thu, 11 Jul 2002 14:43:30 -0500 Message-Id: <200207111943.g6BJhUu07525@jen.americas.sgi.com> Date: Thu, 11 Jul 2002 14:43:30 -0500 Subject: TAKE - fix snafu in last change To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The reworking of the create/mkdir/mknod path had a couple of snafus in it, basically the wrong version of the code went in. This one actually works. Date: Thu Jul 11 12:47:29 PDT 2002 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:122873a linux/fs/xfs/linux/xfs_iops.c - 1.164 From owner-linux-xfs@oss.sgi.com Thu Jul 11 13:26:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BKQKRw023840 for ; Thu, 11 Jul 2002 13:26:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BKQKTt023839 for linux-xfs-outgoing; Thu, 11 Jul 2002 13:26:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from brennmeister.de ([216.40.203.205]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BKQCRw023806 for ; Thu, 11 Jul 2002 13:26:12 -0700 Received: (qmail 1371 invoked by uid 106); 11 Jul 2002 20:30:52 -0000 Received: from linux@torsten-bauer.de by ensim.rackshack.net by uid 102 with qmail-scanner-1.12 (avpspamassassin: 2.20. . Clear:SA:0(0.0/5.0):. Processed in 1.264502 secs); 11 Jul 2002 20:30:52 -0000 Received: from unknown (HELO nowhere) (linux@torsten-bauer.de@172.178.212.237) by me with SMTP; 11 Jul 2002 20:30:51 -0000 From: "Torsten Bauer" To: Subject: problems with upgrading from rh 7.2 -> 7.3 Date: Thu, 11 Jul 2002 22:30:45 +0200 Message-ID: <000801c22919$d671ab10$0100a8c0@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi all, since a few days i tried to upgrade my existing rh 7.2 system to a 7.3 using the installer image from sgi - i know that one is unsupported - but probably some of you can help me with. last week i upgraded my rh 7.2 from xfs 1.0.1? to xfs 1.1 today i tried to upgrade then the whole system. after the system ask me if i would modify the packages for the upgrade (which i answered with no) i got the following error message: one or more of the filesystems listed in the /etc/fstab of your linux system are inconsistent and cannot be mounted. please fix that problem. that is my current fstab: LABEL=/1 / xfs defaults 1 1 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/hda7 swap swap defaults 0 0 /dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 i don't get any error regarding my xfs partition anywhere and all checks are running well. did anybody have an solution or an idea what i could do? thanks a lot in advance torsten From owner-linux-xfs@oss.sgi.com Thu Jul 11 13:34:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BKYkRw024270 for ; Thu, 11 Jul 2002 13:34:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BKYkoL024269 for linux-xfs-outgoing; Thu, 11 Jul 2002 13:34:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BKYeRw024237 for ; Thu, 11 Jul 2002 13:34:41 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA77775; Thu, 11 Jul 2002 15:39: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 PAA29025; Thu, 11 Jul 2002 15:39:10 -0500 (CDT) Subject: Re: problems with upgrading from rh 7.2 -> 7.3 From: Eric Sandeen To: Torsten Bauer Cc: linux-xfs@oss.sgi.com In-Reply-To: <000801c22919$d671ab10$0100a8c0@nowhere> References: <000801c22919$d671ab10$0100a8c0@nowhere> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Jul 2002 15:38:50 -0500 Message-Id: <1026419930.4832.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are you certain that your / xfs filesystem was cleanly unmounted? Perhaps if you can get to the shell before the installer tries to mount it, you can try to manually mount it and see what happens. You might also look at the other consoles for any error messages that might be there. You might also try removing the label and explicity list the device; just a wild guess. :) -Eric On Thu, 2002-07-11 at 15:30, Torsten Bauer wrote: > hi all, > > since a few days i tried to upgrade my existing rh 7.2 system to a 7.3 > using the installer image from sgi - i know that one is unsupported - > but probably some of you can help me with. From owner-linux-xfs@oss.sgi.com Thu Jul 11 13:52:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BKqHRw025233 for ; Thu, 11 Jul 2002 13:52:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BKqHAB025232 for linux-xfs-outgoing; Thu, 11 Jul 2002 13:52:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ente.berdmann.de (frnk-d514e1c1.dsl.mediaWays.net [213.20.225.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BKqBRw025192 for ; Thu, 11 Jul 2002 13:52:12 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 17Skys-0005id-00; Thu, 11 Jul 2002 22:56:06 +0200 Message-ID: <3D2DF0E6.31EAE87D@berdmann.de> Date: Thu, 11 Jul 2002 22:56:06 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Torsten Bauer CC: linux-xfs@oss.sgi.com Subject: Re: problems with upgrading from rh 7.2 -> 7.3 References: <000801c22919$d671ab10$0100a8c0@nowhere> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Torsten Bauer wrote: [...] > after the system ask me if i would modify the packages for the upgrade > (which i answered with no) i got the following error message: > > one or more of the filesystems listed in the /etc/fstab of your linux > system are inconsistent and cannot be mounted. please fix that problem. > > that is my current fstab: > > LABEL=/1 / xfs defaults > 1 1 [...] replace LABEL=... by the device name From owner-linux-xfs@oss.sgi.com Thu Jul 11 16:42:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BNgKRw026519 for ; Thu, 11 Jul 2002 16:42:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BNgKAS026518 for linux-xfs-outgoing; Thu, 11 Jul 2002 16:42:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from brennmeister.de ([216.40.203.205]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BNgERw026490 for ; Thu, 11 Jul 2002 16:42:15 -0700 Received: (qmail 8291 invoked by uid 106); 11 Jul 2002 23:46:56 -0000 Received: from linux@torsten-bauer.de by ensim.rackshack.net by uid 102 with qmail-scanner-1.12 (avpspamassassin: 2.20. . Clear:SA:0(-4.4/5.0):. Processed in 1.694453 secs); 11 Jul 2002 23:46:56 -0000 Received: from unknown (HELO AC8CF5C3.ipt.aol.com) (linux@torsten-bauer.de@172.140.245.195) by me with SMTP; 11 Jul 2002 23:46:55 -0000 Subject: Re: problems with upgrading from rh 7.2 -> 7.3 From: Torsten Bauer To: linux-xfs@oss.sgi.com In-Reply-To: <1026419930.4832.9.camel@stout.americas.sgi.com> References: <000801c22919$d671ab10$0100a8c0@nowhere> <1026419930.4832.9.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 12 Jul 2002 01:46:47 +0200 Message-Id: <1026431210.15410.10.camel@nowhere.torsten-bauer.de> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-07-11 at 22:38, Eric Sandeen wrote: > You might also try removing the label and explicity list the device; > just a wild guess. :) hmm.. that was exact the right help :) i noticed it.. but i thought... probably xfs need that kind of syntax :) never seen that before.. seems to be in the file since i installed the box a couple of month ago with the xfs installer... thanks! torsten From owner-linux-xfs@oss.sgi.com Thu Jul 11 17:34:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C0YjRw027275 for ; Thu, 11 Jul 2002 17:34:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C0Yj2g027274 for linux-xfs-outgoing; Thu, 11 Jul 2002 17:34:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C0YORw027245 for ; Thu, 11 Jul 2002 17:34:24 -0700 Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel10.hp.com (Postfix) with ESMTP id 690FFC0045A for ; Thu, 11 Jul 2002 12:13:46 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 6889EE000B6 for ; Thu, 11 Jul 2002 12:13:46 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2655.55) id <32DCJS7X>; Thu, 11 Jul 2002 12:13:46 -0700 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: kernel BUG with 2.4.19-rc1, XFS CVS July 9, 2002 and SPEC SFS NFS testing Date: Thu, 11 Jul 2002 12:13:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.7 required=5.0 tests=SUBJ_HAS_SPACES version=2.20 X-Spam-Level: ** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, I'm getting the following kernel BUG when running SPEC SFS NFS testing on a 2.4.19-rc1 kernel and an XFS CVS download from July 9th: Hardware: 4 Intel PIII 700 MHz 1MB cache 2 GB memory whole bunch of fibre channel disks ksymoops 2.4.0 on i686 2.4.2-2. Options used -V (default) -K (specified) -L (specified) -O (specified) -m System.map (specified) kernel BUG at filemap.c:843! invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: c1369d10 ecx: 00000016 edx: c0338f54 esi: c2801268 edi: f6d152a0 ebp: e598e3a0 esp: f7bfbecc ds: 0018 es: 0018 ss: 0018 Process ksoftirqd_CPU0 (pid: 3, stackpage=f7bfb000) Stack: c470fb40 c470fb40 c01e316f f6a6c4b8 c470fb40 00000001 f6a6c400 c1369d10 c01e31ad c470fb40 00000001 00000001 c024a30e c470fb40 00000001 f6a6c400 f6a6c400 00000001 00000010 c024a612 f6a6c400 00000001 00000008 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 4b 03 a0 43 2e c0 8d 46 04 39 46 04 74 0e 31 c9 ba 03 >>EIP; c012992c <===== Trace; c01e316f <_end_pagebuf_page_io_multi+107/134> Trace; c01e31ad <_end_io_multi_full+11/18> Trace; c024a30e <__scsi_end_request+6a/130> Trace; c024a612 Trace; c027550b Trace; c02446f7 Trace; c02445b6 Trace; c011d190 Trace; c011d063 Trace; c011cdef Trace; c011d325 Trace; c0107014 Code; c012992c 00000000 <_EIP>: Code; c012992c <===== 0: 0f 0b ud2a <===== Code; c012992e 2: 4b dec %ebx Code; c012992f 3: 03 a0 43 2e c0 8d add 0x8dc02e43(%eax),%esp Code; c0129935 9: 46 inc %esi Code; c0129936 a: 04 39 add $0x39,%al Code; c0129938 c: 46 inc %esi Code; c0129939 d: 04 74 add $0x74,%al Code; c012993b f: 0e push %cs Code; c012993c 10: 31 c9 xor %ecx,%ecx Code; c012993e 12: ba 03 00 00 00 mov $0x3,%edx <0>Kernel panic: Aiee, killing interrupt handler! Here's the code from fs/filemap.c:unlock_page: /* * Unlock the page and wake up sleepers in ___wait_on_page. */ void unlock_page(struct page *page) { wait_queue_head_t *waitqueue = page_waitqueue(page); ClearPageLaunder(page); smp_mb__before_clear_bit(); if (!test_and_clear_bit(PG_locked, &(page)->flags)) BUG(); <===== smp_mb__after_clear_bit(); if (waitqueue_active(waitqueue)) wake_up_all(waitqueue); } When I run the same test on the same kernel, but with an XFS CVS download from Feb 7, 2002, the test runs to completion without any BUGs. Also, the latency numbers for SPEC SFS also look worse for the latest XFS versus Feb 7 (third number is average response time per operation in milliseconds) linux-2.4.19-rc1-xfs_020702 500 495 0.8 148535 300 3 U 5071248 4 18 2 2 3.0 1000 1001 2.4 300112 299 3 U 10140624 4 18 2 2 3.0 1500 1522 4.2 455020 299 3 U 15211872 4 18 2 2 3.0 2000 2038 4.6 609447 299 3 U 20281248 4 18 2 2 3.0 2500 2532 5.0 757196 299 3 U 25350624 4 18 2 2 3.0 ...test continues fine... linux-2.4.19-rc1-xfs_070902 500 496 0.7 148537 299 3 U 5071248 4 18 2 2 3.0 1000 1001 1.6 300145 299 3 U 10140624 4 18 2 2 3.0 1500 1524 7.3 455664 299 3 U 15211872 4 18 2 2 3.0 2000 2037 10.0 609526 299 3 U 20281248 4 18 2 2 3.0 2500 2523 10.8 756978 300 3 U 25350624 4 18 2 2 3.0 ...test crashes with kernel BUG The only parameter changed between these two tests is the version of XFS. Any ideas? Erik From owner-linux-xfs@oss.sgi.com Fri Jul 12 04:39:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CBdjRw019287 for ; Fri, 12 Jul 2002 04:39:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CBdjRB019286 for linux-xfs-outgoing; Fri, 12 Jul 2002 04:39:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CBddRw019258 for ; Fri, 12 Jul 2002 04:39:39 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA78781; Fri, 12 Jul 2002 06:44:11 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-37.corp.sgi.com [134.15.64.37]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA45734; Fri, 12 Jul 2002 06:44:11 -0500 (CDT) Subject: Re: kernel BUG with 2.4.19-rc1, XFS CVS July 9, 2002 and SPEC SFS NFS testing From: Stephen Lord To: "HABBINGA,ERIK ""(HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 12 Jul 2002 06:39:36 -0500 Message-Id: <1026473978.1159.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,SUBJ_HAS_SPACES version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-07-11 at 14:13, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > Hello all, > I'm getting the following kernel BUG when running SPEC SFS NFS testing on > a 2.4.19-rc1 kernel and an XFS CVS download from July 9th: Sorry about that one Erik, my fault, there was bad code out there for about a day. This should be fixed now. I changed when we hold the lock on pages so that user space and the kernel should not step on each other's feet if both are looking at the device. There was a bug in the initial version which should now be fixed. Steve From owner-linux-xfs@oss.sgi.com Fri Jul 12 09:40:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CGehRw008351 for ; Fri, 12 Jul 2002 09:40:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CGehTg008350 for linux-xfs-outgoing; Fri, 12 Jul 2002 09:40:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CGeYRw008320 for ; Fri, 12 Jul 2002 09:40:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA83516 for ; Fri, 12 Jul 2002 11:45:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA32321 for ; Fri, 12 Jul 2002 11:45:08 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6CGdp019554; Fri, 12 Jul 2002 11:39:51 -0500 Message-Id: <200207121639.g6CGdp019554@jen.americas.sgi.com> Date: Fri, 12 Jul 2002 11:39:51 -0500 Subject: TAKE - ifdef cleanup and endian flipping optimizations To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sounds like a wierd combination, but these ifdefs related to the size of various fields, and there were multiple variants of some of the code. Once the code was simplified, working out some endian optimizations was simple (ish). Note if you are experimenting with other patches for large filesystem support, you might want to edit fs/xfs/xfs_types.h and set XFS_BIG_FILESYSTEMS to 1 again. Other restrictions in linux mean turning this off does not reduce the maximum supported filesystem size any. Steve Date: Fri Jul 12 09:42:01 PDT 2002 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:122932a linux/fs/xfs/xfsidbg.c - 1.189 linux/fs/xfs/xfs_vnodeops.c - 1.539 - remove XFS_BIG_FILES ifdefs linux/fs/xfs/xfs_bmap_btree.h - 1.52 - Remove ifdefs for BMBT_USE_64 linux/fs/xfs/xfs_bmap_btree.c - 1.124 - Remove ifdefs for BMBT_USE_64 and XFS_LARGE_FILES, optimize a lot of endian conversion in the btree code linux/fs/xfs/xfs_dir2_sf.c - 1.29 - Fix debug build with XFS_BIG_FILESYSTEMS off linux/fs/xfs/xfs_inode.h - 1.164 - remove XFS_BIG_FILES ifdefs linux/fs/xfs/xfs_types.h - 1.58 - Remove XFS_BIG_FILES and set XFS_BIG_FILESYSTEMS to 0 linux/fs/xfs/xfs_bmap.c - 1.287 - Remove ifdefs for BMBT_USE_64 From owner-linux-xfs@oss.sgi.com Fri Jul 12 13:59:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CKxIRw018256 for ; Fri, 12 Jul 2002 13:59:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CKxIHj018255 for linux-xfs-outgoing; Fri, 12 Jul 2002 13:59:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CKx9Rw018226 for ; Fri, 12 Jul 2002 13:59:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA90371 for ; Fri, 12 Jul 2002 16:03:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA00172 for ; Fri, 12 Jul 2002 16:03:43 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6CKwOc00884; Fri, 12 Jul 2002 15:58:24 -0500 Message-Id: <200207122058.g6CKwOc00884@jen.americas.sgi.com> Date: Fri, 12 Jul 2002 15:58:24 -0500 Subject: TAKE - more dead code removal To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Jul 12 14:03:14 PDT 2002 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:122956a linux/fs/xfs/xfs_vnodeops.c - 1.540 - remove xfs_allocstore and a call to vop_realvp linux/fs/xfs/xfs_dir.c - 1.138 - unneeded cell_capable ifdef linux/fs/xfs/xfs_iocore.c - 1.32 - remove xfs_checklock call linux/fs/xfs/xfs_mount.h - 1.150 - remove xfs_checklock from iocore linux/fs/xfs/xfs_dir2.c - 1.35 - unneeded cell_capable ifdef linux/fs/xfs/linux/xfs_fs_subr.c - 1.33 - remove fs_vnode_change and symbol exports linux/fs/xfs/linux/xfs_vnode.h - 1.49 - allocstore and realvp removed linux/fs/xfs/linux/xfs_fs_subr.h - 1.8 - remove fs_vnode_change prototype From owner-linux-xfs@oss.sgi.com Fri Jul 12 14:08:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CL82Rw018487 for ; Fri, 12 Jul 2002 14:08:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CL82rf018486 for linux-xfs-outgoing; Fri, 12 Jul 2002 14:08:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CL7oRw018457 for ; Fri, 12 Jul 2002 14:07:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA82588 for ; Fri, 12 Jul 2002 16:12:24 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA05701 for ; Fri, 12 Jul 2002 16:12:24 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6CL75f01963; Fri, 12 Jul 2002 16:07:05 -0500 Message-Id: <200207122107.g6CL75f01963@jen.americas.sgi.com> Date: Fri, 12 Jul 2002 16:07:05 -0500 Subject: TAKE - another batch of Christoph changes To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are you dizzy yet? Steve ----- fix compiler warnings Date: Fri Jul 12 13:27:41 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122953a linux/fs/xfs/xfs_rtalloc.c - 1.75 Subject: TAKE - xfs does export symbols Date: Fri Jul 12 13:29:24 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122954a linux/fs/xfs/linux/xfs_super.c - 1.190 Subject: TAKE - kill get_current_cred() Date: Fri Jul 12 13:52:29 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122955a linux/fs/xfs/xfs_dmapi.c - 1.69 linux/fs/xfs/linux/xfs_file.c - 1.73 linux/fs/xfs/linux/xfs_vnode.c - 1.88 linux/fs/xfs/linux/xfs_cred.h - 1.20 linux/fs/xfs/linux/xfs_ioctl.c - 1.68 linux/fs/xfs/xfs_acl.c - 1.32 linux/fs/xfs/xfs_cap.c - 1.5 Subject: TAKE - debug build fix Date: Fri Jul 12 14:10:34 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122962a linux/fs/xfs/xfs_fs.h - 1.1 linux/fs/xfs/xfs_dir2_sf.c - 1.30 Subject: TAKE - move xfs_fs.h Date: Fri Jul 12 14:11:14 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122963a linux/include/linux/xfs_fs.h - 1.36 linux/fs/xfs/pagebuf/page_buf.c - 1.39 From owner-linux-xfs@oss.sgi.com Fri Jul 12 14:21:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CLLaRw019405 for ; Fri, 12 Jul 2002 14:21:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CLLanZ019404 for linux-xfs-outgoing; Fri, 12 Jul 2002 14:21:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CLLLRw019376 for ; Fri, 12 Jul 2002 14:21:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA91192 for ; Fri, 12 Jul 2002 16:25:55 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA11675 for ; Fri, 12 Jul 2002 16:25:55 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6CLKaI02740; Fri, 12 Jul 2002 16:20:36 -0500 Message-Id: <200207122120.g6CLKaI02740@jen.americas.sgi.com> Date: Fri, 12 Jul 2002 16:20:36 -0500 Subject: TAKE - white space cleanup To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fallout from Eric's kernel cleanup, and this lets me use the tools to work out what is really different again. Date: Fri Jul 12 14:24:23 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122964a cmd/xfsprogs/logprint/logprint.c - 1.10 cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.14 cmd/xfsprogs/libxlog/util.c - 1.5 cmd/xfsprogs/include/xfs_trans_space.h - 1.6 cmd/xfsprogs/include/xfs_log.h - 1.11 cmd/xfsprogs/include/xfs_inum.h - 1.6 cmd/xfsprogs/include/xfs_ialloc.h - 1.6 cmd/xfsprogs/include/xfs_ag.h - 1.10 cmd/xfsprogs/include/xfs_extfree_item.h - 1.6 cmd/xfsprogs/include/xfs_buf_item.h - 1.6 cmd/xfsprogs/include/xfs_attr_sf.h - 1.7 cmd/xfsprogs/include/xfs_log_priv.h - 1.10 cmd/xfsprogs/include/xfs_da_btree.h - 1.8 cmd/xfsprogs/include/xfs_bit.h - 1.10 cmd/xfsprogs/include/xfs_sb.h - 1.7 cmd/xfsprogs/include/xfs_dir2_block.h - 1.6 cmd/xfsprogs/include/xfs_fs.h - 1.19 cmd/xfsprogs/include/xfs_dir.h - 1.6 cmd/xfsprogs/include/xfs_dqblk.h - 1.6 cmd/xfsprogs/include/xfs_arch.h - 1.6 cmd/xfsprogs/include/xfs_rtalloc.h - 1.7 cmd/xfsprogs/include/xfs_ialloc_btree.h - 1.6 cmd/xfsprogs/include/xfs_inode_item.h - 1.6 cmd/xfsprogs/include/arch.h - 1.8 cmd/xfsprogs/include/xfs_log_recover.h - 1.6 cmd/xfsprogs/include/xfs_dquot_item.h - 1.6 cmd/xfsprogs/include/xfs_dfrag.h - 1.6 cmd/xfsprogs/include/xfs_bmap_btree.h - 1.6 cmd/xfsprogs/include/xfs_dir2_sf.h - 1.6 cmd/xfsprogs/include/xfs_dir_leaf.h - 1.8 cmd/xfsprogs/include/xfs_mount.h - 1.24 cmd/xfsprogs/include/xfs_btree.h - 1.6 cmd/xfsprogs/include/xfs_dir2_data.h - 1.6 cmd/xfsprogs/include/xfs_inode.h - 1.22 cmd/xfsprogs/include/xfs_dir2_leaf.h - 1.6 cmd/xfsprogs/include/xfs_attr_leaf.h - 1.7 cmd/xfsprogs/include/xfs_types.h - 1.11 cmd/xfsprogs/include/xfs_trans.h - 1.8 cmd/xfsprogs/include/xfs_dir_sf.h - 1.6 cmd/xfsprogs/include/xfs_alloc.h - 1.7 cmd/xfsprogs/include/xfs_imap.h - 1.6 cmd/xfsprogs/include/xfs_bmap.h - 1.7 cmd/xfsprogs/include/xfs_alloc_btree.h - 1.6 cmd/xfsprogs/include/xfs_quota.h - 1.10 cmd/xfsprogs/include/xfs_dir2_node.h - 1.6 cmd/xfsprogs/include/xfs_dir2.h - 1.7 cmd/xfsprogs/include/xfs_dinode.h - 1.8 cmd/xfsprogs/libxfs/xfs_ialloc.c - 1.14 cmd/xfsprogs/libxfs/rdwr.c - 1.10 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.14 cmd/xfsprogs/libxfs/logitem.c - 1.6 cmd/xfsprogs/libxfs/trans.c - 1.7 cmd/xfsprogs/libxfs/init.c - 1.19 cmd/xfsprogs/libxfs/xfs_dir2_block.c - 1.8 cmd/xfsprogs/libxfs/xfs_dir.c - 1.7 cmd/xfsprogs/libxfs/xfs_rtalloc.c - 1.11 cmd/xfsprogs/libxfs/xfs_ialloc_btree.c - 1.6 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.10 cmd/xfsprogs/libxfs/xfs_dir2_sf.c - 1.8 cmd/xfsprogs/libxfs/xfs_dir_leaf.c - 1.9 cmd/xfsprogs/libxfs/xfs_mount.c - 1.10 cmd/xfsprogs/libxfs/xfs_btree.c - 1.10 cmd/xfsprogs/libxfs/xfs_dir2_data.c - 1.7 cmd/xfsprogs/libxfs/xfs_inode.c - 1.12 cmd/xfsprogs/libxfs/xfs_dir2_leaf.c - 1.7 cmd/xfsprogs/libxfs/xfs_attr_leaf.c - 1.6 cmd/xfsprogs/libxfs/util.c - 1.9 cmd/xfsprogs/libxfs/xfs_trans.c - 1.5 cmd/xfsprogs/libxfs/xfs_alloc.c - 1.15 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.15 cmd/xfsprogs/libxfs/xfs_alloc_btree.c - 1.7 cmd/xfsprogs/libxfs/xfs_dir2_node.c - 1.8 cmd/xfsprogs/libxfs/xfs_dir2.c - 1.7 cmd/xfstests/tools/srcdiff - 1.20 cmd/xfsprogs/libxfs/bit.c - 1.2 cmd/xfsprogs/include/xfs_cap.h - 1.4 cmd/xfsprogs/include/xfs_mac.h - 1.3 cmd/xfsprogs/include/xfs_acl.h - 1.4 From owner-linux-xfs@oss.sgi.com Sat Jul 13 01:20:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6D8KBRw025452 for ; Sat, 13 Jul 2002 01:20:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6D8KBxn025451 for linux-xfs-outgoing; Sat, 13 Jul 2002 01:20:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus.city.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6D8K5Rw025423 for ; Sat, 13 Jul 2002 01:20:06 -0700 Received: by zeus.city.tvnet.hu (Postfix, from userid 500) id 918393C25722; Sat, 13 Jul 2002 10:24:45 +0200 (CEST) Subject: makepkgs problem From: Sipos Ferenc To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-2) Date: 13 Jul 2002 10:24:45 +0200 Message-Id: <1026548685.2295.20.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! In the latest redhat beta, the rpm package created a new command, rpmbuild, so the old rpm -ta won't work, only rpmbuild -ta. If someone would correct the Makepkgs script in the cmd dir, to check for rpmbuild, and use it if it exists i would appriciate that. Thx. Paco From owner-linux-xfs@oss.sgi.com Sat Jul 13 10:54:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6DHsSRw030920 for ; Sat, 13 Jul 2002 10:54:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6DHsSjR030919 for linux-xfs-outgoing; Sat, 13 Jul 2002 10:54:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf22bis.bellsouth.net (mail022.mail.bellsouth.net [205.152.58.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6DHsMRw030891 for ; Sat, 13 Jul 2002 10:54:22 -0700 Received: from bellsouth.net ([65.80.93.81]) by imf22bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20020713175900.RKBH19755.imf22bis.bellsouth.net@bellsouth.net> for ; Sat, 13 Jul 2002 13:59:00 -0400 Message-ID: <3D30691C.2F1F7F72@bellsouth.net> Date: Sat, 13 Jul 2002 13:53:32 -0400 From: Jeff Layton X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17-j i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Integrating XFS with experimental NFS patches Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I'm working on a patched 2.4.19-rc1 kernel with XFS (plus some other things). I'm also trying to integrate Trond's experimental NFS patches: http://www.fys.uio.no/~trondmy/src/2.4.19-rc1/ I'm having a great deal of trouble integrating the patches. Does anyone have any suggestions how I might do this? (my patch skills are worefully inadequate for this I think). TIA, Jeff From owner-linux-xfs@oss.sgi.com Sat Jul 13 19:04:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6E24sRw001282 for ; Sat, 13 Jul 2002 19:04:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6E24sK3001281 for linux-xfs-outgoing; Sat, 13 Jul 2002 19:04:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6E24mRw001251 for ; Sat, 13 Jul 2002 19:04:48 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA01603; Sat, 13 Jul 2002 21:09: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 VAA28803; Sat, 13 Jul 2002 21:09:27 -0500 (CDT) Date: Sat, 13 Jul 2002 21:08:47 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jeff Layton cc: linux-xfs@oss.sgi.com Subject: Re: Integrating XFS with experimental NFS patches In-Reply-To: <3D30691C.2F1F7F72@bellsouth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Jeff - What patches are you trying, specifically, and how are they failing? There's no "HOWTO" on patch reject fixups, afaik. :) but with some examples perhaps we can help. -Eric On Sat, 13 Jul 2002, Jeff Layton wrote: > Hello, > > I'm working on a patched 2.4.19-rc1 kernel with XFS (plus some > other things). I'm also trying to integrate Trond's experimental NFS > patches: > > http://www.fys.uio.no/~trondmy/src/2.4.19-rc1/ > > I'm having a great deal of trouble integrating the patches. Does > anyone have any suggestions how I might do this? (my patch skills > are worefully inadequate for this I think). > > TIA, > > Jeff > > From owner-linux-xfs@oss.sgi.com Sun Jul 14 10:20:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6EHKORw012052 for ; Sun, 14 Jul 2002 10:20:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6EHKNT4012051 for linux-xfs-outgoing; Sun, 14 Jul 2002 10:20:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bjont97.videum.vxu.se (iwty39910@bjont97.videum.vxu.se [194.47.105.86]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6EHKHRw012023 for ; Sun, 14 Jul 2002 10:20:17 -0700 Received: (qmail 7220 invoked from network); 14 Jul 2002 17:25:01 -0000 Received: from bilbo.home.sve (192.168.0.2) by hobbit.home.sve with SMTP; 14 Jul 2002 17:25:01 -0000 Received: by bilbo.home.sve (Postfix on SuSE Linux 7.3 (i386), from userid 501) id A07F07C069; Sun, 14 Jul 2002 19:25:00 +0200 (CEST) Date: Sun, 14 Jul 2002 19:25:00 +0200 From: Bo Johansson To: Kelledin Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and grub-0.92 Message-ID: <20020714172500.GA5215@bjont97.videum.vxu.se> References: <200207100551.g6A5pX5G003057@Traveller.attbi.com> <20020710061931.GA18472@ids.org.au> <200207100743.g6A7hBiJ003200@Traveller.attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200207100743.g6A7hBiJ003200@Traveller.attbi.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,FROM_ENDS_IN_NUMS,TO_LOCALPART_EQ_REAL,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jul 10, 2002 at 02:43:11AM -0500, Kelledin wrote: > I just went through the XFS FAQ again and found something else...particularly > concerning LILO. It has the same problem as grub--it can't be installed on > the bootsector of a root partition, because it overwrites the XFS superblock. > This is apparently a limitation of XFS; only reason it worked with lilo is > because I had lilo's bootsector residing on floppy. If you want to have a separate bootsector you can install it on your swap-partition. I have been booting from swap for quite some time and it doesn't get overwritten. Regards Bosse -- Pussy: You spend 9 months trying to get out of it, and the rest of your life trying to get back in... From owner-linux-xfs@oss.sgi.com Sun Jul 14 15:44:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6EMipRw016750 for ; Sun, 14 Jul 2002 15:44:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6EMipwY016749 for linux-xfs-outgoing; Sun, 14 Jul 2002 15:44:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.modwest.com (marshall.modwest.com [208.146.72.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6EMijRw016721 for ; Sun, 14 Jul 2002 15:44:46 -0700 Received: from [10.0.0.142] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by mail.modwest.com (8.12.4/8.12.2) with ESMTP id g6EMnRcr017350 for ; Sun, 14 Jul 2002 16:49:27 -0600 Subject: Re: Integrating XFS with experimental NFS patches From: Sean Gabriel Heacock To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 14 Jul 2002 16:48:19 -0600 Message-Id: <1026686899.29631.6.camel@epyon.modwest.com> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a patch for 2.4.19-rc1 that adds the XFS snapshot from July 2nd, both Trond's and Neil Brown's NFS patches, the O(1) schedular patch, and EVMS 1.1-pre4, at http://www.modwest.com/software.phtml . So far it's working well for me, I must be getting better at hand-patching :) -- Sean Gabriel Heacock System Administrator Modwest, Inc. From owner-linux-xfs@oss.sgi.com Sun Jul 14 16:24:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ENOXRw017399 for ; Sun, 14 Jul 2002 16:24:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ENOXPg017398 for linux-xfs-outgoing; Sun, 14 Jul 2002 16:24:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gate.k1iu.org (pool-64-223-227-69.port.east.verizon.net [64.223.227.69]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ENOORw017367 for ; Sun, 14 Jul 2002 16:24:24 -0700 Received: from gate.k1iu.org (gate.k1iu.org [192.168.1.3]) by gate.k1iu.org (Postfix) with ESMTP id 152D9168633 for ; Sun, 14 Jul 2002 19:29:07 -0400 (EDT) Date: Sun, 14 Jul 2002 19:29:07 -0400 (EDT) From: Tim - K1BR X-X-Sender: k1br@gate.k1iu.org To: linux-xfs@oss.sgi.com Subject: Compilation failure in xfs_db Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm getting the folllowing error trying to compile xfsprogs, specifically in xfs_bd: /usr/bin/libtool --mode=link gcc -o xfs_db -static addr.o agf.o agfl.o agi.o attr.o attrshort.o bit.o block.o bmap.o bmapbt.o bmroot.o bnobt.o check.o cntbt.o command.o convert.o data.o dbread.o debug.o dir.o dir2.o dir2sf.o dirshort.o dquot.o echo.o faddr.o field.o flist.o fprint.o frag.o freesp.o hash.o help.o init.o inobt.o inode.o input.o io.o malloc.o mount.o output.o print.o quit.o sb.o sig.o strvec.o text.o type.o uuid.o write.o main.o ../libxfs/libxfs.la /usr/lib/libuuid.a gcc -o xfs_db addr.o agf.o agfl.o agi.o attr.o attrshort.o bit.o block.o bmap.o bmapbt.o bmroot.o bnobt.o check.o cntbt.o command.o convert.o data.o dbread.o debug.o dir.o dir2.o dir2sf.o dirshort.o dquot.o echo.o faddr.o field.o flist.o fprint.o frag.o freesp.o hash.o help.o init.o inobt.o inode.o input.o io.o malloc.o mount.o output.o print.o quit.o sb.o sig.o strvec.o text.o type.o uuid.o write.o main.o ../libxfs/.libs/libxfs.a /usr/lib/libuuid.a check.o: In function `process_rtbitmap': /usr/src/linux-xfs-cvs/cmd/xfsprogs/db/check.c:3476: undefined reference to `xfs_highbit32' /usr/src/linux-xfs-cvs/cmd/xfsprogs/db/check.c:3489: undefined reference to `xfs_highbit32' collect2: ld returned 1 exit status make[1]: *** [xfs_db] Error 1 make: *** [default] Error 2 xfs_highbit32 seems to be defined both is libxfs/bit.c as an actual function, and in include/xfs.h, as a #define to libxfs_highbit32, which as far as I can tell is never defined. The system is a up-to-date Debian woody with gcc 3.0.4 (same error with gcc 2.95.4), and the source was grabbed today via CVSup. TIA for any help, pointers, hand-holding, etc. Tim From owner-linux-xfs@oss.sgi.com Sun Jul 14 18:13:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F1D3Rw019276 for ; Sun, 14 Jul 2002 18:13:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F1D3N8019275 for linux-xfs-outgoing; Sun, 14 Jul 2002 18:13:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F1CwRw019247 for ; Sun, 14 Jul 2002 18:12:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 SAA00380 for ; Sun, 14 Jul 2002 18:17:46 -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 LAA91905 for linux-xfs@oss.sgi.com; Mon, 15 Jul 2002 11:13:54 +1000 (EST) Date: Mon, 15 Jul 2002 11:13:54 +1000 (EST) From: Nathan Scott Message-Id: <200207150113.LAA91905@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs build X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fix for "undefined reference to xfs_highbit32" build problem in xfs_db. Date: Sun Jul 14 18:14:59 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122996a cmd/xfsprogs/include/xfs_types.h - 1.12 - allow userspace to be built with XFS_BIG_FILESYSTEMS set. From owner-linux-xfs@oss.sgi.com Sun Jul 14 18:19:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F1JwRw019468 for ; Sun, 14 Jul 2002 18:19:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F1Jw1e019467 for linux-xfs-outgoing; Sun, 14 Jul 2002 18:19:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F1JnRw019439 for ; Sun, 14 Jul 2002 18:19:49 -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 SAA02987 for ; Sun, 14 Jul 2002 18:25:04 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27254; Mon, 15 Jul 2002 11:23:17 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) with ESMTP id g6F1LsWQ001616; Mon, 15 Jul 2002 11:21:54 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) id g6F1Lrh0001614; Mon, 15 Jul 2002 11:21:53 +1000 Date: Mon, 15 Jul 2002 11:21:53 +1000 From: Nathan Scott To: Tim - K1BR Cc: linux-xfs@oss.sgi.com Subject: Re: Compilation failure in xfs_db Message-ID: <20020715012153.GC456@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sun, Jul 14, 2002 at 07:29:07PM -0400, Tim - K1BR wrote: > > I'm getting the folllowing error trying to compile xfsprogs, specifically > in xfs_bd: > > /usr/bin/libtool --mode=link gcc -o xfs_db -static addr.o agf.o agfl.o > agi.o attr.o attrshort.o bit.o block.o bmap.o bmapbt.o bmroot.o bnobt.o > check.o cntbt.o > command.o convert.o data.o dbread.o debug.o dir.o dir2.o dir2sf.o > dirshort.o dquot.o echo.o faddr.o field.o flist.o fprint.o frag.o freesp.o > hash.o help.o init.o inobt.o inode.o input.o io.o malloc.o mount.o > output.o print.o quit.o sb.o sig.o strvec.o text.o type.o uuid.o write.o > main.o ../libxfs/libxfs.la /usr/lib/libuuid.a > gcc -o xfs_db addr.o agf.o agfl.o agi.o attr.o attrshort.o bit.o block.o > bmap.o > bmapbt.o bmroot.o bnobt.o check.o cntbt.o command.o convert.o data.o > dbread.o debug.o dir.o dir2.o dir2sf.o dirshort.o dquot.o echo.o faddr.o > field.o flist.o fprint.o frag.o freesp.o hash.o help.o init.o inobt.o > inode.o input.o io.o malloc.o mount.o output.o print.o quit.o sb.o sig.o > strvec.o text.o type.o uuid.o write.o main.o ../libxfs/.libs/libxfs.a > /usr/lib/libuuid.a > check.o: In function `process_rtbitmap': > /usr/src/linux-xfs-cvs/cmd/xfsprogs/db/check.c:3476: undefined reference > to `xfs_highbit32' > /usr/src/linux-xfs-cvs/cmd/xfsprogs/db/check.c:3489: undefined reference > to `xfs_highbit32' > collect2: ld returned 1 exit status > make[1]: *** [xfs_db] Error 1 > make: *** [default] Error 2 > This is fixed, a CVS pull should pick up the new change shortly. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jul 14 18:20:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F1KoRw019510 for ; Sun, 14 Jul 2002 18:20:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F1KoAc019509 for linux-xfs-outgoing; Sun, 14 Jul 2002 18:20:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.ruad (avtodor.gorny.ru [212.164.99.171]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F1KZRw019480 for ; Sun, 14 Jul 2002 18:20:40 -0700 Received: from sokolov.ruad ([192.168.183.47]) by mail.ruad (Lotus Domino Release 5.0.9a) with ESMTP id 2002071508250049:281 ; Mon, 15 Jul 2002 08:25:00 +0700 Date: Mon, 15 Jul 2002 08:25:00 +0700 From: =?koi8-r?B?88/Lz8zP1yDzxdLHxco=?= X-Mailer: The Bat! (v1.60c) Personal Reply-To: =?koi8-r?B?88/Lz8zP1yDzxdLHxco=?= X-Priority: 3 (Normal) Message-ID: <1662520654.20020715082500@avtodor.gorny.ru> To: linux-xfs@oss.sgi.com Subject: kernel BUG at buffer.c MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on mail/Gorno-Altaiavtodor(Release 5.0.9a |January 7, 2002) at 15.07.2002 08:25:00, Serialize by Router on mail/Gorno-Altaiavtodor(Release 5.0.9a |January 7, 2002) at 15.07.2002 08:25:12 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6F1KhRw019482 X-Spam-Status: No, hits=1.8 required=5.0 tests=CHARSET_FARAWAY_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello! I have linux kernel 2.4.19-rc1 with xfs enabled. My xfs partition locate on /dev/ataraid device (Promise FastTrak Tx4). I have two problems: 1) [root@ws188 linux-2.4.19-rc1-xfs]# mkfs.xfs /dev/ataraid/d1p2 mkfs.xfs: warning - cannot set blocksize on block device /dev/ataraid/d1p2: Invalid argument 2)When i copying files between partitions, I receive message. Jul 12 17:01:19 ws188 kernel: kernel BUG at buffer.c:549! Jul 12 17:01:19 ws188 kernel: invalid operand: 0000 Jul 12 17:01:19 ws188 kernel: CPU: 0 Jul 12 17:01:19 ws188 kernel: EIP: 0010:[__insert_into_lru_list+37/112] Not tainted Jul 12 17:01:19 ws188 kernel: EIP: 0010:[] Not tainted Jul 12 17:01:19 ws188 kernel: EFLAGS: 00010206 Jul 12 17:01:19 ws188 kernel: eax: 00000000 ebx: 00000008 ecx: d6e297c0 edx: c02ec594 Jul 12 17:01:19 ws188 kernel: esi: 00000002 edi: 00001000 ebp: 00000000 esp: df0ebe18 Jul 12 17:01:19 ws188 kernel: ds: 0018 es: 0018 ss: 0018 Jul 12 17:01:19 ws188 kernel: Process mc (pid: 872, stackpage=df0eb000) Jul 12 17:01:19 ws188 kernel: Stack: 00000002 d6e297c0 c012fb64 d6e297c0 00000002 d6e297c0 00001000 c012fb7a Jul 12 17:01:19 ws188 kernel: d6e297c0 c01305a5 d6e297c0 00000000 d09b22c0 484cc000 00000000 d6e297c0 Jul 12 17:01:19 ws188 kernel: c0130c56 d09b22c0 c10acf20 00000000 00001000 00001000 00001000 00000000 Jul 12 17:01:19 ws188 kernel: Call Trace: [__refile_buffer+84/96] [refile_buffer+10/16] [__block_commit_write+ 117/192] [generic_commit_write+54/96] [pagebuf_generic_file_write+613/768] Jul 12 17:01:19 ws188 kernel: Call Trace: [] [] [] [] [] Jul 12 17:01:19 ws188 kernel: [xfs_write+1032/1808] [linvfs_pb_bmap+0/208] [linvfs_write+812/864] [sys_writ e+150/240] [system_call+51/56] Jul 12 17:01:19 ws188 kernel: [] [] [] [] [] Jul 12 17:01:19 ws188 kernel: Jul 12 17:01:19 ws188 kernel: Code: 0f 0b 25 02 60 9e 26 c0 8b 02 85 c0 75 07 89 0a 89 49 24 8b -- Sergei Sokolov From owner-linux-xfs@oss.sgi.com Sun Jul 14 18:39:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F1dHRw019872 for ; Sun, 14 Jul 2002 18:39:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F1dHLf019871 for linux-xfs-outgoing; Sun, 14 Jul 2002 18:39:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F1dARw019842 for ; Sun, 14 Jul 2002 18:39:10 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 SAA00718 for ; Sun, 14 Jul 2002 18:43:58 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27468; Mon, 15 Jul 2002 11:42:38 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) with ESMTP id g6F1fEWQ001667; Mon, 15 Jul 2002 11:41:14 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) id g6F1fDcN001665; Mon, 15 Jul 2002 11:41:13 +1000 Date: Mon, 15 Jul 2002 11:41:13 +1000 From: Nathan Scott To: Sipos Ferenc Cc: linux-xfs@oss.sgi.com Subject: Re: makepkgs problem Message-ID: <20020715014113.GD456@frodo> References: <1026548685.2295.20.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1026548685.2295.20.camel@zeus.city.tvnet.hu> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Jul 13, 2002 at 10:24:45AM +0200, Sipos Ferenc wrote: > Hi! > > In the latest redhat beta, the rpm package created a new command, > rpmbuild, rpmbuild has been around for awhile. rpm should still work with -ba though (we don't use -ta as you suggest below). > so the old rpm -ta won't work, only rpmbuild -ta. If someone > would correct the Makepkgs script in the cmd dir, to check for rpmbuild, > and use it if it exists i would appriciate that. Thx. > > Paco > Could you send the exact error message that you are seeing? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jul 14 21:51:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F4pMRw021558 for ; Sun, 14 Jul 2002 21:51:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F4pMU7021557 for linux-xfs-outgoing; Sun, 14 Jul 2002 21:51:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F4pFRw021523 for ; Sun, 14 Jul 2002 21:51:16 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g6F4txR21318 for ; Mon, 15 Jul 2002 13:55:59 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g6F4twr01289 for ; Mon, 15 Jul 2002 13:55:58 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g6F4tvN19562 for ; Mon, 15 Jul 2002 13:55:58 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA493 for ; Mon, 15 Jul 2002 13:55:56 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Jul 15 13:55:55 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g6F4tuA60317 for ; Mon, 15 Jul 2002 13:55:56 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g6F4tuY25038 for ; Mon, 15 Jul 2002 13:55:56 +0900 To: linux-xfs@oss.sgi.com Subject: filesize after H/W fault X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Honest Recruiter) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020715135555H.masano@tnes.nec.co.jp> Date: Mon, 15 Jul 2002 13:55:55 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 18 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have run old xfs on my server machine. The kernel is linux-2.4.7 and xfs cvs based. This system was working fine for several months without any xfs related troubles. But a problem happened at last. After a hardware fault, some files on xfs were truncated to size zero. The files were created via nfs v3 several hours before the hardware fault, and were not overwritten after created. When the filesystem was mounted at reboot, log recovery was done automatically, and there was no error. I thought file data would be sync'd to disk within minutes after it is written. What happened? Any ideas or patches? -- Masano From owner-linux-xfs@oss.sgi.com Sun Jul 14 21:59:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F4x8Rw021839 for ; Sun, 14 Jul 2002 21:59:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F4x82w021838 for linux-xfs-outgoing; Sun, 14 Jul 2002 21:59:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus.city.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F4wYRw021796 for ; Sun, 14 Jul 2002 21:58:35 -0700 Received: by zeus.city.tvnet.hu (Postfix, from userid 500) id 5CE723C2572E; Mon, 15 Jul 2002 07:03:22 +0200 (CEST) Subject: makepkgs log file From: Sipos Ferenc To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-uu1L5Bj9sk1ShVlZ0nVV" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-2) Date: 15 Jul 2002 07:03:22 +0200 Message-Id: <1026709402.1500.2.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-uu1L5Bj9sk1ShVlZ0nVV Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! I send the dist.log, it clearly shows that rpm -ba won't work. Note, that I use the latest rawhide rpms, but sooner or later you have to change the code, I'm sure. Thx. Paco --=-uu1L5Bj9sk1ShVlZ0nVV Content-Disposition: attachment; filename=dist Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=dist; charset=ISO-8859-2 make: Entering directory `/home/sferi/linux-2.4-xfs/cmd/xfsprogs/build' Wrote: /home/sferi/linux-2.4-xfs/cmd/xfsprogs/build/xfsprogs-2.0.6.src.tar.= gz =3D=3D=3D install =3D=3D=3D make[1]: Entering directory `/home/sferi/linux-2.4-xfs/cmd/xfsprogs' =3D=3D=3D include =3D=3D=3D rm -f xfs ln -s . xfs =3D=3D=3D libxfs =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D libxlog =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D libhandle =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D libdisk =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D bmap =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D db =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D freeze =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D fsck =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D growfs =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D imap =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D logprint =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D mkfile =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D mkfs =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D repair =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D rtcp =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D man =3D=3D=3D =3D=3D=3D man3 =3D=3D=3D make[3]: Nothing to be done for `default'. =3D=3D=3D man5 =3D=3D=3D make[3]: Nothing to be done for `default'. =3D=3D=3D man8 =3D=3D=3D make[3]: Nothing to be done for `default'. =3D=3D=3D doc =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D debian =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D build =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D include =3D=3D=3D rm -f xfs ln -s . xfs =3D=3D=3D libxfs =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D libxlog =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D libhandle =3D=3D=3D cd ../libhandle/.libs; ../../install-sh -o root -g root -m 755 -d /usr/lib;= ../../install-sh -o root -g root -m 644 -T so_dot_version libhandle.lai /u= sr/lib; test "SGI XFS" =3D debian || ../../install-sh -o root -g root -T so= _dot_current libhandle.lai /usr/lib =3D=3D=3D libdisk =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D bmap =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= bmap /usr/sbin ../install-sh -o root -g root -m 755 xfs_bmap /usr/sbin/xfs_bmap =3D=3D=3D db =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= db /usr/sbin ../install-sh -o root -g root -m 755 xfs_db /usr/sbin/xfs_db ../install-sh -o root -g root -m 755 xfs_admin.sh /usr/sbin/xfs_admin ../install-sh -o root -g root -m 755 xfs_check.sh /usr/sbin/xfs_check ../install-sh -o root -g root -m 755 xfs_ncheck.sh /usr/sbin/xfs_ncheck =3D=3D=3D freeze =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= freeze /usr/sbin ../install-sh -o root -g root -m 755 xfs_freeze /usr/sbin/xfs_freeze =3D=3D=3D fsck =3D=3D=3D ../install-sh -o root -g root -m 755 -d /sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 fsck= .xfs /sbin ../install-sh -o root -g root -m 755 fsck.xfs /sbin/fsck.xfs =3D=3D=3D growfs =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= growfs /usr/sbin ../install-sh -o root -g root -m 755 xfs_growfs /usr/sbin/xfs_growfs ../install-sh -o root -g root -m 755 xfs_info.sh /usr/sbin/xfs_info =3D=3D=3D imap =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D logprint =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= logprint /usr/sbin ../install-sh -o root -g root -m 755 xfs_logprint /usr/sbin/xfs_logprint =3D=3D=3D mkfile =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= mkfile /usr/sbin ../install-sh -o root -g root -m 755 xfs_mkfile /usr/sbin/xfs_mkfile =3D=3D=3D mkfs =3D=3D=3D ../install-sh -o root -g root -m 755 -d /sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 mkfs= .xfs /sbin ../install-sh -o root -g root -m 755 mkfs.xfs /sbin/mkfs.xfs =3D=3D=3D repair =3D=3D=3D ../install-sh -o root -g root -m 755 -d /sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= repair /sbin ../install-sh -o root -g root -m 755 xfs_repair /sbin/xfs_repair =3D=3D=3D rtcp =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= rtcp /usr/sbin ../install-sh -o root -g root -m 755 xfs_rtcp /usr/sbin/xfs_rtcp =3D=3D=3D man =3D=3D=3D =3D=3D=3D man3 =3D=3D=3D make[3]: Nothing to be done for `install'. =3D=3D=3D man5 =3D=3D=3D ../../install-sh -o root -g root -m 755 -d /usr/share/man/man5 ../../install-sh -o root -g root -m 644 xfs.5.gz /usr/share/man/man5/xfs.5.= gz =3D=3D=3D man8 =3D=3D=3D ../../install-sh -o root -g root -m 755 -d /usr/share/man/man8 ../../install-sh -o root -g root -m 644 fsck.xfs.8.gz /usr/share/man/man8/f= sck.xfs.8.gz ../../install-sh -o root -g root -m 644 mkfs.xfs.8.gz /usr/share/man/man8/m= kfs.xfs.8.gz ../../install-sh -o root -g root -m 644 xfs_admin.8.gz /usr/share/man/man8/= xfs_admin.8.gz ../../install-sh -o root -g root -m 644 xfs_bmap.8.gz /usr/share/man/man8/x= fs_bmap.8.gz ../../install-sh -o root -g root -m 644 xfs_check.8.gz /usr/share/man/man8/= xfs_check.8.gz ../../install-sh -o root -g root -m 644 xfs_db.8.gz /usr/share/man/man8/xfs= _db.8.gz ../../install-sh -o root -g root -m 644 xfs_freeze.8.gz /usr/share/man/man8= /xfs_freeze.8.gz ../../install-sh -o root -g root -m 644 xfs_growfs.8.gz /usr/share/man/man8= /xfs_growfs.8.gz ../../install-sh -o root -g root -S xfs_growfs.8.gz /usr/share/man/man8/xfs= _info.8.gz ../../install-sh -o root -g root -m 644 xfs_logprint.8.gz /usr/share/man/ma= n8/xfs_logprint.8.gz ../../install-sh -o root -g root -m 644 xfs_mkfile.8.gz /usr/share/man/man8= /xfs_mkfile.8.gz ../../install-sh -o root -g root -m 644 xfs_ncheck.8.gz /usr/share/man/man8= /xfs_ncheck.8.gz ../../install-sh -o root -g root -m 644 xfs_repair.8.gz /usr/share/man/man8= /xfs_repair.8.gz ../../install-sh -o root -g root -m 644 xfs_rtcp.8.gz /usr/share/man/man8/x= fs_rtcp.8.gz =3D=3D=3D doc =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/share/doc/xfsprogs ../install-sh -o root -g root -m 644 PORTING CHANGES.gz CREDITS README.LVM = README.quota /usr/share/doc/xfsprogs ../install-sh -o root -g root -m 644 COPYING /usr/share/doc/xfsprogs =3D=3D=3D debian =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D build =3D=3D=3D make[2]: Nothing to be done for `install'. ./install-sh -o root -g root -m 755 -d /usr/share/doc/xfsprogs ./install-sh -o root -g root -m 644 README /usr/share/doc/xfsprogs make[1]: Leaving directory `/home/sferi/linux-2.4-xfs/cmd/xfsprogs' =3D=3D=3D tar =3D=3D=3D Wrote: /home/sferi/linux-2.4-xfs/cmd/xfsprogs/build/tar/xfsprogs-2.0.6.tar.= gz =3D=3D=3D rpm =3D=3D=3D sed -e's|@pkg_name@|xfsprogs|g' \ -e's|@pkg_version@|2.0.6|g' \ -e's|@pkg_release@|0|g' \ -e's|@pkg_distribution@|SGI XFS|g' \ -e's|@pkg_builder@|sferi@zeus.city.tvnet.hu|g' \ -e's|@build_root@|/tmp/21331|g' \ -e'/^BuildRoot: *$/d' \ -e's|@pkg_var_dir@||g' \ -e's|@pkg_share_dir@||g' \ -e's|@pkg_log_dir@||g' \ -e's|@pkg_doc_dir@|/usr/share/doc/xfsprogs|g' \ -e's|@pkg_man_dir@|/usr/share/man|g' \ -e's|@pkg_tmp_dir@||g' \ -e's|@make@|/usr/bin/make|g' < xfsprogs.spec.in > xfsprogs.spec sed -e '/^macrofiles:/s|~/.rpmmacros|rpmmacros|' rpm-4= .rc /bin/rpm -ba --rcfile ./rpm-4.rc xfsprogs.spec -ba: unknown option make[1]: *** [dist] Error 1 Done make: Leaving directory `/home/sferi/linux-2.4-xfs/cmd/xfsprogs/build' --=-uu1L5Bj9sk1ShVlZ0nVV-- From owner-linux-xfs@oss.sgi.com Sun Jul 14 22:01:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F51fRw022009 for ; Sun, 14 Jul 2002 22:01:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F51eNg022008 for linux-xfs-outgoing; Sun, 14 Jul 2002 22:01:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from promiscuous.dyndns.org (12-248-252-90.client.attbi.com [12.248.252.90]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F51ZRw021979 for ; Sun, 14 Jul 2002 22:01:36 -0700 Received: from dserver (unknown [192.168.1.102]) by promiscuous.dyndns.org (Postfix) with SMTP id 7B8D252E38 for ; Sun, 14 Jul 2002 23:52:49 -0500 (CDT) Message-ID: <000f01c22bbd$5363add0$6601a8c0@dserver> From: "*** Neil ***" To: Subject: GREETINGS Date: Mon, 15 Jul 2002 00:06:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Spam-Status: No, hits=1.9 required=5.0 tests=SUBJ_ALL_CAPS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have tried the new XFS installer iso in linuxiso.org. The version is SGI XFS Filesystem 1.1 Release for Red Hat Linux 7.3 Installer. The installer asked me to insert the disc 1 of Redhat 7.3, and it told me that it's not the correct disk. I have tried my 3 redhat 7.3 disk but all failed. As a result, I just installed Redhat 7.3 directly from the 3 disc. Any ideas why my SGI XFS 1.1 installer fails to see the Redhat 7.3 disk #1? FYI, this is the exact link that I downloaded the installer. http://www.linuxiso.org/download.php/386/RH7.3-SGI-XFS-1.1.iso Thanks. Neil From owner-linux-xfs@oss.sgi.com Sun Jul 14 22:10:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F5AlRw022315 for ; Sun, 14 Jul 2002 22:10:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F5Al8N022314 for linux-xfs-outgoing; Sun, 14 Jul 2002 22:10:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F5AgRw022283 for ; Sun, 14 Jul 2002 22:10:42 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id AAA14217; Mon, 15 Jul 2002 00:15:26 -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 AAA87360; Mon, 15 Jul 2002 00:15:25 -0500 (CDT) Date: Mon, 15 Jul 2002 00:14:34 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Sipos Ferenc cc: linux-xfs@oss.sgi.com Subject: Re: makepkgs log file In-Reply-To: <1026709402.1500.2.camel@zeus.city.tvnet.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a change for this in my workarea; I'll check it in on Monday (tomorrow for me) -Eric On 15 Jul 2002, Sipos Ferenc wrote: > Hi! > > I send the dist.log, it clearly shows that rpm -ba won't work. Note, > that I use the latest rawhide rpms, but sooner or later you have to > change the code, I'm sure. Thx. > > Paco > > > From owner-linux-xfs@oss.sgi.com Sun Jul 14 22:22:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F5MTRw022598 for ; Sun, 14 Jul 2002 22:22:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F5MT9X022597 for linux-xfs-outgoing; Sun, 14 Jul 2002 22:22:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F5MMRw022561 for ; Sun, 14 Jul 2002 22:22:22 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id AAA14317; Mon, 15 Jul 2002 00:27:05 -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 AAA75891; Mon, 15 Jul 2002 00:27:05 -0500 (CDT) Date: Mon, 15 Jul 2002 00:26:13 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: ASANO Masahiro cc: linux-xfs@oss.sgi.com Subject: Re: filesize after H/W fault In-Reply-To: <20020715135555H.masano@tnes.nec.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Masano - You say "linux-2.4.7 and xfs cvs based" - does that mean that it is recent XFS code, ported back to 2.4.7? Or is the xfs code from many months ago? There have been MANY changes in the area of syncing & logging since 2.4.7, so if you are running xfs code from the 2.4.7 days, I would strongly suggest an upgrade. I don't have any specific suggestions on what may have gone wrong, but an upgrade would be a good idea. -Eric On Mon, 15 Jul 2002, ASANO Masahiro wrote: > Hi, > > I have run old xfs on my server machine. The kernel is linux-2.4.7 and > xfs cvs based. This system was working fine for several months without > any xfs related troubles. But a problem happened at last. > > After a hardware fault, some files on xfs were truncated to size > zero. The files were created via nfs v3 several hours before the > hardware fault, and were not overwritten after created. When the > filesystem was mounted at reboot, log recovery was done automatically, > and there was no error. > > I thought file data would be sync'd to disk within minutes after it is > written. What happened? > Any ideas or patches? > > -- > Masano > From owner-linux-xfs@oss.sgi.com Sun Jul 14 22:25:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F5PLRw022796 for ; Sun, 14 Jul 2002 22:25:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F5PLNo022795 for linux-xfs-outgoing; Sun, 14 Jul 2002 22:25:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F5PERw022758 for ; Sun, 14 Jul 2002 22:25:14 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id AAA14017; Mon, 15 Jul 2002 00:29:58 -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 AAA58958; Mon, 15 Jul 2002 00:29:58 -0500 (CDT) Date: Mon, 15 Jul 2002 00:29:07 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: *** Neil *** cc: linux-xfs@oss.sgi.com Subject: Re: GREETINGS In-Reply-To: <000f01c22bbd$5363add0$6601a8c0@dserver> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Neil - Red Hat released updated 7.3 isos, so our installer can't find them anymore. If you'd like to try a patch, get ftp://oss.sgi.com/projects/xfs/download/testing/new_rh_iso-2.xdelta and run: xdelta patch new_rh_iso-2.xdelta and you should have an iso that works. Let me know if it does. ;-) -Eric On Mon, 15 Jul 2002, *** Neil *** wrote: > I have tried the new XFS installer iso in linuxiso.org. The version is SGI > XFS Filesystem 1.1 Release for Red Hat Linux 7.3 Installer. > > The installer asked me to insert the disc 1 of Redhat 7.3, and it told me > that it's not the correct disk. > I have tried my 3 redhat 7.3 disk but all failed. > > As a result, I just installed Redhat 7.3 directly from the 3 disc. > > Any ideas why my SGI XFS 1.1 installer fails to see the Redhat 7.3 disk #1? > > FYI, this is the exact link that I downloaded the installer. > http://www.linuxiso.org/download.php/386/RH7.3-SGI-XFS-1.1.iso > > Thanks. > > Neil > From owner-linux-xfs@oss.sgi.com Sun Jul 14 22:36:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F5aHRw023060 for ; Sun, 14 Jul 2002 22:36:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F5aHib023059 for linux-xfs-outgoing; Sun, 14 Jul 2002 22:36:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F5a9Rw023031 for ; Sun, 14 Jul 2002 22:36:09 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 WAA07149 for ; Sun, 14 Jul 2002 22:40:56 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA29520; Mon, 15 Jul 2002 15:39:37 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) with ESMTP id g6F5cDWQ003183; Mon, 15 Jul 2002 15:38:13 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) id g6F5cCdc003181; Mon, 15 Jul 2002 15:38:12 +1000 Date: Mon, 15 Jul 2002 15:38:12 +1000 From: Nathan Scott To: Sipos Ferenc Cc: linux-xfs@oss.sgi.com Subject: Re: makepkgs log file Message-ID: <20020715053812.GB2353@frodo> References: <1026709402.1500.2.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1026709402.1500.2.camel@zeus.city.tvnet.hu> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jul 15, 2002 at 07:03:22AM +0200, Sipos Ferenc wrote: > Hi! > > I send the dist.log, it clearly shows that rpm -ba won't work. Note, > that I use the latest rawhide rpms, but sooner or later you have to > change the code, I'm sure. Thx. > Thanks, looks like we'll have to fix this. > === rpm === > sed -e's|@pkg_name@|xfsprogs|g' \ > -e's|@pkg_version@|2.0.6|g' \ > -e's|@pkg_release@|0|g' \ > -e's|@pkg_distribution@|SGI XFS|g' \ > -e's|@pkg_builder@|sferi@zeus.city.tvnet.hu|g' \ > -e's|@build_root@|/tmp/21331|g' \ > -e'/^BuildRoot: *$/d' \ > -e's|@pkg_var_dir@||g' \ > -e's|@pkg_share_dir@||g' \ > -e's|@pkg_log_dir@||g' \ > -e's|@pkg_doc_dir@|/usr/share/doc/xfsprogs|g' \ > -e's|@pkg_man_dir@|/usr/share/man|g' \ > -e's|@pkg_tmp_dir@||g' \ > -e's|@make@|/usr/bin/make|g' < xfsprogs.spec.in > xfsprogs.spec > sed -e '/^macrofiles:/s|~/.rpmmacros|rpmmacros|' rpm-4.rc > /bin/rpm -ba --rcfile ./rpm-4.rc xfsprogs.spec > -ba: unknown option > make[1]: *** [dist] Error 1 > Done > make: Leaving directory `/home/sferi/linux-2.4-xfs/cmd/xfsprogs/build' cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jul 14 23:16:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F6GFRw023582 for ; Sun, 14 Jul 2002 23:16:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F6GFUk023581 for linux-xfs-outgoing; Sun, 14 Jul 2002 23:16:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from promiscuous.dyndns.org (12-248-252-90.client.attbi.com [12.248.252.90]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F6G8Rw023551 for ; Sun, 14 Jul 2002 23:16:08 -0700 Received: from dserver (unknown [192.168.1.102]) by promiscuous.dyndns.org (Postfix) with SMTP id A0B7552E38; Mon, 15 Jul 2002 01:07:21 -0500 (CDT) Message-ID: <006201c22bc7$bcffc440$6601a8c0@dserver> From: "*** Neil ***" To: "Eric Sandeen" Cc: References: Subject: Re: GREETINGS Date: Mon, 15 Jul 2002 01:20:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, ----- Original Message ----- From: "Eric Sandeen" To: "*** Neil ***" Cc: Sent: Monday, July 15, 2002 12:29 AM Subject: Re: GREETINGS > If you'd like to try a patch, get > ftp://oss.sgi.com/projects/xfs/download/testing/new_rh_iso-2.xdelta > > and run: > > xdelta patch new_rh_iso-2.xdelta I don't know how to execute this since I downloaded all the isos using my Windows o.s. What is new_rh_iso-2.xdelta? How big is this file? If it's ok, can you send me some instructions please. Thank you very much in advance. Neil From owner-linux-xfs@oss.sgi.com Sun Jul 14 23:35:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F6ZhRw023871 for ; Sun, 14 Jul 2002 23:35:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F6ZhG6023870 for linux-xfs-outgoing; Sun, 14 Jul 2002 23:35:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F6ZXRw023842 for ; Sun, 14 Jul 2002 23:35:33 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6F6eGb6086257; Mon, 15 Jul 2002 08:40:16 +0200 (CEST) Message-Id: <4.3.2.7.2.20020715083631.0361c010@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Jul 2002 08:39:20 +0200 To: Eric Sandeen , ASANO Masahiro From: Seth Mos Subject: Re: filesize after H/W fault Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <20020715135555H.masano@tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 00:26 15-7-2002 -0500, Eric Sandeen wrote: >Hi Masano - > >You say "linux-2.4.7 and xfs cvs based" - does that mean that it is >recent XFS code, ported back to 2.4.7? Or is the xfs code from many >months ago? I believe this to be CVS from that time. >There have been MANY changes in the area of syncing & logging since >2.4.7, so if you are running xfs code from the 2.4.7 days, I would >strongly suggest an upgrade. I don't have any specific suggestions >on what may have gone wrong, but an upgrade would be a good idea. It's not unthinkable that a process already got wedged which caused disk processes to get stuck. I have had similar behaviour with hardware failures and XFS. Thinks like memory and such which is silent corruption untill it's too late. He also didn't mention what hardware part was faulty. Cheers >-Eric > >On Mon, 15 Jul 2002, ASANO Masahiro wrote: > > > Hi, > > > > I have run old xfs on my server machine. The kernel is linux-2.4.7 and > > xfs cvs based. This system was working fine for several months without > > any xfs related troubles. But a problem happened at last. > > > > After a hardware fault, some files on xfs were truncated to size > > zero. The files were created via nfs v3 several hours before the > > hardware fault, and were not overwritten after created. When the > > filesystem was mounted at reboot, log recovery was done automatically, > > and there was no error. > > > > I thought file data would be sync'd to disk within minutes after it is > > written. What happened? > > Any ideas or patches? > > > > -- > > Masano > > -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sun Jul 14 23:53:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F6rLRw024209 for ; Sun, 14 Jul 2002 23:53:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F6rK24024208 for linux-xfs-outgoing; Sun, 14 Jul 2002 23:53:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F6rDRw024167 for ; Sun, 14 Jul 2002 23:53:14 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6F6w1Bo093174; Mon, 15 Jul 2002 08:58:02 +0200 (CEST) Message-Id: <4.3.2.7.2.20020715085155.03963838@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Jul 2002 08:57:04 +0200 To: "*** Neil ***" , "Eric Sandeen" From: Seth Mos Subject: Re: GREETINGS Cc: In-Reply-To: <006201c22bc7$bcffc440$6601a8c0@dserver> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 01:20 15-7-2002 -0500, *** Neil *** wrote: > > If you'd like to try a patch, get > > ftp://oss.sgi.com/projects/xfs/download/testing/new_rh_iso-2.xdelta > > > > and run: > > > > xdelta patch new_rh_iso-2.xdelta > >I don't know how to execute this since I downloaded all the isos using my >Windows o.s. xdelta for windows can be found here. http://www.eng.uwaterloo.ca/~ejones/software/xdelta-win32.html >What is new_rh_iso-2.xdelta? How big is this file? About 23 MB. The instructions from above apply. Just open a dos command prompt and type in the command. You might need to make the names shorter because of dos 8.3 name limitations but nothing will stop you from renaming it after the file is patched. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jul 15 00:22:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F7MBRw024704 for ; Mon, 15 Jul 2002 00:22:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F7MAhT024703 for linux-xfs-outgoing; Mon, 15 Jul 2002 00:22:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from promiscuous.dyndns.org (12-248-252-90.client.attbi.com [12.248.252.90]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F7M1Rw024675 for ; Mon, 15 Jul 2002 00:22:02 -0700 Received: from dserver (unknown [192.168.1.102]) by promiscuous.dyndns.org (Postfix) with SMTP id 7F58B52E71; Mon, 15 Jul 2002 02:13:15 -0500 (CDT) Message-ID: <006c01c22bd0$f1a06d90$6601a8c0@dserver> From: "*** Neil ***" To: "Eric Sandeen" , "Seth Mos" Cc: References: <4.3.2.7.2.20020715085155.03963838@pop.xs4all.nl> Subject: Re: GREETINGS Date: Mon, 15 Jul 2002 02:26:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Seth. I will try that. ----- Original Message ----- From: "Seth Mos" To: "*** Neil ***" ; "Eric Sandeen" Cc: Sent: Monday, July 15, 2002 1:57 AM Subject: Re: GREETINGS > At 01:20 15-7-2002 -0500, *** Neil *** wrote: > > > If you'd like to try a patch, get > > > ftp://oss.sgi.com/projects/xfs/download/testing/new_rh_iso-2.xdelta > > > > > > and run: > > > > > > xdelta patch new_rh_iso-2.xdelta > > > >I don't know how to execute this since I downloaded all the isos using my > >Windows o.s. > > xdelta for windows can be found here. > http://www.eng.uwaterloo.ca/~ejones/software/xdelta-win32.html > > >What is new_rh_iso-2.xdelta? How big is this file? > > About 23 MB. > > The instructions from above apply. > Just open a dos command prompt and type in the command. You might need to > make the names shorter because of dos 8.3 name limitations but nothing will > stop you from renaming it after the file is patched. > > Cheers > -- > Seth > It might just be your lucky day, if you only knew. > > From owner-linux-xfs@oss.sgi.com Mon Jul 15 00:35:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F7ZaRw024947 for ; Mon, 15 Jul 2002 00:35:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F7Zav7024946 for linux-xfs-outgoing; Mon, 15 Jul 2002 00:35:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F7ZRRw024917 for ; Mon, 15 Jul 2002 00:35:28 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g6F7eGe18407 for ; Mon, 15 Jul 2002 16:40:16 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g6F7eFc19439 for ; Mon, 15 Jul 2002 16:40:15 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g6F7eFd00479 for ; Mon, 15 Jul 2002 16:40:15 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA192 for ; Mon, 15 Jul 2002 16:40:13 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Jul 15 16:40:12 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g6F7eCA76216; Mon, 15 Jul 2002 16:40:12 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g6F7eCY03379; Mon, 15 Jul 2002 16:40:12 +0900 To: sandeen@sgi.com, knuffie@xs4all.nl Cc: linux-xfs@oss.sgi.com Subject: Re: filesize after H/W fault In-Reply-To: <4.3.2.7.2.20020715083631.0361c010@pop.xs4all.nl> References: <20020715135555H.masano@tnes.nec.co.jp> <4.3.2.7.2.20020715083631.0361c010@pop.xs4all.nl> X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Honest Recruiter) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020715164012R.masano@tnes.nec.co.jp> Date: Mon, 15 Jul 2002 16:40:12 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 27 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Eric, > You say "linux-2.4.7 and xfs cvs based" - does that mean that it is > recent XFS code, ported back to 2.4.7? Or is the xfs code from many > months ago? Some major issues and many minor changes had been back ported, but not completely. I could not change os version so easy by some reasons. > There have been MANY changes in the area of syncing & logging since > 2.4.7, so if you are running xfs code from the 2.4.7 days, I would > strongly suggest an upgrade. I don't have any specific suggestions > on what may have gone wrong, but an upgrade would be a good idea. Mmm, I agree, but... Thanks Seth, > He also didn't mention what hardware part was faulty. A PCI related problem. This PCI-box has been replaced already and it's fine now. -- Masano From owner-linux-xfs@oss.sgi.com Mon Jul 15 04:01:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FB1XRw028082 for ; Mon, 15 Jul 2002 04:01:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FB1XCZ028081 for linux-xfs-outgoing; Mon, 15 Jul 2002 04:01:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FB1ORw028051 for ; Mon, 15 Jul 2002 04:01:24 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA23130; Mon, 15 Jul 2002 06:06:07 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-25.corp.sgi.com [134.15.64.25]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA24462; Mon, 15 Jul 2002 06:06:06 -0500 (CDT) Subject: Re: filesize after H/W fault From: Stephen Lord To: ASANO Masahiro Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020715135555H.masano@tnes.nec.co.jp> References: <20020715135555H.masano@tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Jul 2002 06:01:25 -0500 Message-Id: <1026730887.1139.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2002-07-14 at 23:55, ASANO Masahiro wrote: > Hi, > > I have run old xfs on my server machine. The kernel is linux-2.4.7 and > xfs cvs based. This system was working fine for several months without > any xfs related troubles. But a problem happened at last. > > After a hardware fault, some files on xfs were truncated to size > zero. The files were created via nfs v3 several hours before the > hardware fault, and were not overwritten after created. When the > filesystem was mounted at reboot, log recovery was done automatically, > and there was no error. > > I thought file data would be sync'd to disk within minutes after it is > written. What happened? > Any ideas or patches? There is one scenario which can cause this: o files are created with data in them, then the filesystem goes idle for a long time o there is a crash Because inode size updates are not transactional, and there was no log activity after the writes to change the log, the tail of the log is still before the create operations. This gets replayed on recovery and the size gets reset. If this theory is correct then you may still have extents in the file with your data in them. There is code in the kernel to deal with this scenario, the xfs_sync path will push an extra record into the log on an idle filesystem, but it depends on write_super getting called correctly. This will move the tail of the log forwards and prevent the replay of the old transactions. Steve > > -- > Masano From owner-linux-xfs@oss.sgi.com Mon Jul 15 04:41:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FBfcRw028834 for ; Mon, 15 Jul 2002 04:41:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FBfcmM028833 for linux-xfs-outgoing; Mon, 15 Jul 2002 04:41:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta04.algx.net (chimta04.algx.net [216.99.233.79]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FBfQRw028805 for ; Mon, 15 Jul 2002 04:41:27 -0700 Received: from wiley.ceo.com (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx04.algx.net (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with ESMTP id <0GZA00FQ5GORM3@chimmx04.algx.net> for linux-xfs@oss.sgi.com; Mon, 15 Jul 2002 06:46:03 -0500 (CDT) Date: Mon, 15 Jul 2002 07:46:02 -0400 From: Danny Cox Subject: Re: kernel BUG at buffer.c In-reply-to: <1662520654.20020715082500@avtodor.gorny.ru> To: =?koi8-r?Q?=F3=CF=CB=CF=CC=CF=D7_?= =?koi8-r?Q?=F3=C5=D2=C7=C5=CA?= Cc: XFS Mailing List Message-id: <1026733563.1151.8.camel@wiley> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain; charset=koi8-r References: <1662520654.20020715082500@avtodor.gorny.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6FBfRRw028806 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sergei, On Sun, 2002-07-14 at 21:25, óÏËÏÌÏ× óÅÒÇÅÊ wrote: > Hello! > I have linux kernel 2.4.19-rc1 with xfs enabled. > My xfs partition locate on /dev/ataraid device (Promise FastTrak Tx4). > I have two problems: > > 1) [root@ws188 linux-2.4.19-rc1-xfs]# mkfs.xfs /dev/ataraid/d1p2 > mkfs.xfs: warning - cannot set blocksize on block device /dev/ataraid/d1p2: Invalid argument > > 2)When i copying files between partitions, I receive message. > > Jul 12 17:01:19 ws188 kernel: kernel BUG at buffer.c:549! > Jul 12 17:01:19 ws188 kernel: invalid operand: 0000 > Jul 12 17:01:19 ws188 kernel: CPU: 0 > Jul 12 17:01:19 ws188 kernel: EIP: 0010:[__insert_into_lru_list+37/112] Not tainted > Jul 12 17:01:19 ws188 kernel: EIP: 0010:[] Not tainted > Jul 12 17:01:19 ws188 kernel: EFLAGS: 00010206 > Jul 12 17:01:19 ws188 kernel: eax: 00000000 ebx: 00000008 ecx: d6e297c0 edx: c02ec594 > Jul 12 17:01:19 ws188 kernel: esi: 00000002 edi: 00001000 ebp: 00000000 esp: df0ebe18 > Jul 12 17:01:19 ws188 kernel: ds: 0018 es: 0018 ss: 0018 > Jul 12 17:01:19 ws188 kernel: Process mc (pid: 872, stackpage=df0eb000) > Jul 12 17:01:19 ws188 kernel: Stack: 00000002 d6e297c0 c012fb64 d6e297c0 00000002 d6e297c0 00001000 c012fb7a > Jul 12 17:01:19 ws188 kernel: d6e297c0 c01305a5 d6e297c0 00000000 d09b22c0 484cc000 00000000 d6e297c0 > Jul 12 17:01:19 ws188 kernel: c0130c56 d09b22c0 c10acf20 00000000 00001000 00001000 00001000 00000000 > Jul 12 17:01:19 ws188 kernel: Call Trace: [__refile_buffer+84/96] [refile_buffer+10/16] [__block_commit_write+ > 117/192] [generic_commit_write+54/96] [pagebuf_generic_file_write+613/768] > Jul 12 17:01:19 ws188 kernel: Call Trace: [] [] [] [] [] > Jul 12 17:01:19 ws188 kernel: [xfs_write+1032/1808] [linvfs_pb_bmap+0/208] [linvfs_write+812/864] [sys_writ > e+150/240] [system_call+51/56] > Jul 12 17:01:19 ws188 kernel: [] [] [] [] [] > Jul 12 17:01:19 ws188 kernel: > Jul 12 17:01:19 ws188 kernel: Code: 0f 0b 25 02 60 9e 26 c0 8b 02 85 c0 75 07 89 0a 89 49 24 8b I've seen this type of bug before. Then, it was an inappropriate interaction between XFS and fs.h macros. XFS uses it's pagebuf routines to perform I/O, and pagebuf allocates it's own buffer headers. When certain macros are called, they not only set/reset bits, but they also remove the bh from one list, and add it to another. Since these bhs belong to XFS/pagebuf alone, this leads to problems. __refile_buffer does just this sort of action with bhs. See the macro 'mark_buffer_clean' in linux/include/linux/fs.h for an example. If you have the source to the ataraid driver, you want to make sure that it avoids any calls that eventually call refile_buffer, because these buffers belong to XFS, and should not appear on any of buffer.c's LRU lists. Hope this helps! -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Mon Jul 15 08:56:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FFu1Rw003789 for ; Mon, 15 Jul 2002 08:56:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FFu1GL003786 for linux-xfs-outgoing; Mon, 15 Jul 2002 08:56:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FFrmRw003704 for ; Mon, 15 Jul 2002 08:53:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA84141 for ; Mon, 15 Jul 2002 10:58:35 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA65128 for ; Mon, 15 Jul 2002 10:58:35 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6FFqmM28440; Mon, 15 Jul 2002 10:52:48 -0500 Message-Id: <200207151552.g6FFqmM28440@jen.americas.sgi.com> Date: Mon, 15 Jul 2002 10:52:48 -0500 Subject: TAKE - merge recent 2.4 changes into 2.5 tree To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A large number of mods just went into the 2.5 code base Steve ------ remove unneeded locking implementation from dmapi Date: Mon Jul 8 13:03:55 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122496a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122496a linux/fs/xfs/support/sv.h - 1.8 linux/fs/xfs_dmapi/Makefile - 1.5 linux/fs/xfs_dmapi/sv.c - 1.2 linux/fs/xfs_dmapi/sv.h - 1.2 - Merge of 2.4.x-xfs:slinx:122496a by lord. Subject: TAKE - Date: Mon Jul 8 13:11:15 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: sandeen Merged by: lord Merged mods: 2.4.x-xfs:slinx:122557a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122557a linux/fs/xfs/xfs_inode.c - 1.343 - Merge of 2.4.x-xfs:slinx:122557a by lord. Don't let CAP_DAC_OVERRIDE override if no execute bits are set other minor cleanup in xfs_iaccess() Subject: TAKE - Date: Mon Jul 8 20:18:37 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122661a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122661a linux/fs/xfs/xfs_vnodeops.c - 1.533 - Merge of 2.4.x-xfs:slinx:122661a by lord. Add an iflush call which will initiate an inode flush to disk if it can, otherwise return EAGAIN. linux/fs/xfs/xfs_trans.c - 1.131 - Merge of 2.4.x-xfs:slinx:122661a by lord. Mark the super block dirty after a transaction linux/fs/xfs/linux/xfs_super.c - 1.200 - Merge of 2.4.x-xfs:slinx:122661a by lord. change write_inode method to call into VOP_IFLUSH linux/fs/xfs/linux/xfs_iops.c - 1.159 - Merge of 2.4.x-xfs:slinx:122661a by lord. remove unneeded inode field updates, make more use of mark_inode_dirty linux/fs/xfs/linux/xfs_vnode.h - 1.45 - Merge of 2.4.x-xfs:slinx:122661a by lord. add VOP_IFLUSH Subject: TAKE - Date: Mon Jul 8 20:27:40 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122666a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122666a linux/fs/xfs/xfs_rw.h - 1.65 linux/fs/xfs/xfs_rw.c - 1.361 linux/fs/xfs/xfs_vnodeops.c - 1.534 linux/fs/xfs/xfs_dfrag.c - 1.31 - Merge of 2.4.x-xfs:slinx:122666a by lord. changes xfs_inval_cached_pages interface linux/fs/xfs/linux/xfs_lrw.c - 1.150 - Merge of 2.4.x-xfs:slinx:122666a by lord. move pagebuf_iozero here, relocate xfs stats here, change xfs_inval_cached_pages interface linux/fs/xfs/linux/xfs_file.c - 1.68 - Merge of 2.4.x-xfs:slinx:122666a by lord. move xfs stats into xfs linux/fs/xfs/pagebuf/page_buf_io.c - 1.41 linux/fs/xfs/pagebuf/page_buf.h - 1.26 - Merge of 2.4.x-xfs:slinx:122666a by lord. remove pagebuf_iozero from here Subject: TAKE - Date: Tue Jul 9 13:02:50 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122679a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122679a linux/mm/filemap.c - 1.124 - Merge of 2.4.x-xfs:slinx:122679a by lord. break generic_file_write apart for use by xfs. Fix direct read end of file handling. linux/include/linux/fs.h - 1.179 - Merge of 2.4.x-xfs:slinx:122679a by lord. prototype for do_generic_file_write linux/fs/xfs/xfs_dmapi.c - 1.69 - Merge of 2.4.x-xfs:slinx:122679a by lord. Get max direct I/O size from a different place linux/fs/xfs/linux/xfs_lrw.c - 1.151 - Merge of 2.4.x-xfs:slinx:122679a by lord. replace call to pagebuf_generic_file_write with do_generic_file_write. linux/fs/xfs/linux/xfs_file.c - 1.69 - Merge of 2.4.x-xfs:slinx:122679a by lord. since we now call the generic write path in xfs remove the checks here which duplicate its functionality. Grab the i_sem lock in the non O_DIRECT case, we need it in the vmtruncate call out of do_generic_file_write. linux/fs/xfs/linux/xfs_iops.c - 1.160 - Merge of 2.4.x-xfs:slinx:122679a by lord. Add a truncate operation, change setattr to use vmtruncate and not call inode_setattr linux/fs/xfs/linux/xfs_ioctl.c - 1.72 - Merge of 2.4.x-xfs:slinx:122679a by lord. Get max direct I/O size from a different place linux/fs/xfs/pagebuf/page_buf_io.c - 1.42 - Merge of 2.4.x-xfs:slinx:122679a by lord. remove write path linux/fs/xfs/pagebuf/page_buf.c - 1.36 - Merge of 2.4.x-xfs:slinx:122679a by lord. leave pages locked when reading it in. linux/fs/xfs/pagebuf/page_buf.h - 1.27 - Merge of 2.4.x-xfs:slinx:122679a by lord. remove prototypes linux/fs/xfs/pagebuf/page_buf_internal.h - 1.11 - Merge of 2.4.x-xfs:slinx:122679a by lord. remove direct I/O config option Subject: TAKE - Date: Tue Jul 9 13:06:49 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122727a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122727a linux/fs/xfs/xfs_log_recover.c - 1.237 - Merge of 2.4.x-xfs:slinx:122727a by lord. when allocating a buffer for recovery reading the log, use a power of 2 Subject: TAKE - Date: Tue Jul 9 13:10:40 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122683a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122683a linux/fs/xfs/linux/xfs_vnode.c - 1.89 - Merge of 2.4.x-xfs:slinx:122683a by lord. small cleanup in generation number code Subject: TAKE - Date: Tue Jul 9 13:13:48 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122684a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122684a linux/fs/xfs/linux/xfs_lrw.c - 1.152 - Merge of 2.4.x-xfs:slinx:122684a by lord. rename pagebuf_iozero to xfs_iozero and change error sign to be positive Subject: TAKE - update command version number info Date: Tue Jul 9 13:18:11 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122685a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122685a linux/Documentation/Changes - 1.53 - Merge of 2.4.x-xfs:slinx:122685a by lord. Subject: TAKE - Date: Tue Jul 9 13:48:37 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: sandeen Merged by: lord Merged mods: 2.4.x-xfs:slinx:122728a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122728a linux/fs/xfs/xfs_bmap.h - 1.77 linux/fs/xfs/xfs_bmap.c - 1.285 - Merge of 2.4.x-xfs:slinx:122728a by lord. Change xfs_bmalloca_t to use chars instead of ints to reduce stack usage; fix up associated functions. linux/fs/xfs/linux/xfs_super.c - 1.201 - Merge of 2.4.x-xfs:slinx:122728a by lord. Ease up on stack; allocate xfs_args struct for linvfs_read_super and linvfs_remount Subject: TAKE - Date: Mon Jul 15 04:24:01 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122739a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122739a linux/fs/xfs/linux/xfs_iops.c - 1.162 - Merge of 2.4.x-xfs:slinx:122739a by lord. remove some page zeroing from the read path of getblock. Subject: TAKE - only include iobuf.h where needed Date: Mon Jul 15 04:41:22 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122766a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122766a linux/fs/xfs/linux/xfs_iops.c - 1.163 linux/fs/xfs/linux/xfs_ioctl.c - 1.74 linux/fs/xfs/pagebuf/page_buf.h - 1.29 - Merge of 2.4.x-xfs:slinx:122766a by lord. Subject: TAKE - use unlock_page instead of UnlockPage Date: Mon Jul 15 05:05:41 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122767a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122767a linux/fs/xfs/linux/xfs_lrw.c - 1.155 linux/fs/xfs/linux/xfs_iops.c - 1.164 linux/fs/xfs/pagebuf/page_buf_io.c - 1.44 linux/fs/xfs/pagebuf/page_buf.c - 1.38 - Merge of 2.4.x-xfs:slinx:122767a by lord. Subject: TAKE - do not pass file->f_flags into check frozen Date: Mon Jul 15 05:07:56 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122768a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122768a linux/fs/xfs/linux/xfs_lrw.c - 1.156 - Merge of 2.4.x-xfs:slinx:122768a by lord. Subject: TAKE - do not pass cwd into rmdir Date: Mon Jul 15 05:20:08 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122770a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122770a linux/fs/xfs/xfs_vnodeops.c - 1.536 linux/fs/xfs/linux/xfs_iops.c - 1.165 linux/fs/xfs/linux/xfs_vnode.h - 1.47 - Merge of 2.4.x-xfs:slinx:122770a by lord. Subject: TAKE - rearrange dmapi mmap event trigger Date: Mon Jul 15 05:31:56 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: roehrich Merged by: lord Merged mods: 2.4.x-xfs:slinx:122771a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122771a linux/mm/mprotect.c - 1.27 - Merge of 2.4.x-xfs:slinx:122771a by lord. Remove call to f_op->dmapi_map_event(). Add call to f_op->mprotect(). linux/include/linux/fs.h - 1.181 - Merge of 2.4.x-xfs:slinx:122771a by lord. Remove dmapi_map_event from file_operations. Add mprotect to file_operations. linux/fs/xfs/xfs_dmapi.h - 1.27 - Merge of 2.4.x-xfs:slinx:122771a by lord. xfs_dmapi_mmap_event() prototype linux/fs/xfs/xfs_dmapi.c - 1.71 - Merge of 2.4.x-xfs:slinx:122771a by lord. Add xfs_dmapi_mmap_event(). This is the reincarnation of linvfs_dmapi_map_event(). linux/fs/xfs/linux/xfs_dmistubs.c - 1.18 - Merge of 2.4.x-xfs:slinx:122771a by lord. xfs_dmapi_mmap_event() stub linux/fs/xfs/linux/xfs_file.c - 1.71 - Merge of 2.4.x-xfs:slinx:122771a by lord. Remove linvfs_dmapi_map_event(). Add linvfs_mprotect(). Change linvfs_generic_file_mmap() to check for dmapi permission _before_ doing the generic_file_mmap()...not much point in doing it after. Subject: TAKE - add iobuf.h to xfs_dmapi.c Date: Mon Jul 15 05:34:45 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: roehrich Merged by: lord Merged mods: 2.4.x-xfs:slinx:122778a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122778a linux/fs/xfs/xfs_dmapi.c - 1.72 - Merge of 2.4.x-xfs:slinx:122778a by lord. add iobuf.h Subject: TAKE - dmapi: introduce vnode ptr into dm_tokdata_t This is the first of a series of patches to get the dmapi core to use bhv's and bhv locks correctly. These patches are being carried over from work currently going on for Irix, in PV 860655. Date: Mon Jul 15 05:36:23 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: roehrich Merged by: lord Merged mods: 2.4.x-xfs:slinx:122813a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122813a linux/fs/xfs_dmapi/dmapi_right.c - 1.7 linux/fs/xfs_dmapi/dmapi_private.h - 1.13 linux/fs/xfs_dmapi/dmapi_event.c - 1.6 - Merge of 2.4.x-xfs:slinx:122813a by lord. No Message Supplied Subject: TAKE - dmapi: Change VN_HOLD/VN_RELE/iput to use the new vnode pointer Date: Mon Jul 15 05:59:47 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: roehrich Merged by: lord Merged mods: 2.4.x-xfs:slinx:122818a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122818a linux/fs/xfs_dmapi/dmapi_right.c - 1.8 - Merge of 2.4.x-xfs:slinx:122818a by lord. Change VN_HOLD/VN_RELE to use the new vnode pointer. Subject: TAKE - dmapi: change dm_fsys_vector to use new vnode pointer Date: Mon Jul 15 06:02:53 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: roehrich Merged by: lord Merged mods: 2.4.x-xfs:slinx:122821a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122821a linux/fs/xfs_dmapi/dmapi_right.c - 1.9 linux/fs/xfs_dmapi/dmapi_register.c - 1.19 linux/fs/xfs_dmapi/dmapi_region.c - 1.3 linux/fs/xfs_dmapi/dmapi_private.h - 1.14 linux/fs/xfs_dmapi/dmapi_mountinfo.c - 1.7 linux/fs/xfs_dmapi/dmapi_io.c - 1.3 linux/fs/xfs_dmapi/dmapi_hole.c - 1.3 linux/fs/xfs_dmapi/dmapi_handle.c - 1.3 linux/fs/xfs_dmapi/dmapi_event.c - 1.7 linux/fs/xfs_dmapi/dmapi_dmattr.c - 1.3 linux/fs/xfs_dmapi/dmapi_config.c - 1.4 linux/fs/xfs_dmapi/dmapi_bulkattr.c - 1.3 linux/fs/xfs_dmapi/dmapi_attr.c - 1.3 - Merge of 2.4.x-xfs:slinx:122821a by lord. No Message Supplied Subject: TAKE - rework mprotect handling (again) Patch from Christoph Hellwig. Summary: * ->mprotect is not an operation on the fd but the vma, make it a VM operation instead of file operation * remove file argument from ->mprotect - it's always vma->vm_file * define HAVE_VMOP_MPROTECT and make ->mprotect conditional on it * simplify ->mmap, calling generic_file_mmap is pointless. * rename linvfs_generic_file_mmap to linvfs_file_mmap * add missing externs in xfs_dmapi.h Date: Mon Jul 15 06:17:41 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: roehrich Merged by: lord Merged mods: 2.4.x-xfs:slinx:122842a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122842a linux/mm/mprotect.c - 1.28 linux/include/linux/mm.h - 1.91 linux/include/linux/fs.h - 1.182 linux/fs/xfs/xfs_dmapi.h - 1.28 linux/fs/xfs/xfs_dmapi.c - 1.73 linux/fs/xfs/linux/xfs_dmistubs.c - 1.19 linux/fs/xfs/linux/xfs_file.c - 1.72 - Merge of 2.4.x-xfs:slinx:122842a by lord. Subject: TAKE - dmapi: add bhv locking at top of fsys_vector calls Date: Mon Jul 15 06:27:44 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: roehrich Merged by: lord Merged mods: 2.4.x-xfs:slinx:122845a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122845a linux/fs/xfs_dmapi/dmapi_right.c - 1.10 linux/fs/xfs_dmapi/dmapi_register.c - 1.20 linux/fs/xfs_dmapi/dmapi_region.c - 1.4 linux/fs/xfs_dmapi/dmapi_io.c - 1.4 linux/fs/xfs_dmapi/dmapi_hole.c - 1.4 linux/fs/xfs_dmapi/dmapi_handle.c - 1.4 linux/fs/xfs_dmapi/dmapi_dmattr.c - 1.4 linux/fs/xfs_dmapi/dmapi_config.c - 1.5 linux/fs/xfs_dmapi/dmapi_bulkattr.c - 1.4 linux/fs/xfs_dmapi/dmapi_attr.c - 1.4 - Merge of 2.4.x-xfs:slinx:122845a by lord. Subject: TAKE - clean up the check frozen interface Date: Mon Jul 15 06:32:21 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122847a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122847a linux/fs/xfs/xfs_mount.h - 1.147 linux/fs/xfs/xfs_mount.c - 1.293 linux/fs/xfs/xfs_trans.c - 1.133 linux/fs/xfs/xfs_fsops.c - 1.81 linux/fs/xfs/linux/xfs_lrw.c - 1.157 - Merge of 2.4.x-xfs:slinx:122847a by lord. Subject: TAKE - fix comment Date: Mon Jul 15 06:54:45 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122850a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122850a linux/fs/xfs/xfs_mount.c - 1.294 - Merge of 2.4.x-xfs:slinx:122850a by lord. Subject: TAKE - remove VOP_CLOSE Date: Mon Jul 15 06:59:38 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122851a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122851a linux/fs/xfs/xfs_vnodeops.c - 1.537 linux/fs/xfs/linux/xfs_vnode.h - 1.48 - Merge of 2.4.x-xfs:slinx:122851a by lord. Subject: TAKE - rationalize mount arguments Date: Mon Jul 15 07:06:30 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122852a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122852a linux/fs/xfs/xfs_vfsops.c - 1.358 linux/fs/xfs/xfs_clnt.h - 1.32 linux/fs/xfs/xfs_mount.h - 1.148 linux/fs/xfs/linux/xfs_super.c - 1.203 linux/fs/xfs/linux/xfs_vfs.h - 1.21 - Merge of 2.4.x-xfs:slinx:122852a by lord. Subject: TAKE - change ih_lock to an read/write spin lock Date: Mon Jul 15 07:08:41 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122855a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122855a linux/fs/xfs/xfs_vnodeops.c - 1.538 linux/fs/xfs/xfs_iget.c - 1.165 linux/fs/xfs/xfs_inode.h - 1.163 - Merge of 2.4.x-xfs:slinx:122855a by lord. Subject: TAKE - Date: Mon Jul 15 08:12:47 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122857a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122857a linux/fs/xfs/pagebuf/page_buf_locking.c - 1.19 - Merge of 2.4.x-xfs:slinx:122857a by lord. Do determination of allowed request layouts at mount time rather than at request time. Probably about a million less tests this way. linux/fs/xfs/pagebuf/page_buf.c - 1.39 - Merge of 2.4.x-xfs:slinx:122857a by lord. More cleanup of page locking during read, also rationalize the code in the I/O path which understands the layour restrictions of specific device types. linux/fs/xfs/pagebuf/page_buf.h - 1.30 - Merge of 2.4.x-xfs:slinx:122857a by lord. add new flags field to pb_target structure Subject: TAKE - remove VOP_FCNTL - unused Date: Mon Jul 15 08:15:31 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122860a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122860a linux/fs/xfs/linux/xfs_vnode.h - 1.49 - Merge of 2.4.x-xfs:slinx:122860a by lord. Subject: TAKE - remove unused variables Date: Mon Jul 15 08:17:09 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122861a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122861a linux/fs/xfs/xfs_iget.c - 1.166 - Merge of 2.4.x-xfs:slinx:122861a by lord. Subject: TAKE - code shrink the create/mkdir/mknod path Date: Mon Jul 15 08:19:29 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122863a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122863a linux/fs/xfs/linux/xfs_iops.c - 1.166 linux/fs/xfs/linux/xfs_vnode.h - 1.50 - Merge of 2.4.x-xfs:slinx:122863a by lord. Subject: TAKE - fix snafu in last change Date: Mon Jul 15 08:21:58 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122873a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122873a linux/fs/xfs/linux/xfs_iops.c - 1.167 - Merge of 2.4.x-xfs:slinx:122873a by lord. Subject: TAKE - Date: Mon Jul 15 08:24:49 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122932a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122932a linux/fs/xfs/xfsidbg.c - 1.192 linux/fs/xfs/xfs_vnodeops.c - 1.539 - Merge of 2.4.x-xfs:slinx:122932a by lord. remove XFS_BIG_FILES ifdefs linux/fs/xfs/xfs_bmap_btree.h - 1.52 - Merge of 2.4.x-xfs:slinx:122932a by lord. Remove ifdefs for BMBT_USE_64 linux/fs/xfs/xfs_bmap_btree.c - 1.124 - Merge of 2.4.x-xfs:slinx:122932a by lord. Remove ifdefs for BMBT_USE_64 and XFS_LARGE_FILES, optimize a lot of endian conversion in the btree code linux/fs/xfs/xfs_dir2_sf.c - 1.29 - Merge of 2.4.x-xfs:slinx:122932a by lord. Fix debug build with XFS_BIG_FILESYSTEMS off linux/fs/xfs/xfs_inode.h - 1.164 - Merge of 2.4.x-xfs:slinx:122932a by lord. remove XFS_BIG_FILES ifdefs linux/fs/xfs/xfs_types.h - 1.59 - Merge of 2.4.x-xfs:slinx:122932a by lord. Remove XFS_BIG_FILES and set XFS_BIG_FILESYSTEMS to 0 linux/fs/xfs/xfs_bmap.c - 1.287 - Merge of 2.4.x-xfs:slinx:122932a by lord. Remove ifdefs for BMBT_USE_64 Subject: TAKE - fix compiler warnings Date: Mon Jul 15 08:28:16 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122953a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122953a linux/fs/xfs/xfs_rtalloc.c - 1.75 - Merge of 2.4.x-xfs:slinx:122953a by lord. Subject: TAKE - xfs does export symbols Date: Mon Jul 15 08:30:55 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122954a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122954a linux/fs/xfs/linux/xfs_super.c - 1.204 - Merge of 2.4.x-xfs:slinx:122954a by lord. Subject: TAKE - kill get_current_cred() Date: Mon Jul 15 08:34:59 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122955a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122955a linux/fs/xfs/xfs_dmapi.c - 1.74 linux/fs/xfs/linux/xfs_file.c - 1.73 linux/fs/xfs/linux/xfs_vnode.c - 1.91 linux/fs/xfs/linux/xfs_cred.h - 1.20 linux/fs/xfs/linux/xfs_ioctl.c - 1.75 linux/fs/xfs/xfs_acl.c - 1.31 linux/fs/xfs/xfs_cap.c - 1.5 - Merge of 2.4.x-xfs:slinx:122955a by lord. Subject: TAKE - Date: Mon Jul 15 08:40:01 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122956a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122956a linux/fs/xfs/xfs_vnodeops.c - 1.540 - Merge of 2.4.x-xfs:slinx:122956a by lord. remove xfs_allocstore and a call to vop_realvp linux/fs/xfs/xfs_dir.c - 1.138 - Merge of 2.4.x-xfs:slinx:122956a by lord. unneeded cell_capable ifdef linux/fs/xfs/xfs_iocore.c - 1.32 - Merge of 2.4.x-xfs:slinx:122956a by lord. remove xfs_checklock call linux/fs/xfs/xfs_mount.h - 1.149 - Merge of 2.4.x-xfs:slinx:122956a by lord. remove xfs_checklock from iocore linux/fs/xfs/xfs_dir2.c - 1.35 - Merge of 2.4.x-xfs:slinx:122956a by lord. unneeded cell_capable ifdef linux/fs/xfs/linux/xfs_fs_subr.c - 1.34 - Merge of 2.4.x-xfs:slinx:122956a by lord. remove fs_vnode_change and symbol exports linux/fs/xfs/linux/xfs_vnode.h - 1.51 - Merge of 2.4.x-xfs:slinx:122956a by lord. allocstore and realvp removed linux/fs/xfs/linux/xfs_fs_subr.h - 1.8 - Merge of 2.4.x-xfs:slinx:122956a by lord. remove fs_vnode_change prototype Subject: TAKE - debug build fix Date: Mon Jul 15 08:42:46 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:122962a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122962a linux/fs/xfs/xfs_fs.h - 1.1 linux/fs/xfs/xfs_dir2_sf.c - 1.30 - Merge of 2.4.x-xfs:slinx:122962a by lord. Subject: TAKE - Date: Mon Jul 15 08:51:46 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Merged by: lord Merged mods: 2.4.x-xfs:slinx:122963a,2.4.x-xfs:slinx:122969a,2.4.x-xfs:slinx:122970a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:123014a linux/fs/xfs/linux/xfs_linux.h - 1.80 - Merge of 2.4.x-xfs:slinx:122970a originally by lord on 07/12/02 move dmapi includes out of here linux/include/linux/xfs_fs.h - 1.36 - Merge of 2.4.x-xfs:slinx:122963a originally by lord on 07/12/02 move xfs_fs.h linux/fs/xfs/xfs.h - 1.26 - Merge of 2.4.x-xfs:slinx:122969a originally by lord on 07/12/02 include xfs_fs.h here linux/fs/xfs/pagebuf/page_buf.c - 1.40 - Merge of 2.4.x-xfs:slinx:122963a originally by lord on 07/12/02 move xfs_fs.h Subject: TAKE - Date: Mon Jul 15 08:54:54 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: nathans Merged by: lord Merged mods: 2.4.x-xfs:slinx:122997a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122997a linux/fs/xfs/xfs_types.h - 1.60 - Merge of 2.4.x-xfs:slinx:122997a by lord. allow setting for XFS_BIG_FILESYSTEMS to come in from the Makefile. Subject: TAKE - remove xfs_rsync_fn, not used Date: Mon Jul 15 08:57:48 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: 2.4.x-xfs:slinx:123003a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:123003a linux/fs/xfs/xfs_iocore.c - 1.33 - Merge of 2.4.x-xfs:slinx:123003a by lord. From owner-linux-xfs@oss.sgi.com Mon Jul 15 09:26:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FGQGRw004764 for ; Mon, 15 Jul 2002 09:26:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FGQGik004763 for linux-xfs-outgoing; Mon, 15 Jul 2002 09:26:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.rjmx.net (root@khufu.ne.client2.attbi.com [24.91.146.150]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FGQ9Rw004734 for ; Mon, 15 Jul 2002 09:26:10 -0700 Received: from khufu.rjmx.net (ron@khufu.rjmx.net [192.168.1.2]) by mail.rjmx.net (8.12.3/8.12.3) with ESMTP id g6FGUxmr013719 for ; Mon, 15 Jul 2002 12:30:59 -0400 Date: Mon, 15 Jul 2002 12:30:59 -0400 Message-ID: <87it3hhs1o.wl@khufu.rjmx.net> From: Ron Murray To: linux-xfs@oss.sgi.com Subject: XFS 1.1 and pre-emptible kernel??? User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) Reply-To: rjmx@rjmx.net MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=0.9 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm running a 2.4.18 kernel with XFS 1.1 and the pre-emptible kernel patch. If I create an XFS filesystem on /var, any process I run on the machine runs ok (as far as I can tell), but gives a exited with preempt_count x error on exit (where x > 1). Some digging at google turned up a suggestion that the XFS developers were aware of the problem, and that it had been fixed in CVS (this some time in early April), although nothing shows up in a search of this mailing list. I'd rather not try the current CVS version of XFS (don't trust pre-release kernels!), but I'm curious to see if it's been fixed (and I can wait till the official 2.4.19 kernel release and XFS patches). Is it better now? .....Ron -- Ron Murray (rjmx@rjmx.net) http://www.rjmx.net/~ron GPG Public Key Fingerprint: F2C1 FC47 5EF7 0317 133C D66B 8ADA A3C4 D86C 74DE From owner-linux-xfs@oss.sgi.com Mon Jul 15 09:33:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FGXdRw004966 for ; Mon, 15 Jul 2002 09:33:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FGXdgB004965 for linux-xfs-outgoing; Mon, 15 Jul 2002 09:33:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from strike.wu-wien.ac.at (strike.wu-wien.ac.at [137.208.8.200]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FGXNRw004937 for ; Mon, 15 Jul 2002 09:33:24 -0700 Received: from strike.wu-wien.ac.at (ariel.wu-wien.ac.at [137.208.89.100]) by strike.wu-wien.ac.at (8.11.6/8.11.6) with ESMTP id g6FGc5M06490; Mon, 15 Jul 2002 18:38:05 +0200 Message-ID: <3D32FA6F.2010402@strike.wu-wien.ac.at> Date: Mon, 15 Jul 2002 18:38:07 +0200 From: Alexander Bergolth User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: de-at, de-de, de, en, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS hangs when creating large files X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I've recently upgraded my box to from the XFS enabled version of Redhat 7.2 to XFS-RH 7.3. Additionally I'm using the openafs-client (1.2.3 and 1.2.5). (The AFS-Cache is not an XFS-Filesystem.) Since the upgrade, I'm expiriencing hanging processes when creating large files (around 700 MB): A command like head -c 700000000 /dev/zero > testfile hangs after having written the last byte. Other processes that try to access the same file are blocking too. (testfile resides in an XFS-Filesystem.) I've been able to reproduce the system on several machines running kernel-2.4.18-4SGI_XFS_1.1 and openafs-1.2.5-rh7.3.1. Using kernel-2.4.9-21SGI_XFS_1.0.2 and openafs-1.2.3-rh7.2.2 didn't show the problem. The Call Trace of the hanging process always looks like that: [] truncate_list_pages [kernel] 0x1f6 [] truncate_inode_pages [kernel] 0x3b [] xfs_itruncate_start [kernel] 0x74 [] xfs_inactive_free_eofblocks [kernel] 0x1c4 [] xfs_release [kernel] 0x97 [] linvfs_release [kernel] 0x20 [] fput [kernel] 0x4d [] filp_close [kernel] 0x53 [] sys_close [kernel] 0x43 [] system_call [kernel] 0x33 Additional information about the system and three test runs is avaliable at http://leo.kloburg.at/xfs-afs/ I've also made the following observations: *) The problem appears only in conjunction with the afs daemon. *) Loading the AFS-Kernel Module is not enough to hang the process. *) Only when afsd is running, processes that create lange files will hang. *) Once you stop the daemon, hanging processes will return. *) The call trace of one afsd-Process always contains some xfs_ functions when the problem occurs, e.g. afsd S C0358000 72 1153 1 1154 (NOTLB) Call Trace: [] schedule_timeout [kernel] 0x14 [] ll_copy_to_user [kernel] 0x38 [] wait_for_packet [kernel] 0xe6 [] skb_recv_datagram [kernel] 0xb0 [] udp_recvmsg [kernel] 0x59 [] __make_request [kernel] 0x25c [] inet_recvmsg [kernel] 0x39 [] sock_recvmsg [kernel] 0x31 [] xfs_bmbt_get_state [kernel] 0x25 [] xfs_bmap_do_search_extents [kernel] 0x348 [] osi_NetReceive [libafs-2.4.18-4SGI_XFS_1.1-i686] 0xbd [] xfs_bmap_search_extents [kernel] 0x48 [] __wake_up [kernel] 0x32 [] afs_osi_Wakeup [libafs-2.4.18-4SGI_XFS_1.1-i686] 0xe [] rxi_AllocDataBuf [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x2d [] rxk_ReadPacket [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x95 [] rxk_Listener [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x6e [] afs_syscall_call [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x15e [] afs_RX_Running [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x0 [] xfs_bmbt_get_state [kernel] 0x25 [] xfs_bmap_do_search_extents [kernel] 0x2b6 [] xfs_bmap_search_extents [kernel] 0x48 [] xfs_bmapi [kernel] 0x34b [] ide_dmaproc [kernel] 0x1ec [] generic_unplug_device [kernel] 0x1e [] filemap_nopage [kernel] 0xbc [] __alloc_pages [kernel] 0x75 [] page_remove_rmap [kernel] 0x5d [] do_wp_page [kernel] 0x229 [] handle_mm_fault [kernel] 0x106 [] do_page_fault [kernel] 0x12a [] afs_syscall [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x10b [] sys_setpriority [kernel] 0x60 [] system_call [kernel] 0x33 Can anybody help to find out what's going on? Any hints are greatly appreciated, --leo ----------------------------------------------------------------------- Alexander (Leo) Bergolth leo@leo.wu-wien.ac.at WU-Wien - Zentrum fuer Informatikdienste http://leo.wu-wien.ac.at Computers are like air conditioners - they stop working properly when you open Windows From owner-linux-xfs@oss.sgi.com Mon Jul 15 09:35:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FGZ6Rw005108 for ; Mon, 15 Jul 2002 09:35:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FGZ6WZ005107 for linux-xfs-outgoing; Mon, 15 Jul 2002 09:35:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FGYwRw005055 for ; Mon, 15 Jul 2002 09:34:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA26974; Mon, 15 Jul 2002 11:39:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA13054; Mon, 15 Jul 2002 11:39:44 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6FGXvg28705; Mon, 15 Jul 2002 11:33:57 -0500 Subject: Re: XFS 1.1 and pre-emptible kernel??? From: Steve Lord To: rjmx@rjmx.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <87it3hhs1o.wl@khufu.rjmx.net> References: <87it3hhs1o.wl@khufu.rjmx.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Jul 2002 11:33:57 -0500 Message-Id: <1026750837.15571.16.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-07-15 at 11:30, Ron Murray wrote: > I'm running a 2.4.18 kernel with XFS 1.1 and the pre-emptible kernel > patch. If I create an XFS filesystem on /var, any process I run on the > machine runs ok (as far as I can tell), but gives a > > exited with preempt_count x > > error on exit (where x > 1). > > Some digging at google turned up a suggestion that the XFS > developers were aware of the problem, and that it had been fixed in > CVS (this some time in early April), although nothing shows up in a > search of this mailing list. > > I'd rather not try the current CVS version of XFS (don't trust > pre-release kernels!), but I'm curious to see if it's been fixed (and > I can wait till the official 2.4.19 kernel release and XFS patches). > > Is it better now? > This is fixed in CVS, has been for a while now I think, Eric did some testing, and can confirm or deny this. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jul 15 09:37:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FGbeRw005317 for ; Mon, 15 Jul 2002 09:37:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FGbeOW005316 for linux-xfs-outgoing; Mon, 15 Jul 2002 09:37:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FGbWRw005288 for ; Mon, 15 Jul 2002 09:37:32 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA25174; Mon, 15 Jul 2002 11:42:18 -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 LAA12943; Mon, 15 Jul 2002 11:42:18 -0500 (CDT) Subject: Re: XFS 1.1 and pre-emptible kernel??? From: Eric Sandeen To: rjmx@rjmx.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <87it3hhs1o.wl@khufu.rjmx.net> References: <87it3hhs1o.wl@khufu.rjmx.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 15 Jul 2002 11:41:22 -0500 Message-Id: <1026751283.10198.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ron - I tested pre-empt with xfs a week or two ago, and I did get some of these " exited with preempt_count x" messages. On the other hand, I then tested with a vanilla ext2 kernel + pre-empt, and got the same messages. So, I don't think the problem is unique to, or necessarily even caused by, XFS. What processes complained of non-zero preempt_counts? Can you run these same tests on an ext[2,3]-only box, without xfs patches? -Eric On Mon, 2002-07-15 at 11:30, Ron Murray wrote: > I'm running a 2.4.18 kernel with XFS 1.1 and the pre-emptible kernel > patch. If I create an XFS filesystem on /var, any process I run on the > machine runs ok (as far as I can tell), but gives a > > exited with preempt_count x > > error on exit (where x > 1). > > Some digging at google turned up a suggestion that the XFS > developers were aware of the problem, and that it had been fixed in > CVS (this some time in early April), although nothing shows up in a > search of this mailing list. > > I'd rather not try the current CVS version of XFS (don't trust > pre-release kernels!), but I'm curious to see if it's been fixed (and > I can wait till the official 2.4.19 kernel release and XFS patches). > > Is it better now? > > .....Ron > From owner-linux-xfs@oss.sgi.com Mon Jul 15 11:05:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FI5kRw007007 for ; Mon, 15 Jul 2002 11:05:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FI5k2Y007006 for linux-xfs-outgoing; Mon, 15 Jul 2002 11:05:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.rjmx.net (root@khufu.ne.client2.attbi.com [24.91.146.150]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FI5ZRw006978 for ; Mon, 15 Jul 2002 11:05:36 -0700 Received: from khufu.rjmx.net (ron@khufu.rjmx.net [192.168.1.2]) by mail.rjmx.net (8.12.3/8.12.3) with ESMTP id g6FIAPmr014081; Mon, 15 Jul 2002 14:10:25 -0400 Date: Mon, 15 Jul 2002 14:10:24 -0400 Message-ID: <87adosq2un.wl@khufu.rjmx.net> From: Ron Murray To: Eric Sandeen Cc: rjmx@rjmx.net, linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 and pre-emptible kernel??? In-Reply-To: <1026751283.10198.4.camel@stout.americas.sgi.com> References: <87it3hhs1o.wl@khufu.rjmx.net> <1026751283.10198.4.camel@stout.americas.sgi.com> User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) Reply-To: rjmx@rjmx.net MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric. I suppose I should have explained exactly what I did. It went something like this: - System is currently ext3 on /, reiserfs on /var, /usr, /home - Booted to single-user mode - Backed up /var filesystem (to /usr/something-or-other). /var is on device /dev/hda7. - Unmounted original /var - Ran 'mkfs -t xfs -f /dev/hda7' (it complained if I left out '-f'), and this completed with no errors - mount -t xfs /dev/hda7 /var. No problems. - Copied contents of /usr/whatever-it-was back to /var At this point, almost any program I ran would exit with the preempt_count error (I remember it happened with ls at least, but others did the same. I forget which). If you want me to run some more tests, I can probably do some tonight. I have seen some of these errors in my system log, and once or twice when shutting the system down, but they were always related to nfs and rpciod (? memory failure: replace brain). They were also rare; it was only when I created and used an xfs filesystem that the errors appeared on lots of other things, and far more often. Furthermore, they went away when I switched back to reiserfs on /var. .....Ron At 15 Jul 2002 11:41:22 -0500, Eric Sandeen wrote: > > Hi Ron - > > I tested pre-empt with xfs a week or two ago, and I did get some of > these " exited with preempt_count x" messages. > > On the other hand, I then tested with a vanilla ext2 kernel + pre-empt, > and got the same messages. > > So, I don't think the problem is unique to, or necessarily even caused > by, XFS. What processes complained of non-zero preempt_counts? Can you > run these same tests on an ext[2,3]-only box, without xfs patches? > > -Eric -- Ron Murray (rjmx@rjmx.net) http://www.rjmx.net/~ron GPG Public Key Fingerprint: F2C1 FC47 5EF7 0317 133C D66B 8ADA A3C4 D86C 74DE From owner-linux-xfs@oss.sgi.com Mon Jul 15 11:25:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FIPTRw007533 for ; Mon, 15 Jul 2002 11:25:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FIPT66007532 for linux-xfs-outgoing; Mon, 15 Jul 2002 11:25:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FIPORw007503 for ; Mon, 15 Jul 2002 11:25:24 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA30139; Mon, 15 Jul 2002 13:30:11 -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 NAA08850; Mon, 15 Jul 2002 13:30:10 -0500 (CDT) Subject: Re: XFS 1.1 and pre-emptible kernel??? From: Eric Sandeen To: rjmx@rjmx.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <87adosq2un.wl@khufu.rjmx.net> References: <87it3hhs1o.wl@khufu.rjmx.net> <1026751283.10198.4.camel@stout.americas.sgi.com> <87adosq2un.wl@khufu.rjmx.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 15 Jul 2002 13:29:14 -0500 Message-Id: <1026757754.7431.19.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ron - On Mon, 2002-07-15 at 13:10, Ron Murray wrote: > At this point, almost any program I ran would exit with the > preempt_count error (I remember it happened with ls at least, but > others did the same. I forget which). If you want me to run some more > tests, I can probably do some tonight. Ah, ok. Well I guess it's fixed in CVS then, but not in XFS 1.1. I wasn't sure when the changes went in. So, if you want to use pre-empt, you'll need to use CVS or wait for our next release. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Jul 15 11:37:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FIbmRw007782 for ; Mon, 15 Jul 2002 11:37:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FIbmmH007781 for linux-xfs-outgoing; Mon, 15 Jul 2002 11:37:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ursa.xanoptix.com (host-64-65-199-187.choiceone.net [64.65.199.187]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FIbbRw007752 for ; Mon, 15 Jul 2002 11:37:39 -0700 Received: from kend-linux.xanoptix.com ([10.20.1.45] helo=xanoptix.com)by ursa.xanoptix.comwith smtp(Exim 3.20 #1 (Debian))id 17UAnj-00078t-00for ; Mon, 15 Jul 2002 14:42:27 -0400 Received: from 10.20.1.45 (SquirrelMail authenticated user kend) by kend-linux.xanoptix.com with HTTP; Mon, 15 Jul 2002 14:42:28 -0400 (EDT) Message-ID: <33881.10.20.1.45.1026758548.squirrel@kend-linux.xanoptix.com> Date: Mon, 15 Jul 2002 14:42:28 -0400 (EDT) Subject: XFS (via CVS, last Thursday) and segfaulting on getfacl. From: "Ken D'Ambrosio" To: In-Reply-To: <87adosq2un.wl@khufu.rjmx.net> References: <87adosq2un.wl@khufu.rjmx.net> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.5) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Howdy, all. I got the latest and greatest XFS on Thursday, and just tried something that's got me a bit confused. I wanted to set ACLs on our Sales directory, recursively, so I did setfacl -m -R g:gSales:rwx Sales/ which spat back setfacl: Option -m: Invalid argument near character 1 So I then tried reversing "-m" and "-R", and it seemed to work. However, now when I try to getfacl, I get: [root@nebula shared]# getfacl Sales # file: Sales # owner: root # group: root Segmentation fault Any suggestions as to a) where I screwed up, and b) how to fix it? Thanks! -Ken From owner-linux-xfs@oss.sgi.com Mon Jul 15 12:53:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FJrmRw008547 for ; Mon, 15 Jul 2002 12:53:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FJrm8m008546 for linux-xfs-outgoing; Mon, 15 Jul 2002 12:53:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FJreRw008509 for ; Mon, 15 Jul 2002 12:53:40 -0700 Received: (qmail 14712 invoked by uid 500); 15 Jul 2002 19:57:59 -0000 Subject: sysctl tuning for XFS. From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IsLC5D3REBpBxCb7+FPn" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 15 Jul 2002 14:57:58 -0500 Message-Id: <1026763078.14248.16.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-IsLC5D3REBpBxCb7+FPn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable In the following directory in proc, /proc/sys/fs/xfs/, exists the following tuneables, refcache_purge refcache_size . What, if any, can I gain by tweaking these on a quad processor P4 Xeon server? I'm using 2.4.19-rc1-aa2 on this box and pushing ~900GB oracle DB. I've got 8GB ram also.=20 Any help would be much appreciated. --=20 Austin Gonyou Coremetrics, Inc. --=-IsLC5D3REBpBxCb7+FPn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9MylG94g6ZVmFMoIRAl0MAJ9qK+FPYYjF+CzNVzOqsWoFkSeSjgCffi02 HiEgJZXQTuRjjvgELfPgnYo= =qP+G -----END PGP SIGNATURE----- --=-IsLC5D3REBpBxCb7+FPn-- From owner-linux-xfs@oss.sgi.com Mon Jul 15 13:14:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FKE4Rw010377 for ; Mon, 15 Jul 2002 13:14:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FKE3V2010376 for linux-xfs-outgoing; Mon, 15 Jul 2002 13:14:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FKDuRw009305 for ; Mon, 15 Jul 2002 13:13:56 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA30650; Mon, 15 Jul 2002 15:18:42 -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 PAA24358; Mon, 15 Jul 2002 15:18:42 -0500 (CDT) Subject: Re: sysctl tuning for XFS. From: Eric Sandeen To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1026763078.14248.16.camel@UberGeek> References: <1026763078.14248.16.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 15 Jul 2002 15:17:45 -0500 Message-Id: <1026764265.7431.31.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-07-15 at 14:57, Austin Gonyou wrote: > > In the following directory in proc, /proc/sys/fs/xfs/, exists the > following tuneables, refcache_purge refcache_size . What, if any, can I > gain by tweaking these on a quad processor P4 Xeon server? I'm using > 2.4.19-rc1-aa2 on this box and pushing ~900GB oracle DB. I've got 8GB > ram also. Those are for the NFS refcache, which holds references on files written via NFS, to keep pre-allocation in-place for a while. To quote Steve, "This prevents xfs from constantly freeing this space and then reallocating it on the next write and is a very major performance win in NFS." So, the size & purge sysctl values are how big this cache is, and how many entries are purged out every time the filesystem syncs (i.e. how fast it drains). If you have a lot of writes coming in at once over NFS making the cache larger might help. In general you'd probably scale the purge size with the overall size. Since it holds things open with pre-allocation, you'll see more disk usage while the file is in the NFS refcache. If you have quotas, this could impact user quotas. If you have a lot of dirty entries in the refcache, umount might take longer, as well. If you find anything interesting while testing, let us know. :) -Eric From owner-linux-xfs@oss.sgi.com Mon Jul 15 13:25:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FKPZRw012169 for ; Mon, 15 Jul 2002 13:25:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FKPZwZ012168 for linux-xfs-outgoing; Mon, 15 Jul 2002 13:25:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from tigger.cc-concepts.com (64-40-83-10.dsl.mebtel.net [64.40.83.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FKPORw012130 for ; Mon, 15 Jul 2002 13:25:24 -0700 Received: from thebaptistes.net (CharliesMac.egr.duke.edu [152.3.195.6]) (authenticated) by tigger.cc-concepts.com (8.11.6/8.11.6) with ESMTP id g6FKU1Z08293; Mon, 15 Jul 2002 16:30:01 -0400 Message-ID: <3D3330C8.7050608@thebaptistes.net> Date: Mon, 15 Jul 2002 16:30:00 -0400 From: Mike Baptiste User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rjmx@rjmx.net CC: linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 and pre-emptible kernel??? References: <87it3hhs1o.wl@khufu.rjmx.net> X-Enigmail-Version: 0.63.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.2 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK,PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get tons of these as well with 2.4.18 and 1.1 using rel 5 of the pre-empt patch. I used GCC 3.1 to compile. As far as I can tell they are harmless messages, though they fill up dmesg quickly ;) A Google search turned up a post from R. Love talking about how this was a debug message that came out if the pre-empt count was not = 0. He felt it would be rare to have it not be 0, though he had gotten some reports of false logs and was thinking he might pull the log message. Can't find it now though (I searched when I first recompiled) Well, I can attest that pretty much every process that exits on my machine generates these messages. But so far, my machine has run like a rock with it - so for now I'm ignoring the logs and plowing ahead ;) Mike Ron Murray wrote: > I'm running a 2.4.18 kernel with XFS 1.1 and the pre-emptible kernel > patch. If I create an XFS filesystem on /var, any process I run on the > machine runs ok (as far as I can tell), but gives a > > exited with preempt_count x > > error on exit (where x > 1). > > Some digging at google turned up a suggestion that the XFS > developers were aware of the problem, and that it had been fixed in > CVS (this some time in early April), although nothing shows up in a > search of this mailing list. > > I'd rather not try the current CVS version of XFS (don't trust > pre-release kernels!), but I'm curious to see if it's been fixed (and > I can wait till the official 2.4.19 kernel release and XFS patches). > > Is it better now? > > .....Ron > > -- > Ron Murray (rjmx@rjmx.net) > http://www.rjmx.net/~ron > GPG Public Key Fingerprint: F2C1 FC47 5EF7 0317 133C D66B 8ADA A3C4 D86C 74DE - -- Mike Baptiste - mike@thebaptistes.net Download my GnuPG key at http://thebaptistes.net/mike.gpg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9MzDIjIdByR81v90RAq5/AJ4zTeRJTMKviDLEB91uyB4NPXaYMgCgpwak llcQG4qjB2d+cv7liI1lsXA= =D2HK -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Jul 15 13:30:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FKUQRw012425 for ; Mon, 15 Jul 2002 13:30:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FKUQng012424 for linux-xfs-outgoing; Mon, 15 Jul 2002 13:30:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FKUMRw012395 for ; Mon, 15 Jul 2002 13:30:22 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA33831; Mon, 15 Jul 2002 15:35:08 -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 PAA02254; Mon, 15 Jul 2002 15:35:08 -0500 (CDT) Subject: Re: XFS 1.1 and pre-emptible kernel??? From: Eric Sandeen To: Mike Baptiste Cc: rjmx@rjmx.net, linux-xfs@oss.sgi.com In-Reply-To: <3D3330C8.7050608@thebaptistes.net> References: <87it3hhs1o.wl@khufu.rjmx.net> <3D3330C8.7050608@thebaptistes.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 15 Jul 2002 15:34:11 -0500 Message-Id: <1026765251.7431.34.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-07-15 at 15:30, Mike Baptiste wrote: > Well, I can attest that pretty much every process that exits on my > machine generates these messages. But so far, my machine has run like a > rock with it - so for now I'm ignoring the logs and plowing ahead ;) I think that the rest of RML's post said that if you were getting > 0, then pre-empt was essentially not doing it's job. Safe, probably, but not actually doing anything. :) So plowing ahead is fine, but your machine might not be running the way you think it is. -Eric From owner-linux-xfs@oss.sgi.com Mon Jul 15 13:41:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FKfpRw012709 for ; Mon, 15 Jul 2002 13:41:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FKfpLg012708 for linux-xfs-outgoing; Mon, 15 Jul 2002 13:41:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FKfjRw012678 for ; Mon, 15 Jul 2002 13:41:46 -0700 Received: from [195.20.224.220] (helo=mrvdomng1.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #3) id 17UCij-0000RE-00; Mon, 15 Jul 2002 22:45:25 +0200 Received: from [217.228.145.100] (helo=kernelpanix.aura.of.mankind) by mrvdomng1.kundenserver.de with esmtp (Exim 3.35 #2) id 17UCij-0004R0-00; Mon, 15 Jul 2002 22:45:25 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id g6FKRkT12185; Mon, 15 Jul 2002 22:27:46 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Mon, 15 Jul 2002 22:27:46 +0200 From: utz lehmann To: Eric Sandeen Cc: Mike Baptiste , rjmx@rjmx.net, linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 and pre-emptible kernel??? Message-ID: <20020715222746.A12181@s2y4n2c.de> References: <87it3hhs1o.wl@khufu.rjmx.net> <3D3330C8.7050608@thebaptistes.net> <1026765251.7431.34.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1026765251.7431.34.camel@stout.americas.sgi.com> X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen [sandeen@sgi.com] wrote: > On Mon, 2002-07-15 at 15:30, Mike Baptiste wrote: > > > Well, I can attest that pretty much every process that exits on my > > machine generates these messages. But so far, my machine has run like a > > rock with it - so for now I'm ignoring the logs and plowing ahead ;) > > I think that the rest of RML's post said that if you were getting > 0, > then pre-empt was essentially not doing it's job. Safe, probably, but > not actually doing anything. :) So plowing ahead is fine, but your > machine might not be running the way you think it is. I can confirm this. The 2.4.18 and 1.1 patches produced tons of this error/warnings and the preempt snappies was gone (no preemption works). Using a CVS kernel is ok. I only get this warnings while unmounting on shutdown. utz From owner-linux-xfs@oss.sgi.com Mon Jul 15 14:14:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FLE3Rw013491 for ; Mon, 15 Jul 2002 14:14:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FLE3PM013490 for linux-xfs-outgoing; Mon, 15 Jul 2002 14:14:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FLDpRw013274 for ; Mon, 15 Jul 2002 14:13:51 -0700 Received: (qmail 15069 invoked by uid 500); 15 Jul 2002 21:15:18 -0000 Subject: Re: sysctl tuning for XFS. From: Austin Gonyou To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1026764265.7431.31.camel@stout.americas.sgi.com> References: <1026764265.7431.31.camel@stout.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2OtiJzYdyZndZszpgms+" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 15 Jul 2002 16:15:18 -0500 Message-Id: <1026767718.14816.9.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-2OtiJzYdyZndZszpgms+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ahh..good info. Nothing I can use here, but good info. I say that because I'm not doing any NFS stuff in this case. What I'm really trying to do is do lots of sysctl tuning stuffs with regard to memory and disk IO to maximize the bandwidth for oracle.=20 On Mon, 2002-07-15 at 15:17, Eric Sandeen wrote: > On Mon, 2002-07-15 at 14:57, Austin Gonyou wrote: > >=20 > > In the following directory in proc, /proc/sys/fs/xfs/, exists the > > following tuneables, refcache_purge refcache_size . What, if any, > can I > > gain by tweaking these on a quad processor P4 Xeon server? I'm using > > 2.4.19-rc1-aa2 on this box and pushing ~900GB oracle DB. I've got > 8GB > > ram also.=20 >=20 > Those are for the NFS refcache, which holds references on files > written > via NFS, to keep pre-allocation in-place for a while. To quote Steve, >=20 > "This prevents xfs from constantly freeing this space and then > reallocating it on the next write and is a very major performance win > in > NFS." >=20 > So, the size & purge sysctl values are how big this cache is, and how > many entries are purged out every time the filesystem syncs (i.e. how > fast it drains).=20=20 >=20 > If you have a lot of writes coming in at once over NFS making the > cache > larger might help. In general you'd probably scale the purge size > with > the overall size. >=20 > Since it holds things open with pre-allocation, you'll see more disk > usage while the file is in the NFS refcache. If you have quotas, this > could impact user quotas. If you have a lot of dirty entries in the > refcache, umount might take longer, as well. >=20 > If you find anything interesting while testing, let us know. :) >=20 > -Eric --=20 Austin Gonyou Coremetrics, Inc. --=-2OtiJzYdyZndZszpgms+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9Mztm94g6ZVmFMoIRAgIiAKCT0BXyXnA09kQU46Uw52yry/6ltACfXeK4 B5tkShNeEzSts+tVSPe5w2s= =PxkP -----END PGP SIGNATURE----- --=-2OtiJzYdyZndZszpgms+-- From owner-linux-xfs@oss.sgi.com Mon Jul 15 15:12:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FMC4Rw014503 for ; Mon, 15 Jul 2002 15:12:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FMC4r3014502 for linux-xfs-outgoing; Mon, 15 Jul 2002 15:12:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FMBuRw014472 for ; Mon, 15 Jul 2002 15:11:56 -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 PAA07668 for ; Mon, 15 Jul 2002 15:17:15 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA06286; Tue, 16 Jul 2002 08:15:28 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) with ESMTP id g6FME3YT000979; Tue, 16 Jul 2002 08:14:03 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) id g6FME23E000977; Tue, 16 Jul 2002 08:14:02 +1000 Date: Tue, 16 Jul 2002 08:14:02 +1000 From: Nathan Scott To: "Ken D'Ambrosio" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS (via CVS, last Thursday) and segfaulting on getfacl. Message-ID: <20020715221402.GA454@frodo> References: <87adosq2un.wl@khufu.rjmx.net> <33881.10.20.1.45.1026758548.squirrel@kend-linux.xanoptix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33881.10.20.1.45.1026758548.squirrel@kend-linux.xanoptix.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Ken, On Mon, Jul 15, 2002 at 02:42:28PM -0400, Ken D'Ambrosio wrote: > Howdy, all. I got the latest and greatest XFS on Thursday, and just tried Did you get a new kernel and new tools? (what does getfacl --version say on your box?) > something that's got me a bit confused. I wanted to set ACLs on our Sales > directory, recursively, so I did > setfacl -m -R g:gSales:rwx Sales/ which spat back > > setfacl: Option -m: Invalid argument near character 1 > > So I then tried reversing "-m" and "-R", and it seemed to work. However, Yep, -m needs an argument. > now when I try to getfacl, I get: > > [root@nebula shared]# getfacl Sales > # file: Sales > # owner: root > # group: root > Segmentation fault > > Any suggestions as to a) where I screwed up, and b) how to fix it? Make sure you have latest tools as well as kernel, if that doesn't help (hopefully it will - I tried but can't reproduce this problem), we'll need to get a getfacl core dump and start to analyse where its going wrong. Remember to type "limit coredumpsize unlimited" before running getfacl, and then mail the core file to me. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jul 15 15:46:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FMkWRw015129 for ; Mon, 15 Jul 2002 15:46:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FMkWf0015128 for linux-xfs-outgoing; Mon, 15 Jul 2002 15:46:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from tigger.cc-concepts.com (64-40-83-10.dsl.mebtel.net [64.40.83.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FMkNRw015099 for ; Mon, 15 Jul 2002 15:46:24 -0700 Received: from thebaptistes.net (gwy3.cc-concepts.com [64.40.83.12]) (authenticated) by tigger.cc-concepts.com (8.11.6/8.11.6) with ESMTP id g6FMpBZ11030 for ; Mon, 15 Jul 2002 18:51:11 -0400 Message-ID: <3D3351DE.2060008@thebaptistes.net> Date: Mon, 15 Jul 2002 18:51:10 -0400 From: Mike Baptiste User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 and pre-emptible kernel??? References: <87it3hhs1o.wl@khufu.rjmx.net> <3D3330C8.7050608@thebaptistes.net> <1026765251.7431.34.camel@stout.americas.sgi.com> X-Enigmail-Version: 0.63.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.2 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK,PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I figured as much since, like Utz, I noticed the responsiveness was a little slower, but everything seemed to be working. I've generally stuck with XFS releases up till now, but maybe I'll give the CVS snapshot a go :) Mike Eric Sandeen wrote: > On Mon, 2002-07-15 at 15:30, Mike Baptiste wrote: > > >>Well, I can attest that pretty much every process that exits on my >>machine generates these messages. But so far, my machine has run like a >>rock with it - so for now I'm ignoring the logs and plowing ahead ;) > > > I think that the rest of RML's post said that if you were getting > 0, > then pre-empt was essentially not doing it's job. Safe, probably, but > not actually doing anything. :) So plowing ahead is fine, but your > machine might not be running the way you think it is. > > -Eric - -- Mike Baptiste - mike@thebaptistes.net Download my GnuPG key at http://thebaptistes.net/mike.gpg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9M1HdjIdByR81v90RAqdjAKCaZJ6zKpWrek9oajngWirq/1uBrACglIDU zmMysE+glXlqSS663p6hlrU= =JiI3 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Jul 15 21:09:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6G493Rw018860 for ; Mon, 15 Jul 2002 21:09:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6G493VQ018859 for linux-xfs-outgoing; Mon, 15 Jul 2002 21:09:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6G48xRw018831 for ; Mon, 15 Jul 2002 21:08:59 -0700 Received: from idcomm.com (IDENT:jOnhAJXSTiY/S8689fanRIw6dTqDRKhO@tnt01-ppp-087.idcomm.com [216.98.194.87]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g6G4Exl06139 for ; Mon, 15 Jul 2002 22:14:59 -0600 Message-ID: <3D339DCB.715E072C@idcomm.com> Date: Mon, 15 Jul 2002 22:15:07 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: current cvs status of aic7xxx "build firmware" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I remember quite a while back the need to choose the "build firmware" on aic7xxx, and lots of kernel config headaches for the SGI people with regards to generated versus permanent files in the source tree. The FAQ still says build firmware is needed for aic7xxx, but somewhere I vaguely recall this might have changed. Is it still recommended or required to build firmware? Or is this no longer the case, with the FAQ being outdated? D. Stimits, stimits @ idcomm.com From owner-linux-xfs@oss.sgi.com Mon Jul 15 21:42:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6G4g1Rw019404 for ; Mon, 15 Jul 2002 21:42:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6G4g1nj019403 for linux-xfs-outgoing; Mon, 15 Jul 2002 21:42:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6G4frRw019374 for ; Mon, 15 Jul 2002 21:41:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA38847 for ; Mon, 15 Jul 2002 23:46: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 XAA99957 for ; Mon, 15 Jul 2002 23:46:42 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6G4jfO26653; Mon, 15 Jul 2002 23:45:41 -0500 Message-Id: <200207160445.g6G4jfO26653@stout.americas.sgi.com> Date: Mon, 15 Jul 2002 23:45:41 -0500 Subject: TAKE - build cmds with rpmbuild X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This should get things working again with the very latest versions of RPM, which require rpmbuild for building rpms (as opposed to just using rpm). Looking at the configure.in files there's some other non-critical cleanup that could be done, but ignoring that for now. :) Use rpmbuild for building rpms Date: Mon Jul 15 21:44:19 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:123084a cmd/acl/configure.in - 1.19 cmd/acl/build/Makefile - 1.9 cmd/acl/build/rpm/Makefile - 1.10 cmd/acl/include/builddefs.in - 1.21 cmd/attr/configure.in - 1.10 cmd/attr/build/Makefile - 1.7 cmd/attr/build/rpm/Makefile - 1.9 cmd/attr/include/builddefs.in - 1.18 cmd/xfsprogs/configure.in - 1.14 cmd/xfsprogs/build/Makefile - 1.8 cmd/xfsprogs/build/rpm/Makefile - 1.9 cmd/xfsprogs/include/builddefs.in - 1.23 cmd/xfsdump/configure.in - 1.20 cmd/xfsdump/build/Makefile - 1.7 cmd/xfsdump/build/rpm/Makefile - 1.8 cmd/xfsdump/include/builddefs.in - 1.18 cmd/dmapi/configure.in - 1.15 cmd/dmapi/build/Makefile - 1.7 cmd/dmapi/build/rpm/Makefile - 1.8 cmd/dmapi/include/builddefs.in - 1.17 From owner-linux-xfs@oss.sgi.com Mon Jul 15 21:56:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6G4uPRw019745 for ; Mon, 15 Jul 2002 21:56:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6G4uPOF019744 for linux-xfs-outgoing; Mon, 15 Jul 2002 21:56:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6G4uJRw019715 for ; Mon, 15 Jul 2002 21:56:20 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id AAA35636; Tue, 16 Jul 2002 00:01:08 -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 AAA45130; Tue, 16 Jul 2002 00:01:08 -0500 (CDT) Date: Tue, 16 Jul 2002 00:00:08 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: current cvs status of aic7xxx "build firmware" In-Reply-To: <3D339DCB.715E072C@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It looks like the built firmware was added back to the tree about a year ago - on purpose, even. Not sure what the circumstances surrounding that change were, but it's in the tree at this point. So there should be no need to rebuild. -Eric On Mon, 15 Jul 2002, D. Stimits wrote: > I remember quite a while back the need to choose the "build firmware" on > aic7xxx, and lots of kernel config headaches for the SGI people with > regards to generated versus permanent files in the source tree. The FAQ > still says build firmware is needed for aic7xxx, but somewhere I vaguely > recall this might have changed. Is it still recommended or required to > build firmware? Or is this no longer the case, with the FAQ being > outdated? > > D. Stimits, stimits @ idcomm.com > From owner-linux-xfs@oss.sgi.com Mon Jul 15 23:51:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6G6pHRw020801 for ; Mon, 15 Jul 2002 23:51:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6G6pHSV020800 for linux-xfs-outgoing; Mon, 15 Jul 2002 23:51:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6G6pBRw020772 for ; Mon, 15 Jul 2002 23:51:12 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6G6u1A6016259; Tue, 16 Jul 2002 08:56:02 +0200 (CEST) Message-Id: <4.3.2.7.2.20020716085329.04173360@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jul 2002 08:55:03 +0200 To: Eric Sandeen , "D. Stimits" From: Seth Mos Subject: Re: current cvs status of aic7xxx "build firmware" Cc: "XFS: linux-xfs@oss.sgi.com" In-Reply-To: References: <3D339DCB.715E072C@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 00:00 16-7-2002 -0500, Eric Sandeen wrote: >It looks like the built firmware was added back to the tree about >a year ago - on purpose, even. Not sure what the circumstances >surrounding that change were, but it's in the tree at this point. >So there should be no need to rebuild. Unless you have problems ofcourse. That is what the FAQ entry refers to. I still build my kernel with this option enabled. It's just a few extra cycles the machine has to make. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Jul 16 03:38:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GAc8Rw023464 for ; Tue, 16 Jul 2002 03:38:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GAc8TK023463 for linux-xfs-outgoing; Tue, 16 Jul 2002 03:38:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GAaiRw023430 for ; Tue, 16 Jul 2002 03:36:45 -0700 Received: (qmail 4878 invoked by uid 0); 16 Jul 2002 10:41:33 -0000 Date: Tue, 16 Jul 2002 12:41:33 +0200 (MEST) From: ayatu@gmx.de To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="========GMXBoundary326931026816093" Subject: hard lockup - kmem_cache_zalloc X-Priority: 3 (Normal) X-Authenticated-Sender: #0007628267@gmx.net X-Authenticated-IP: [194.77.158.72] Message-ID: <32693.1026816093@www20.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a MIME encapsulated multipart message - please use a MIME-compliant e-mail program to open it. Dies ist eine mehrteilige Nachricht im MIME-Format - bitte verwenden Sie zum Lesen ein MIME-konformes Mailprogramm. --========GMXBoundary326931026816093 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've attached the output of 'ksymoops < kern.log > kern.log.ksymoops_ed' and the messages logfile from after the hard-reboot. I didn't bother to ksymoops 'messages' too as those dumps were already in kern.log. The bester anwser I could get would be that this is most probably a hardware-failure as a software-failure would give the anti-linux camp here ammunition to switch over to an CVSNT-server :D Thanks in advance. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net --========GMXBoundary326931026816093 Content-Type: application/octet-stream; name="kern.log.ksymoops_ed" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kern.log.ksymoops_ed" a3N5bW9vcHMgMi40LjMgb24gaTY4NiAyLjQuMTcteGZzLiAgT3B0aW9ucyB1 c2VkCiAgICAgLVYgKGRlZmF1bHQpCiAgICAgLWsgL3Byb2Mva3N5bXMgKGRl ZmF1bHQpCiAgICAgLWwgL3Byb2MvbW9kdWxlcyAoZGVmYXVsdCkKICAgICAt byAvbGliL21vZHVsZXMvMi40LjE3LXhmcy8gKGRlZmF1bHQpCiAgICAgLW0g L2Jvb3QvU3lzdGVtLm1hcC0yLjQuMTcteGZzIChkZWZhdWx0KQoKV2Fybmlu ZzogWW91IGRpZCBub3QgdGVsbCBtZSB3aGVyZSB0byBmaW5kIHN5bWJvbCBp bmZvcm1hdGlvbi4gIEkgd2lsbAphc3N1bWUgdGhhdCB0aGUgbG9nIG1hdGNo ZXMgdGhlIGtlcm5lbCBhbmQgbW9kdWxlcyB0aGF0IGFyZSBydW5uaW5nCnJp Z2h0IG5vdyBhbmQgSSdsbCB1c2UgdGhlIGRlZmF1bHQgb3B0aW9ucyBhYm92 ZSBmb3Igc3ltYm9sIHJlc29sdXRpb24uCklmIHRoZSBjdXJyZW50IGtlcm5l bCBhbmQvb3IgbW9kdWxlcyBkbyBub3QgbWF0Y2ggdGhlIGxvZywgeW91IGNh biBnZXQKbW9yZSBhY2N1cmF0ZSBvdXRwdXQgYnkgdGVsbGluZyBtZSB0aGUg a2VybmVsIHZlcnNpb24gYW5kIHdoZXJlIHRvIGZpbmQKbWFwLCBtb2R1bGVz LCBrc3ltcyBldGMuICBrc3ltb29wcyAtaCBleHBsYWlucyB0aGUgb3B0aW9u cy4KCkp1bCAxNSAyMDoxMzozMiBjdnMga2VybmVsOiBVbmFibGUgdG8gaGFu ZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3Mg ZTUzMGMyYzAKSnVsIDE1IDIwOjEzOjMyIGN2cyBrZXJuZWw6IGMwMTI2NmU0 Ckp1bCAxNSAyMDoxMzozMiBjdnMga2VybmVsOiAqcGRlID0gMDAwMDAwMDAK SnVsIDE1IDIwOjEzOjMyIGN2cyBrZXJuZWw6IE9vcHM6IDAwMDIKSnVsIDE1 IDIwOjEzOjMyIGN2cyBrZXJuZWw6IENQVTogICAgMApKdWwgMTUgMjA6MTM6 MzIgY3ZzIGtlcm5lbDogRUlQOiAgICAwMDEwOltrbWVtX2NhY2hlX3phbGxv YysxODgvMjEyXSAgICBUYWludGVkOiBQIApKdWwgMTUgMjA6MTM6MzIgY3Zz IGtlcm5lbDogRUZMQUdTOiAwMDAxMDIwNgpKdWwgMTUgMjA6MTM6MzIgY3Zz IGtlcm5lbDogZWF4OiAwMDAwMDAwMCAgIGVieDogMDAwMDAwODggICBlY3g6 IDAwMDAwMDIyICAgZWR4OiAwMDAwMDAwMApKdWwgMTUgMjA6MTM6MzIgY3Zz IGtlcm5lbDogZXNpOiBlNTMwYzJjMCAgIGVkaTogZTUzMGMyYzAgICBlYnA6 IDAwMDAwMGYwICAgZXNwOiBjNjllYmRkYwpKdWwgMTUgMjA6MTM6MzIgY3Zz IGtlcm5lbDogZHM6IDAwMTggICBlczogMDAxOCAgIHNzOiAwMDE4Ckp1bCAx NSAyMDoxMzozMiBjdnMga2VybmVsOiBQcm9jZXNzIHVhZ2VudGQgKHBpZDog MjgzMCwgc3RhY2twYWdlPWM2OWViMDAwKQpKdWwgMTUgMjA6MTM6MzIgY3Zz IGtlcm5lbDogU3RhY2s6IDAwMDAwMDAwIDAwMDAwMDA2IDAwMDAwMDAxIGRm NjgzMGUwIGUwODlhNmViIGRmNjgzMGUwIDAwMDAwMGYwIGMxYjBkYTA0IApK dWwgMTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogICAgICAgIGRmN2M5MDAwIDAw MDAwMDA0IGRmZGU3MGUwIGUwOGQ2MTgzIGRmNjgzMGUwIDAwMDAwMDAxIDAw MDAwMDA0IGMxYjBkYTA0IApKdWwgMTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDog ICAgICAgIGUwOGU1YTYzIGMxYjBkYTA0IGRmN2M5MDAwIDAwMDAwMDA0IGMx YjBkYTA0IDAwMDAwNzAwIGRmN2M5MDAwIGUwOGU5MDgzIApKdWwgMTUgMjA6 MTM6MzIgY3ZzIGtlcm5lbDogQ2FsbCBUcmFjZTogW3hmczpfX2luc21vZF94 ZnNfTy9saWIvbW9kdWxlcy8yLjQuMTcteGZzL2tlcm5lbC9mcy94ZnMveGZz Lm9fTSstMTA1MTcvOTZdIFt4ZnM6X19pbnNtb2RfeGZzX1MudGV4dF9MMzc2 OTI4KzIzMzc2My8zNzc0NDBdIFt4ZnM6X19pbnNtb2RfeGZzX1MudGV4dF9M Mzc2OTI4KzI5NzQ3NS8zNzc0NDBdIFt4ZnM6X19pbnNtb2RfeGZzX1MudGV4 dF9MMzc2OTI4KzMxMTMzMS8zNzc0NDBdIFt4ZnM6X19pbnNtb2RfeGZzX1Mu dGV4dF9MMzc2OTI4KzM1NjAyNi8zNzc0NDBdIApKdWwgMTUgMjA6MTM6MzIg Y3ZzIGtlcm5lbDogICAgWzxlMDhmZGM4MD5dIFtub3RpZnlfY2hhbmdlKzc2 LzIwOF0gW3N5c191dGltZSsxNzEvMTk2XSBbZmlscF9jbG9zZSs5Mi8xMDBd IFtzeXNfY2xvc2UrNjcvODRdIFtzeXN0ZW1fY2FsbCs1MS81Nl0gCkp1bCAx NSAyMDoxMzozMiBjdnMga2VybmVsOiBDb2RlOiBmMyBhYiBmNiBjMyAwMiA3 NCAwMiA2NiBhYiBmNiBjMyAwMSA3NCAwMSBhYSA4OSBmMCA1YiA1ZSA1ZiAK VXNpbmcgZGVmYXVsdHMgZnJvbSBrc3ltb29wcyAtdCBlbGYzMi1pMzg2IC1h IGkzODYKClRyYWNlOyBlMDhmZGM4MCA8W3hmc11zeXNfY3JlZF92YWwrMC9j MD4KQ29kZTsgIDAwMDAwMDAwIEJlZm9yZSBmaXJzdCBzeW1ib2wKMDAwMDAw MDAgPF9FSVA+OgpDb2RlOyAgMDAwMDAwMDAgQmVmb3JlIGZpcnN0IHN5bWJv bAogICAwOiAgIGYzIGFiICAgICAgICAgICAgICAgICAgICAgcmVweiBzdG9z ICVlYXgsJWVzOiglZWRpKQpDb2RlOyAgMDAwMDAwMDIgQmVmb3JlIGZpcnN0 IHN5bWJvbAogICAyOiAgIGY2IGMzIDAyICAgICAgICAgICAgICAgICAgdGVz dCAgICQweDIsJWJsCkNvZGU7ICAwMDAwMDAwNCBCZWZvcmUgZmlyc3Qgc3lt Ym9sCiAgIDU6ICAgNzQgMDIgICAgICAgICAgICAgICAgICAgICBqZSAgICAg OSA8X0VJUCsweDk+IDAwMDAwMDA4IEJlZm9yZSBmaXJzdCBzeW1ib2wKQ29k ZTsgIDAwMDAwMDA2IEJlZm9yZSBmaXJzdCBzeW1ib2wKICAgNzogICA2NiBh YiAgICAgICAgICAgICAgICAgICAgIHN0b3MgICAlYXgsJWVzOiglZWRpKQpD b2RlOyAgMDAwMDAwMDggQmVmb3JlIGZpcnN0IHN5bWJvbAogICA5OiAgIGY2 IGMzIDAxICAgICAgICAgICAgICAgICAgdGVzdCAgICQweDEsJWJsCkNvZGU7 ICAwMDAwMDAwYyBCZWZvcmUgZmlyc3Qgc3ltYm9sCiAgIGM6ICAgNzQgMDEg ICAgICAgICAgICAgICAgICAgICBqZSAgICAgZiA8X0VJUCsweGY+IDAwMDAw MDBlIEJlZm9yZSBmaXJzdCBzeW1ib2wKQ29kZTsgIDAwMDAwMDBlIEJlZm9y ZSBmaXJzdCBzeW1ib2wKICAgZTogICBhYSAgICAgICAgICAgICAgICAgICAg ICAgIHN0b3MgICAlYWwsJWVzOiglZWRpKQpDb2RlOyAgMDAwMDAwMGUgQmVm b3JlIGZpcnN0IHN5bWJvbAogICBmOiAgIDg5IGYwICAgICAgICAgICAgICAg ICAgICAgbW92ICAgICVlc2ksJWVheApDb2RlOyAgMDAwMDAwMTAgQmVmb3Jl IGZpcnN0IHN5bWJvbAogIDExOiAgIDViICAgICAgICAgICAgICAgICAgICAg ICAgcG9wICAgICVlYngKQ29kZTsgIDAwMDAwMDEyIEJlZm9yZSBmaXJzdCBz eW1ib2wKICAxMjogICA1ZSAgICAgICAgICAgICAgICAgICAgICAgIHBvcCAg ICAlZXNpCkNvZGU7ICAwMDAwMDAxMiBCZWZvcmUgZmlyc3Qgc3ltYm9sCiAg MTM6ICAgNWYgICAgICAgICAgICAgICAgICAgICAgICBwb3AgICAgJWVkaQoK SnVsIDE1IDIyOjMyOjM4IGN2cyBrZXJuZWw6ICA8MT5VbmFibGUgdG8gaGFu ZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3Mg ZTUzMGMyYzAKSnVsIDE1IDIyOjMyOjM4IGN2cyBrZXJuZWw6IGMwMTI2NmU0 Ckp1bCAxNSAyMjozMjozOCBjdnMga2VybmVsOiAqcGRlID0gMDAwMDAwMDAK SnVsIDE1IDIyOjMyOjM4IGN2cyBrZXJuZWw6IE9vcHM6IDAwMDIKSnVsIDE1 IDIyOjMyOjM4IGN2cyBrZXJuZWw6IENQVTogICAgMApKdWwgMTUgMjI6MzI6 MzggY3ZzIGtlcm5lbDogRUlQOiAgICAwMDEwOltrbWVtX2NhY2hlX3phbGxv YysxODgvMjEyXSAgICBUYWludGVkOiBQIApKdWwgMTUgMjI6MzI6MzggY3Zz IGtlcm5lbDogRUZMQUdTOiAwMDAxMDIwNgpKdWwgMTUgMjI6MzI6MzggY3Zz IGtlcm5lbDogZWF4OiAwMDAwMDAwMCAgIGVieDogMDAwMDAwODggICBlY3g6 IDAwMDAwMDIyICAgZWR4OiAwMDAwMDAwMApKdWwgMTUgMjI6MzI6MzggY3Zz IGtlcm5lbDogZXNpOiBlNTMwYzJjMCAgIGVkaTogZTUzMGMyYzAgICBlYnA6 IDAwMDAwMGYwICAgZXNwOiBjYTQxM2I2MApKdWwgMTUgMjI6MzI6MzggY3Zz IGtlcm5lbDogZHM6IDAwMTggICBlczogMDAxOCAgIHNzOiAwMDE4Ckp1bCAx NSAyMjozMjozOCBjdnMga2VybmVsOiBQcm9jZXNzIGN2cyAocGlkOiAyOTUz LCBzdGFja3BhZ2U9Y2E0MTMwMDApCkp1bCAxNSAyMjozMjozOCBjdnMga2Vy bmVsOiBTdGFjazogMDAwMDAwMDAgMDAwMDAwMDYgMDAwMDAwMDEgZGY2ODMw ZTAgZTA4OWE2ZWIgZGY2ODMwZTAgMDAwMDAwZjAgZGU5ZDY5ODQgCkp1bCAx NSAyMjozMjozOCBjdnMga2VybmVsOiAgICAgICAgZGY3YzkwMDAgZGZkZTdl YTAgMDAwMDAwMDQgZTA4ZDYxODMgZGY2ODMwZTAgMDAwMDAwMDEgMDU0MDAx NzYgMDAwMDAwMDAgCkp1bCAxNSAyMjozMjozOCBjdnMga2VybmVsOiAgICAg ICAgZTA4ZTU5NjggZGU5ZDY5ODQgZGY3YzkwMDAgY2E0MTNiZjggMDAwMDAw MDAgMDAwMDgxYjYgY2E0MTNjNmMgZGU5ZDY5ODQgCkp1bCAxNSAyMjozMjoz OCBjdnMga2VybmVsOiBDYWxsIFRyYWNlOiBbeGZzOl9faW5zbW9kX3hmc19P L2xpYi9tb2R1bGVzLzIuNC4xNy14ZnMva2VybmVsL2ZzL3hmcy94ZnMub19N Ky0xMDUxNy85Nl0gW3hmczpfX2luc21vZF94ZnNfUy50ZXh0X0wzNzY5Mjgr MjMzNzYzLzM3NzQ0MF0gW3hmczpfX2luc21vZF94ZnNfUy50ZXh0X0wzNzY5 MjgrMjk3MjI0LzM3NzQ0MF0gW3hmczpfX2luc21vZF94ZnNfUy50ZXh0X0wz NzY5MjgrMjIyNjMxLzM3NzQ0MF0gW3hmczpfX2luc21vZF94ZnNfUy50ZXh0 X0wzNzY5MjgrMzAwMDMyLzM3NzQ0MF0gCkp1bCAxNSAyMjozMjozOCBjdnMg a2VybmVsOiBDb2RlOiBmMyBhYiBmNiBjMyAwMiA3NCAwMiA2NiBhYiBmNiBj MyAwMSA3NCAwMSBhYSA4OSBmMCA1YiA1ZSA1ZiAKCkNvZGU7ICAwMDAwMDAw MCBCZWZvcmUgZmlyc3Qgc3ltYm9sCjAwMDAwMDAwIDxfRUlQPjoKQ29kZTsg IDAwMDAwMDAwIEJlZm9yZSBmaXJzdCBzeW1ib2wKICAgMDogICBmMyBhYiAg ICAgICAgICAgICAgICAgICAgIHJlcHogc3RvcyAlZWF4LCVlczooJWVkaSkK Q29kZTsgIDAwMDAwMDAyIEJlZm9yZSBmaXJzdCBzeW1ib2wKICAgMjogICBm NiBjMyAwMiAgICAgICAgICAgICAgICAgIHRlc3QgICAkMHgyLCVibApDb2Rl OyAgMDAwMDAwMDQgQmVmb3JlIGZpcnN0IHN5bWJvbAogICA1OiAgIDc0IDAy ICAgICAgICAgICAgICAgICAgICAgamUgICAgIDkgPF9FSVArMHg5PiAwMDAw MDAwOCBCZWZvcmUgZmlyc3Qgc3ltYm9sCkNvZGU7ICAwMDAwMDAwNiBCZWZv cmUgZmlyc3Qgc3ltYm9sCiAgIDc6ICAgNjYgYWIgICAgICAgICAgICAgICAg ICAgICBzdG9zICAgJWF4LCVlczooJWVkaSkKQ29kZTsgIDAwMDAwMDA4IEJl Zm9yZSBmaXJzdCBzeW1ib2wKICAgOTogICBmNiBjMyAwMSAgICAgICAgICAg ICAgICAgIHRlc3QgICAkMHgxLCVibApDb2RlOyAgMDAwMDAwMGMgQmVmb3Jl IGZpcnN0IHN5bWJvbAogICBjOiAgIDc0IDAxICAgICAgICAgICAgICAgICAg ICAgamUgICAgIGYgPF9FSVArMHhmPiAwMDAwMDAwZSBCZWZvcmUgZmlyc3Qg c3ltYm9sCkNvZGU7ICAwMDAwMDAwZSBCZWZvcmUgZmlyc3Qgc3ltYm9sCiAg IGU6ICAgYWEgICAgICAgICAgICAgICAgICAgICAgICBzdG9zICAgJWFsLCVl czooJWVkaSkKQ29kZTsgIDAwMDAwMDBlIEJlZm9yZSBmaXJzdCBzeW1ib2wK ICAgZjogICA4OSBmMCAgICAgICAgICAgICAgICAgICAgIG1vdiAgICAlZXNp LCVlYXgKQ29kZTsgIDAwMDAwMDEwIEJlZm9yZSBmaXJzdCBzeW1ib2wKICAx MTogICA1YiAgICAgICAgICAgICAgICAgICAgICAgIHBvcCAgICAlZWJ4CkNv ZGU7ICAwMDAwMDAxMiBCZWZvcmUgZmlyc3Qgc3ltYm9sCiAgMTI6ICAgNWUg ICAgICAgICAgICAgICAgICAgICAgICBwb3AgICAgJWVzaQpDb2RlOyAgMDAw MDAwMTIgQmVmb3JlIGZpcnN0IHN5bWJvbAogIDEzOiAgIDVmICAgICAgICAg ICAgICAgICAgICAgICAgcG9wICAgICVlZGkKCkp1bCAxNSAyMjozNjoxMiBj dnMga2VybmVsOiAgPDE+VW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFnaW5n IHJlcXVlc3QgYXQgdmlydHVhbCBhZGRyZXNzIGU1MzBjMmMwCkp1bCAxNSAy MjozNjoxMiBjdnMga2VybmVsOiBjMDEyNjZlNApKdWwgMTUgMjI6MzY6MTIg Y3ZzIGtlcm5lbDogKnBkZSA9IDAwMDAwMDAwCkp1bCAxNSAyMjozNjoxMiBj dnMga2VybmVsOiBPb3BzOiAwMDAyCkp1bCAxNSAyMjozNjoxMiBjdnMga2Vy bmVsOiBDUFU6ICAgIDAKSnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6IEVJ UDogICAgMDAxMDpba21lbV9jYWNoZV96YWxsb2MrMTg4LzIxMl0gICAgVGFp bnRlZDogUCAKSnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6IEVGTEFHUzog MDAwMTAyMDYKSnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6IGVheDogMDAw MDAwMDAgICBlYng6IDAwMDAwMDg4ICAgZWN4OiAwMDAwMDAyMiAgIGVkeDog MDAwMDAwMDAKSnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6IGVzaTogZTUz MGMyYzAgICBlZGk6IGU1MzBjMmMwICAgZWJwOiAwMDAwMDBmMCAgIGVzcDog ZDY5NGRiNjAKSnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6IGRzOiAwMDE4 ICAgZXM6IDAwMTggICBzczogMDAxOApKdWwgMTUgMjI6MzY6MTIgY3ZzIGtl cm5lbDogUHJvY2VzcyBjdnMgKHBpZDogMjk1OSwgc3RhY2twYWdlPWQ2OTRk MDAwKQpKdWwgMTUgMjI6MzY6MTIgY3ZzIGtlcm5lbDogU3RhY2s6IDAwMDAw MDAwIDAwMDAwMDA2IDAwMDAwMDAxIGRmNjgzMGUwIGUwODlhNmViIGRmNjgz MGUwIDAwMDAwMGYwIGQ0ZDU4NWZjIApKdWwgMTUgMjI6MzY6MTIgY3ZzIGtl cm5lbDogICAgICAgIGRmN2M5MDAwIGQyMGNlMzQwIDAwMDAwMDA0IGUwOGQ2 MTgzIGRmNjgzMGUwIDAwMDAwMDAxIDA0ODRjMTQyIDAwMDAwMDAwIApKdWwg MTUgMjI6MzY6MTIgY3ZzIGtlcm5lbDogICAgICAgIGUwOGU1OTY4IGQ0ZDU4 NWZjIGRmN2M5MDAwIGQ2OTRkYmY4IDAwMDAwMDAwIDAwMDA4MTI0IGQ2OTRk YzZjIGQ0ZDU4NWZjIApKdWwgMTUgMjI6MzY6MTIgY3ZzIGtlcm5lbDogQ2Fs bCBUcmFjZTogW3hmczpfX2luc21vZF94ZnNfTy9saWIvbW9kdWxlcy8yLjQu MTcteGZzL2tlcm5lbC9mcy94ZnMveGZzLm9fTSstMTA1MTcvOTZdIFt4ZnM6 X19pbnNtb2RfeGZzX1MudGV4dF9MMzc2OTI4KzIzMzc2My8zNzc0NDBdIFt4 ZnM6X19pbnNtb2RfeGZzX1MudGV4dF9MMzc2OTI4KzI5NzIyNC8zNzc0NDBd IFt4ZnM6X19pbnNtb2RfeGZzX1MudGV4dF9MMzc2OTI4KzIyMjYzMS8zNzc0 NDBdIFt4ZnM6X19pbnNtb2RfeGZzX1MudGV4dF9MMzc2OTI4KzMwMDAzMi8z Nzc0NDBdIApKdWwgMTUgMjI6MzY6MTIgY3ZzIGtlcm5lbDogQ29kZTogZjMg YWIgZjYgYzMgMDIgNzQgMDIgNjYgYWIgZjYgYzMgMDEgNzQgMDEgYWEgODkg ZjAgNWIgNWUgNWYgCgpDb2RlOyAgMDAwMDAwMDAgQmVmb3JlIGZpcnN0IHN5 bWJvbAowMDAwMDAwMCA8X0VJUD46CkNvZGU7ICAwMDAwMDAwMCBCZWZvcmUg Zmlyc3Qgc3ltYm9sCiAgIDA6ICAgZjMgYWIgICAgICAgICAgICAgICAgICAg ICByZXB6IHN0b3MgJWVheCwlZXM6KCVlZGkpCkNvZGU7ICAwMDAwMDAwMiBC ZWZvcmUgZmlyc3Qgc3ltYm9sCiAgIDI6ICAgZjYgYzMgMDIgICAgICAgICAg ICAgICAgICB0ZXN0ICAgJDB4MiwlYmwKQ29kZTsgIDAwMDAwMDA0IEJlZm9y ZSBmaXJzdCBzeW1ib2wKICAgNTogICA3NCAwMiAgICAgICAgICAgICAgICAg ICAgIGplICAgICA5IDxfRUlQKzB4OT4gMDAwMDAwMDggQmVmb3JlIGZpcnN0 IHN5bWJvbApDb2RlOyAgMDAwMDAwMDYgQmVmb3JlIGZpcnN0IHN5bWJvbAog ICA3OiAgIDY2IGFiICAgICAgICAgICAgICAgICAgICAgc3RvcyAgICVheCwl ZXM6KCVlZGkpCkNvZGU7ICAwMDAwMDAwOCBCZWZvcmUgZmlyc3Qgc3ltYm9s CiAgIDk6ICAgZjYgYzMgMDEgICAgICAgICAgICAgICAgICB0ZXN0ICAgJDB4 MSwlYmwKQ29kZTsgIDAwMDAwMDBjIEJlZm9yZSBmaXJzdCBzeW1ib2wKICAg YzogICA3NCAwMSAgICAgICAgICAgICAgICAgICAgIGplICAgICBmIDxfRUlQ KzB4Zj4gMDAwMDAwMGUgQmVmb3JlIGZpcnN0IHN5bWJvbApDb2RlOyAgMDAw MDAwMGUgQmVmb3JlIGZpcnN0IHN5bWJvbAogICBlOiAgIGFhICAgICAgICAg ICAgICAgICAgICAgICAgc3RvcyAgICVhbCwlZXM6KCVlZGkpCkNvZGU7ICAw MDAwMDAwZSBCZWZvcmUgZmlyc3Qgc3ltYm9sCiAgIGY6ICAgODkgZjAgICAg ICAgICAgICAgICAgICAgICBtb3YgICAgJWVzaSwlZWF4CkNvZGU7ICAwMDAw MDAxMCBCZWZvcmUgZmlyc3Qgc3ltYm9sCiAgMTE6ICAgNWIgICAgICAgICAg ICAgICAgICAgICAgICBwb3AgICAgJWVieApDb2RlOyAgMDAwMDAwMTIgQmVm b3JlIGZpcnN0IHN5bWJvbAogIDEyOiAgIDVlICAgICAgICAgICAgICAgICAg ICAgICAgcG9wICAgICVlc2kKQ29kZTsgIDAwMDAwMDEyIEJlZm9yZSBmaXJz dCBzeW1ib2wKICAxMzogICA1ZiAgICAgICAgICAgICAgICAgICAgICAgIHBv cCAgICAlZWRpCgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogY3B1OiAw LCBjbG9ja3M6IDk5ODI4NCwgc2xpY2U6IDQ5OTE0MgpKdWwgMTYgMDg6NDI6 NDcgY3ZzIGtlcm5lbDogU0dJIFhGUyB3aXRoIEFDTHMsIEVBcywgbm8gZGVi dWcgZW5hYmxlZAoKMSB3YXJuaW5nIGlzc3VlZC4gIFJlc3VsdHMgbWF5IG5v dCBiZSByZWxpYWJsZS4K --========GMXBoundary326931026816093 Content-Type: application/octet-stream; name="messages" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="messages" SnVsIDE0IDA2OjQ3OjE1IGN2cyBzeXNsb2dkIDEuNC4xIzEwOiByZXN0YXJ0 LgpKdWwgMTQgMDc6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0IDA3OjI2 OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAwNzo0Njo0OSBjdnMgLS0gTUFS SyAtLQpKdWwgMTQgMDg6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0IDA4 OjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAwODo0Njo0OSBjdnMgLS0g TUFSSyAtLQpKdWwgMTQgMDk6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0 IDA5OjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAwOTo0Njo0OSBjdnMg LS0gTUFSSyAtLQpKdWwgMTQgMTA6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVs IDE0IDEwOjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAxMDo0Njo0OSBj dnMgLS0gTUFSSyAtLQpKdWwgMTQgMTE6MDY6NDkgY3ZzIC0tIE1BUksgLS0K SnVsIDE0IDExOjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAxMTo0Njo0 OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTQgMTI6MDY6NDkgY3ZzIC0tIE1BUksg LS0KSnVsIDE0IDEyOjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAxMjo0 Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTQgMTM6MDY6NDkgY3ZzIC0tIE1B UksgLS0KSnVsIDE0IDEzOjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAx Mzo0Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTQgMTQ6MDY6NDkgY3ZzIC0t IE1BUksgLS0KSnVsIDE0IDE0OjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAx NCAxNDo0Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTQgMTU6MDY6NDkgY3Zz IC0tIE1BUksgLS0KSnVsIDE0IDE1OjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1 bCAxNCAxNTo0Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTQgMTY6MDY6NDkg Y3ZzIC0tIE1BUksgLS0KSnVsIDE0IDE2OjI2OjQ5IGN2cyAtLSBNQVJLIC0t Ckp1bCAxNCAxNjo0Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTQgMTc6MDY6 NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0IDE3OjI2OjQ5IGN2cyAtLSBNQVJL IC0tCkp1bCAxNCAxNzo0Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTQgMTg6 MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0IDE4OjI2OjQ5IGN2cyAtLSBN QVJLIC0tCkp1bCAxNCAxODo0Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTQg MTk6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0IDE5OjI2OjQ5IGN2cyAt LSBNQVJLIC0tCkp1bCAxNCAxOTo0Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwg MTQgMjA6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0IDIwOjI2OjQ5IGN2 cyAtLSBNQVJLIC0tCkp1bCAxNCAyMDo0Njo0OSBjdnMgLS0gTUFSSyAtLQpK dWwgMTQgMjE6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0IDIxOjI2OjQ5 IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAyMTo0Njo0OSBjdnMgLS0gTUFSSyAt LQpKdWwgMTQgMjI6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0IDIyOjI2 OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAyMjo0Njo0OSBjdnMgLS0gTUFS SyAtLQpKdWwgMTQgMjM6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE0IDIz OjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNCAyMzo0Njo0OSBjdnMgLS0g TUFSSyAtLQpKdWwgMTUgMDA6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVsIDE1 IDAwOjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAwMDo0Njo0OSBjdnMg LS0gTUFSSyAtLQpKdWwgMTUgMDE6MDY6NDkgY3ZzIC0tIE1BUksgLS0KSnVs IDE1IDAxOjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAwMTo0Njo0OSBj dnMgLS0gTUFSSyAtLQpKdWwgMTUgMDI6MDY6NDkgY3ZzIC0tIE1BUksgLS0K SnVsIDE1IDAyOjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAwMjo0Njo0 OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMDM6MDY6NDkgY3ZzIC0tIE1BUksg LS0KSnVsIDE1IDAzOjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAwMzo0 Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMDQ6MDY6NDkgY3ZzIC0tIE1B UksgLS0KSnVsIDE1IDA0OjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAw NDo0Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMDU6MDY6NDkgY3ZzIC0t IE1BUksgLS0KSnVsIDE1IDA1OjI2OjQ5IGN2cyAtLSBNQVJLIC0tCkp1bCAx NSAwNTo0Njo0OSBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMDY6MDY6NDkgY3Zz IC0tIE1BUksgLS0KSnVsIDE1IDA2OjI1OjA3IGN2cyBzeXNsb2dkIDEuNC4x IzEwOiByZXN0YXJ0LgpKdWwgMTUgMDY6NDY6NTIgY3ZzIC0tIE1BUksgLS0K SnVsIDE1IDA3OjA2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAwNzoyNjo1 MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMDc6NDY6NTIgY3ZzIC0tIE1BUksg LS0KSnVsIDE1IDA4OjA2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAwODoy Njo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMDg6NDY6NTIgY3ZzIC0tIE1B UksgLS0KSnVsIDE1IDA5OjA2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAw OToyNjo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMDk6NDY6NTIgY3ZzIC0t IE1BUksgLS0KSnVsIDE1IDEwOjA2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAx NSAxMDoyNjo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMTA6NDY6NTIgY3Zz IC0tIE1BUksgLS0KSnVsIDE1IDExOjA2OjUyIGN2cyAtLSBNQVJLIC0tCkp1 bCAxNSAxMToyNjo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMTE6NDY6NTIg Y3ZzIC0tIE1BUksgLS0KSnVsIDE1IDEyOjA2OjUyIGN2cyAtLSBNQVJLIC0t Ckp1bCAxNSAxMjoyNjo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMTI6NDY6 NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDEzOjA2OjUyIGN2cyAtLSBNQVJL IC0tCkp1bCAxNSAxMzoyNjo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTUgMTM6 NDY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDE0OjA2OjUyIGN2cyAtLSBN QVJLIC0tCkp1bCAxNSAxNDoyNjo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTUg MTQ6NDY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDE1OjA2OjUyIGN2cyAt LSBNQVJLIC0tCkp1bCAxNSAxNToyNjo1MiBjdnMgLS0gTUFSSyAtLQpKdWwg MTUgMTU6NDY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDE2OjA2OjUyIGN2 cyAtLSBNQVJLIC0tCkp1bCAxNSAxNjoyNjo1MiBjdnMgLS0gTUFSSyAtLQpK dWwgMTUgMTY6NDY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDE3OjA2OjUy IGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAxNzoyNjo1MiBjdnMgLS0gTUFSSyAt LQpKdWwgMTUgMTc6NDY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDE4OjA2 OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAxODoyNjo1MiBjdnMgLS0gTUFS SyAtLQpKdWwgMTUgMTg6NDY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDE5 OjA2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAxOToyNjo1MiBjdnMgLS0g TUFSSyAtLQpKdWwgMTUgMTk6NDY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1 IDIwOjA2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAyMDoxMzozMiBjdnMg a2VybmVsOiAgcHJpbnRpbmcgZWlwOgpKdWwgMTUgMjA6MTM6MzIgY3ZzIGtl cm5lbDogYzAxMjY2ZTQKSnVsIDE1IDIwOjEzOjMyIGN2cyBrZXJuZWw6IE9v cHM6IDAwMDIKSnVsIDE1IDIwOjEzOjMyIGN2cyBrZXJuZWw6IENQVTogICAg MApKdWwgMTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogRUlQOiAgICAwMDEwOltr bWVtX2NhY2hlX3phbGxvYysxODgvMjEyXSAgICBUYWludGVkOiBQIApKdWwg MTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogRUZMQUdTOiAwMDAxMDIwNgpKdWwg MTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogZWF4OiAwMDAwMDAwMCAgIGVieDog MDAwMDAwODggICBlY3g6IDAwMDAwMDIyICAgZWR4OiAwMDAwMDAwMApKdWwg MTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogZXNpOiBlNTMwYzJjMCAgIGVkaTog ZTUzMGMyYzAgICBlYnA6IDAwMDAwMGYwICAgZXNwOiBjNjllYmRkYwpKdWwg MTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogZHM6IDAwMTggICBlczogMDAxOCAg IHNzOiAwMDE4Ckp1bCAxNSAyMDoxMzozMiBjdnMga2VybmVsOiBQcm9jZXNz IHVhZ2VudGQgKHBpZDogMjgzMCwgc3RhY2twYWdlPWM2OWViMDAwKQpKdWwg MTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogU3RhY2s6IDAwMDAwMDAwIDAwMDAw MDA2IDAwMDAwMDAxIGRmNjgzMGUwIGUwODlhNmViIGRmNjgzMGUwIDAwMDAw MGYwIGMxYjBkYTA0IApKdWwgMTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogICAg ICAgIGRmN2M5MDAwIDAwMDAwMDA0IGRmZGU3MGUwIGUwOGQ2MTgzIGRmNjgz MGUwIDAwMDAwMDAxIDAwMDAwMDA0IGMxYjBkYTA0IApKdWwgMTUgMjA6MTM6 MzIgY3ZzIGtlcm5lbDogICAgICAgIGUwOGU1YTYzIGMxYjBkYTA0IGRmN2M5 MDAwIDAwMDAwMDA0IGMxYjBkYTA0IDAwMDAwNzAwIGRmN2M5MDAwIGUwOGU5 MDgzIApKdWwgMTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogQ2FsbCBUcmFjZTog W3hmczpfX2luc21vZF94ZnNfTy9saWIvbW9kdWxlcy8yLjQuMTcteGZzL2tl cm5lbC9mcy94ZnMveGZzLm9fTSstMTA1MTcvOTZdIFt4ZnM6X19pbnNtb2Rf eGZzX1MudGV4dF9MMzc2OTI4KzIzMzc2My8zNzc0NDBdIFt4ZnM6X19pbnNt b2RfeGZzX1MudGV4dF9MMzc2OTI4KzI5NzQ3NS8zNzc0NDBdIFt4ZnM6X19p bnNtb2RfeGZzX1MudGV4dF9MMzc2OTI4KzMxMTMzMS8zNzc0NDBdIFt4ZnM6 X19pbnNtb2RfeGZzX1MudGV4dF9MMzc2OTI4KzM1NjAyNi8zNzc0NDBdIApK dWwgMTUgMjA6MTM6MzIgY3ZzIGtlcm5lbDogICAgWzxlMDhmZGM4MD5dIFtu b3RpZnlfY2hhbmdlKzc2LzIwOF0gW3N5c191dGltZSsxNzEvMTk2XSBbZmls cF9jbG9zZSs5Mi8xMDBdIFtzeXNfY2xvc2UrNjcvODRdIFtzeXN0ZW1fY2Fs bCs1MS81Nl0gCkp1bCAxNSAyMDoxMzozMiBjdnMga2VybmVsOiAKSnVsIDE1 IDIwOjEzOjMyIGN2cyBrZXJuZWw6IENvZGU6IGYzIGFiIGY2IGMzIDAyIDc0 IDAyIDY2IGFiIGY2IGMzIDAxIDc0IDAxIGFhIDg5IGYwIDViIDVlIDVmIApK dWwgMTUgMjA6MjY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDIwOjQ2OjUy IGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAyMTowNjo1MiBjdnMgLS0gTUFSSyAt LQpKdWwgMTUgMjE6MjY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDIxOjQ2 OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAyMjowNjo1MiBjdnMgLS0gTUFS SyAtLQpKdWwgMTUgMjI6MjY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDIy OjMyOjM4IGN2cyBrZXJuZWw6ICA8MT5VbmFibGUgdG8gaGFuZGxlIGtlcm5l bCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgZTUzMGMyYzAK SnVsIDE1IDIyOjMyOjM4IGN2cyBrZXJuZWw6ICBwcmludGluZyBlaXA6Ckp1 bCAxNSAyMjozMjozOCBjdnMga2VybmVsOiBjMDEyNjZlNApKdWwgMTUgMjI6 MzI6MzggY3ZzIGtlcm5lbDogT29wczogMDAwMgpKdWwgMTUgMjI6MzI6Mzgg Y3ZzIGtlcm5lbDogQ1BVOiAgICAwCkp1bCAxNSAyMjozMjozOCBjdnMga2Vy bmVsOiBFSVA6ICAgIDAwMTA6W2ttZW1fY2FjaGVfemFsbG9jKzE4OC8yMTJd ICAgIFRhaW50ZWQ6IFAgCkp1bCAxNSAyMjozMjozOCBjdnMga2VybmVsOiBF RkxBR1M6IDAwMDEwMjA2Ckp1bCAxNSAyMjozMjozOCBjdnMga2VybmVsOiBl YXg6IDAwMDAwMDAwICAgZWJ4OiAwMDAwMDA4OCAgIGVjeDogMDAwMDAwMjIg ICBlZHg6IDAwMDAwMDAwCkp1bCAxNSAyMjozMjozOCBjdnMga2VybmVsOiBl c2k6IGU1MzBjMmMwICAgZWRpOiBlNTMwYzJjMCAgIGVicDogMDAwMDAwZjAg ICBlc3A6IGNhNDEzYjYwCkp1bCAxNSAyMjozMjozOCBjdnMga2VybmVsOiBk czogMDAxOCAgIGVzOiAwMDE4ICAgc3M6IDAwMTgKSnVsIDE1IDIyOjMyOjM4 IGN2cyBrZXJuZWw6IFByb2Nlc3MgY3ZzIChwaWQ6IDI5NTMsIHN0YWNrcGFn ZT1jYTQxMzAwMCkKSnVsIDE1IDIyOjMyOjM4IGN2cyBrZXJuZWw6IFN0YWNr OiAwMDAwMDAwMCAwMDAwMDAwNiAwMDAwMDAwMSBkZjY4MzBlMCBlMDg5YTZl YiBkZjY4MzBlMCAwMDAwMDBmMCBkZTlkNjk4NCAKSnVsIDE1IDIyOjMyOjM4 IGN2cyBrZXJuZWw6ICAgICAgICBkZjdjOTAwMCBkZmRlN2VhMCAwMDAwMDAw NCBlMDhkNjE4MyBkZjY4MzBlMCAwMDAwMDAwMSAwNTQwMDE3NiAwMDAwMDAw MCAKSnVsIDE1IDIyOjMyOjM4IGN2cyBrZXJuZWw6ICAgICAgICBlMDhlNTk2 OCBkZTlkNjk4NCBkZjdjOTAwMCBjYTQxM2JmOCAwMDAwMDAwMCAwMDAwODFi NiBjYTQxM2M2YyBkZTlkNjk4NCAKSnVsIDE1IDIyOjMyOjM4IGN2cyBrZXJu ZWw6IENhbGwgVHJhY2U6IFt4ZnM6X19pbnNtb2RfeGZzX08vbGliL21vZHVs ZXMvMi40LjE3LXhmcy9rZXJuZWwvZnMveGZzL3hmcy5vX00rLTEwNTE3Lzk2 XSBbeGZzOl9faW5zbW9kX3hmc19TLnRleHRfTDM3NjkyOCsyMzM3NjMvMzc3 NDQwXSBbeGZzOl9faW5zbW9kX3hmc19TLnRleHRfTDM3NjkyOCsyOTcyMjQv Mzc3NDQwXSBbeGZzOl9faW5zbW9kX3hmc19TLnRleHRfTDM3NjkyOCsyMjI2 MzEvMzc3NDQwXSBbeGZzOl9faW5zbW9kX3hmc19TLnRleHRfTDM3NjkyOCsz MDAwMzIvMzc3NDQwXSAKSnVsIDE1IDIyOjMyOjM4IGN2cyBrZXJuZWw6ICAg IFt4ZnM6X19pbnNtb2RfeGZzX1MudGV4dF9MMzc2OTI4KzMxODU0MC8zNzc0 NDBdIFt4ZnM6X19pbnNtb2RfeGZzX1Mucm9kYXRhX0wxNTQ3Nis2NC8xNTk2 OF0gW3hmczpfX2luc21vZF94ZnNfUy50ZXh0X0wzNzY5MjgrMzUzMDUxLzM3 NzQ0MF0gW3hmczpfX2luc21vZF94ZnNfUy50ZXh0X0wzNzY5MjgrNDQ1NC8z Nzc0NDBdIFs8ZTA4ZmRjODA+XSBbeGZzOl9faW5zbW9kX3hmc19TLnRleHRf TDM3NjkyOCsyNzU4NjQvMzc3NDQwXSAKSnVsIDE1IDIyOjMyOjM4IGN2cyBr ZXJuZWw6ICAgIFt4ZnM6X19pbnNtb2RfeGZzX1MudGV4dF9MMzc2OTI4KzM1 MzM3Mi8zNzc0NDBdIFt2ZnNfY3JlYXRlKzExMy8xNjRdIFtvcGVuX25hbWVp KzM1MS8xMzE2XSBbZmlscF9vcGVuKzU5LzkyXSBbc3lzX29wZW4rNTQvMTQ4 XSBbc3lzdGVtX2NhbGwrNTEvNTZdIApKdWwgMTUgMjI6MzI6MzggY3ZzIGtl cm5lbDogCkp1bCAxNSAyMjozMjozOCBjdnMga2VybmVsOiBDb2RlOiBmMyBh YiBmNiBjMyAwMiA3NCAwMiA2NiBhYiBmNiBjMyAwMSA3NCAwMSBhYSA4OSBm MCA1YiA1ZSA1ZiAKSnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6ICA8MT5V bmFibGUgdG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0 dWFsIGFkZHJlc3MgZTUzMGMyYzAKSnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJu ZWw6ICBwcmludGluZyBlaXA6Ckp1bCAxNSAyMjozNjoxMiBjdnMga2VybmVs OiBjMDEyNjZlNApKdWwgMTUgMjI6MzY6MTIgY3ZzIGtlcm5lbDogT29wczog MDAwMgpKdWwgMTUgMjI6MzY6MTIgY3ZzIGtlcm5lbDogQ1BVOiAgICAwCkp1 bCAxNSAyMjozNjoxMiBjdnMga2VybmVsOiBFSVA6ICAgIDAwMTA6W2ttZW1f Y2FjaGVfemFsbG9jKzE4OC8yMTJdICAgIFRhaW50ZWQ6IFAgCkp1bCAxNSAy MjozNjoxMiBjdnMga2VybmVsOiBFRkxBR1M6IDAwMDEwMjA2Ckp1bCAxNSAy MjozNjoxMiBjdnMga2VybmVsOiBlYXg6IDAwMDAwMDAwICAgZWJ4OiAwMDAw MDA4OCAgIGVjeDogMDAwMDAwMjIgICBlZHg6IDAwMDAwMDAwCkp1bCAxNSAy MjozNjoxMiBjdnMga2VybmVsOiBlc2k6IGU1MzBjMmMwICAgZWRpOiBlNTMw YzJjMCAgIGVicDogMDAwMDAwZjAgICBlc3A6IGQ2OTRkYjYwCkp1bCAxNSAy MjozNjoxMiBjdnMga2VybmVsOiBkczogMDAxOCAgIGVzOiAwMDE4ICAgc3M6 IDAwMTgKSnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6IFByb2Nlc3MgY3Zz IChwaWQ6IDI5NTksIHN0YWNrcGFnZT1kNjk0ZDAwMCkKSnVsIDE1IDIyOjM2 OjEyIGN2cyBrZXJuZWw6IFN0YWNrOiAwMDAwMDAwMCAwMDAwMDAwNiAwMDAw MDAwMSBkZjY4MzBlMCBlMDg5YTZlYiBkZjY4MzBlMCAwMDAwMDBmMCBkNGQ1 ODVmYyAKSnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6ICAgICAgICBkZjdj OTAwMCBkMjBjZTM0MCAwMDAwMDAwNCBlMDhkNjE4MyBkZjY4MzBlMCAwMDAw MDAwMSAwNDg0YzE0MiAwMDAwMDAwMCAKSnVsIDE1IDIyOjM2OjEyIGN2cyBr ZXJuZWw6ICAgICAgICBlMDhlNTk2OCBkNGQ1ODVmYyBkZjdjOTAwMCBkNjk0 ZGJmOCAwMDAwMDAwMCAwMDAwODEyNCBkNjk0ZGM2YyBkNGQ1ODVmYyAKSnVs IDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6IENhbGwgVHJhY2U6IFt4ZnM6X19p bnNtb2RfeGZzX08vbGliL21vZHVsZXMvMi40LjE3LXhmcy9rZXJuZWwvZnMv eGZzL3hmcy5vX00rLTEwNTE3Lzk2XSBbeGZzOl9faW5zbW9kX3hmc19TLnRl eHRfTDM3NjkyOCsyMzM3NjMvMzc3NDQwXSBbeGZzOl9faW5zbW9kX3hmc19T LnRleHRfTDM3NjkyOCsyOTcyMjQvMzc3NDQwXSBbeGZzOl9faW5zbW9kX3hm c19TLnRleHRfTDM3NjkyOCsyMjI2MzEvMzc3NDQwXSBbeGZzOl9faW5zbW9k X3hmc19TLnRleHRfTDM3NjkyOCszMDAwMzIvMzc3NDQwXSAKSnVsIDE1IDIy OjM2OjEyIGN2cyBrZXJuZWw6ICAgIFt4ZnM6X19pbnNtb2RfeGZzX1MudGV4 dF9MMzc2OTI4KzMxODU0MC8zNzc0NDBdIFt4ZnM6X19pbnNtb2RfeGZzX1Mu cm9kYXRhX0wxNTQ3Nis2NC8xNTk2OF0gW3hmczpfX2luc21vZF94ZnNfUy50 ZXh0X0wzNzY5MjgrMzUzMDUxLzM3NzQ0MF0gW3hmczpfX2luc21vZF94ZnNf Uy50ZXh0X0wzNzY5MjgrNDQ1NC8zNzc0NDBdIFs8ZTA4ZmRjODA+XSBbeGZz Ol9faW5zbW9kX3hmc19TLnRleHRfTDM3NjkyOCsyNzU4NjQvMzc3NDQwXSAK SnVsIDE1IDIyOjM2OjEyIGN2cyBrZXJuZWw6ICAgIFt4ZnM6X19pbnNtb2Rf eGZzX1MudGV4dF9MMzc2OTI4KzM1MzM3Mi8zNzc0NDBdIFt2ZnNfY3JlYXRl KzExMy8xNjRdIFtvcGVuX25hbWVpKzM1MS8xMzE2XSBbZmlscF9vcGVuKzU5 LzkyXSBbc3lzX29wZW4rNTQvMTQ4XSBbc3lzdGVtX2NhbGwrNTEvNTZdIApK dWwgMTUgMjI6MzY6MTIgY3ZzIGtlcm5lbDogCkp1bCAxNSAyMjozNjoxMiBj dnMga2VybmVsOiBDb2RlOiBmMyBhYiBmNiBjMyAwMiA3NCAwMiA2NiBhYiBm NiBjMyAwMSA3NCAwMSBhYSA4OSBmMCA1YiA1ZSA1ZiAKSnVsIDE1IDIyOjQ2 OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNSAyMzowNjo1MiBjdnMgLS0gTUFS SyAtLQpKdWwgMTUgMjM6MjY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE1IDIz OjQ2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNiAwMDowNjo1MiBjdnMgLS0g TUFSSyAtLQpKdWwgMTYgMDA6MjY6NTIgY3ZzIC0tIE1BUksgLS0KSnVsIDE2 IDAwOjQ2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNiAwMTowNjo1MiBjdnMg LS0gTUFSSyAtLQpKdWwgMTYgMDE6MjY6NTIgY3ZzIC0tIE1BUksgLS0KSnVs IDE2IDAxOjQ2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNiAwMjowNjo1MiBj dnMgLS0gTUFSSyAtLQpKdWwgMTYgMDI6MjY6NTIgY3ZzIC0tIE1BUksgLS0K SnVsIDE2IDAyOjQ2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNiAwMzowNjo1 MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTYgMDM6MjY6NTIgY3ZzIC0tIE1BUksg LS0KSnVsIDE2IDAzOjQ2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNiAwNDow Njo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTYgMDQ6MjY6NTIgY3ZzIC0tIE1B UksgLS0KSnVsIDE2IDA0OjQ2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAxNiAw NTowNjo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTYgMDU6MjY6NTIgY3ZzIC0t IE1BUksgLS0KSnVsIDE2IDA1OjQ2OjUyIGN2cyAtLSBNQVJLIC0tCkp1bCAx NiAwNjowNjo1MiBjdnMgLS0gTUFSSyAtLQpKdWwgMTYgMDY6MjU6NDAgY3Zz IHN5c2xvZ2QgMS40LjEjMTA6IHJlc3RhcnQuCkp1bCAxNiAwNjo0Njo1NSBj dnMgLS0gTUFSSyAtLQpKdWwgMTYgMDc6MDY6NTUgY3ZzIC0tIE1BUksgLS0K SnVsIDE2IDA3OjI2OjU1IGN2cyAtLSBNQVJLIC0tCkp1bCAxNiAwNzo0Njo1 NSBjdnMgLS0gTUFSSyAtLQpKdWwgMTYgMDg6NDI6NDYgY3ZzIHN5c2xvZ2Qg MS40LjEjMTA6IHJlc3RhcnQuCkp1bCAxNiAwODo0Mjo0NiBjdnMga2VybmVs OiBrbG9nZCAxLjQuMSMxMCwgbG9nIHNvdXJjZSA9IC9wcm9jL2ttc2cgc3Rh cnRlZC4KSnVsIDE2IDA4OjQyOjQ2IGN2cyBrZXJuZWw6IEluc3BlY3Rpbmcg L2Jvb3QvU3lzdGVtLm1hcC0yLjQuMTcteGZzCkp1bCAxNiAwODo0Mjo0NyBj dnMga2VybmVsOiBMb2FkZWQgMTI4NTUgc3ltYm9scyBmcm9tIC9ib290L1N5 c3RlbS5tYXAtMi40LjE3LXhmcy4KSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJu ZWw6IFN5bWJvbHMgbWF0Y2gga2VybmVsIHZlcnNpb24gMi40LjE3LgpKdWwg MTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogTG9hZGVkIDEyNCBzeW1ib2xzIGZy b20gNiBtb2R1bGVzLgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogTGlu dXggdmVyc2lvbiAyLjQuMTcteGZzIChyb290QGN2cy1uZXcpIChnY2MgdmVy c2lvbiAyLjk1LjQgKERlYmlhbiBwcmVyZWxlYXNlKSkgIzIgRnJpIEphbiAy NSAxMDoxMToxMyBDRVQgMjAwMgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5l bDogQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgpKdWwgMTYgMDg6 NDI6NDcgY3ZzIGtlcm5lbDogIEJJT1MtZTgyMDogMDAwMDAwMDAwMDAwMDAw MCAtIDAwMDAwMDAwMDAwOWZjMDAgKHVzYWJsZSkKSnVsIDE2IDA4OjQyOjQ3 IGN2cyBrZXJuZWw6ICBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwOWZjMDAgLSAw MDAwMDAwMDAwMGEwMDAwIChyZXNlcnZlZCkKSnVsIDE2IDA4OjQyOjQ3IGN2 cyBrZXJuZWw6ICBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAw MDAwMDAwMTAwMDAwIChyZXNlcnZlZCkKSnVsIDE2IDA4OjQyOjQ3IGN2cyBr ZXJuZWw6ICBCSU9TLWU4MjA6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAw MDIwMDAwMDAwICh1c2FibGUpCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVs OiAgQklPUy1lODIwOiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMw MTAwMCAocmVzZXJ2ZWQpCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiAg QklPUy1lODIwOiAwMDAwMDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUwMTAw MCAocmVzZXJ2ZWQpCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiAgQklP Uy1lODIwOiAwMDAwMDAwMGZmZmMwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAo cmVzZXJ2ZWQpCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBmb3VuZCBT TVAgTVAtdGFibGUgYXQgMDAwZmI0NjAKSnVsIDE2IDA4OjQyOjQ3IGN2cyBr ZXJuZWw6IGhtLCBwYWdlIDAwMGZiMDAwIHJlc2VydmVkIHR3aWNlLgpKdWwg MTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogaG0sIHBhZ2UgMDAwZmMwMDAgcmVz ZXJ2ZWQgdHdpY2UuCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBobSwg cGFnZSAwMDBmNTAwMCByZXNlcnZlZCB0d2ljZS4KSnVsIDE2IDA4OjQyOjQ3 IGN2cyBrZXJuZWw6IGhtLCBwYWdlIDAwMGY2MDAwIHJlc2VydmVkIHR3aWNl LgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogT24gbm9kZSAwIHRvdGFs cGFnZXM6IDEzMTA3MgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogem9u ZSgwKTogNDA5NiBwYWdlcy4KSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6 IHpvbmUoMSk6IDEyNjk3NiBwYWdlcy4KSnVsIDE2IDA4OjQyOjQ3IGN2cyBr ZXJuZWw6IHpvbmUoMik6IDAgcGFnZXMuCkp1bCAxNiAwODo0Mjo0NyBjdnMg a2VybmVsOiBJbnRlbCBNdWx0aVByb2Nlc3NvciBTcGVjaWZpY2F0aW9uIHYx LjQKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6ICAgICBWaXJ0dWFsIFdp cmUgY29tcGF0aWJpbGl0eSBtb2RlLgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtl cm5lbDogT0VNIElEOiBJTlRFTCAgICBQcm9kdWN0IElEOiA0NDBCWCAgICAg ICAgQVBJQyBhdDogMHhGRUUwMDAwMApKdWwgMTYgMDg6NDI6NDcgY3ZzIGtl cm5lbDogUHJvY2Vzc29yICMwIFBlbnRpdW0odG0pIFBybyBBUElDIHZlcnNp b24gMTcKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IEkvTyBBUElDICMy IFZlcnNpb24gMTcgYXQgMHhGRUMwMDAwMC4KSnVsIDE2IDA4OjQyOjQ3IGN2 cyBrZXJuZWw6IFByb2Nlc3NvcnM6IDEKSnVsIDE2IDA4OjQyOjQ3IGN2cyBr ZXJuZWw6IEtlcm5lbCBjb21tYW5kIGxpbmU6IGF1dG8gQk9PVF9JTUFHRT0x IHJvIHJvb3Q9ODAxCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBJbml0 aWFsaXppbmcgQ1BVIzAKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IERl dGVjdGVkIDM5OS4zMjggTUh6IHByb2Nlc3Nvci4KSnVsIDE2IDA4OjQyOjQ3 IGN2cyBrZXJuZWw6IENvbnNvbGU6IGNvbG91ciBWR0ErIDgweDUwCkp1bCAx NiAwODo0Mjo0NyBjdnMga2VybmVsOiBDYWxpYnJhdGluZyBkZWxheSBsb29w Li4uIDc5Ni4yNiBCb2dvTUlQUwpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5l bDogTWVtb3J5OiA1MTQzNDBrLzUyNDI4OGsgYXZhaWxhYmxlICg3MjdrIGtl cm5lbCBjb2RlLCA5NTYwayByZXNlcnZlZCwgMTg1ayBkYXRhLCAyMDBrIGlu aXQsIDBrIGhpZ2htZW0pCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBE ZW50cnktY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6 IDcsIDUyNDI4OCBieXRlcykKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6 IElub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMzI3NjggKG9yZGVy OiA2LCAyNjIxNDQgYnl0ZXMpCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVs OiBNb3VudC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDgxOTIgKG9yZGVy OiA0LCA2NTUzNiBieXRlcykKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6 IEJ1ZmZlci1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRl cjogNSwgMTMxMDcyIGJ5dGVzKQpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5l bDogUGFnZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3Jk ZXI6IDcsIDUyNDI4OCBieXRlcykKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJu ZWw6IENQVTogTDEgSSBjYWNoZTogMTZLLCBMMSBEIGNhY2hlOiAxNksKSnVs IDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IENQVTogTDIgY2FjaGU6IDUxMksK SnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IEludGVsIG1hY2hpbmUgY2hl Y2sgYXJjaGl0ZWN0dXJlIHN1cHBvcnRlZC4KSnVsIDE2IDA4OjQyOjQ3IGN2 cyBrZXJuZWw6IEludGVsIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJs ZWQgb24gQ1BVIzAuCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBDUFU6 IEludGVsIFBlbnRpdW0gSUkgKERlc2NodXRlcykgc3RlcHBpbmcgMDIKSnVs IDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IEVuYWJsaW5nIGZhc3QgRlBVIHNh dmUgYW5kIHJlc3RvcmUuLi4gZG9uZS4KSnVsIDE2IDA4OjQyOjQ3IGN2cyBr ZXJuZWw6IENoZWNraW5nICdobHQnIGluc3RydWN0aW9uLi4uIE9LLgpKdWwg MTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogUE9TSVggY29uZm9ybWFuY2UgdGVz dGluZyBieSBVTklGSVgKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IGVu YWJsZWQgRXh0SU5UIG9uIENQVSMwCkp1bCAxNiAwODo0Mjo0NyBjdnMga2Vy bmVsOiBFU1IgdmFsdWUgYmVmb3JlIGVuYWJsaW5nIHZlY3RvcjogMDAwMDAw MDQKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IEVTUiB2YWx1ZSBhZnRl ciBlbmFibGluZyB2ZWN0b3I6IDAwMDAwMDAwCkp1bCAxNiAwODo0Mjo0NyBj dnMga2VybmVsOiBFTkFCTElORyBJTy1BUElDIElSUXMKSnVsIDE2IDA4OjQy OjQ3IGN2cyBrZXJuZWw6IFNldHRpbmcgMiBpbiB0aGUgcGh5c19pZF9wcmVz ZW50X21hcApKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogLi4uY2hhbmdp bmcgSU8tQVBJQyBwaHlzaWNhbCBBUElDIElEIHRvIDIgLi4uIG9rLgpKdWwg MTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogLi5USU1FUjogdmVjdG9yPTB4MzEg cGluMT0yIHBpbjI9MApKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogdGVz dGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uCkp1bCAx NiAwODo0Mjo0NyBjdnMga2VybmVsOiAKSnVsIDE2IDA4OjQyOjQ3IGN2cyBr ZXJuZWw6IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBk b25lLgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogVXNpbmcgbG9jYWwg QVBJQyB0aW1lciBpbnRlcnJ1cHRzLgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtl cm5lbDogY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4KSnVsIDE2IDA4OjQy OjQ3IGN2cyBrZXJuZWw6IC4uLi4uIENQVSBjbG9jayBzcGVlZCBpcyAzOTku MzE0NiBNSHouCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiAuLi4uLiBo b3N0IGJ1cyBjbG9jayBzcGVlZCBpcyA5OS44Mjg0IE1Iei4KSnVsIDE2IDA4 OjQyOjQ3IGN2cyBrZXJuZWw6IGNwdTogMCwgY2xvY2tzOiA5OTgyODQsIHNs aWNlOiA0OTkxNDIKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IENQVTA8 VDA6OTk4MjcyLFQxOjQ5OTEyMCxEOjEwLFM6NDk5MTQyLEM6OTk4Mjg0PgpK dWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogbXRycjogdjEuNDAgKDIwMDEw MzI3KSBSaWNoYXJkIEdvb2NoIChyZ29vY2hAYXRuZi5jc2lyby5hdSkKSnVs IDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IG10cnI6IGRldGVjdGVkIG10cnIg dHlwZTogSW50ZWwKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IFBDSTog UENJIEJJT1MgcmV2aXNpb24gMi4xMCBlbnRyeSBhdCAweGZkYWMxLCBsYXN0 IGJ1cz0yCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBQQ0k6IFVzaW5n IGNvbmZpZ3VyYXRpb24gdHlwZSAxCkp1bCAxNiAwODo0Mjo0NyBjdnMga2Vy bmVsOiBQQ0k6IFByb2JpbmcgUENJIGhhcmR3YXJlCkp1bCAxNiAwODo0Mjo0 NyBjdnMga2VybmVsOiBQQ0ktPkFQSUMgSVJRIHRyYW5zZm9ybTogKEIwLEk3 LFAzKSAtPiAxOQpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogUENJLT5B UElDIElSUSB0cmFuc2Zvcm06IChCMCxJMTYsUDApIC0+IDE3Ckp1bCAxNiAw ODo0Mjo0NyBjdnMga2VybmVsOiBQQ0ktPkFQSUMgSVJRIHRyYW5zZm9ybTog KEIwLEkxOCxQMCkgLT4gMTkKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6 IFBDSS0+QVBJQyBJUlEgdHJhbnNmb3JtOiAoQjEsSTAsUDApIC0+IDExCkp1 bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBMaW51eCBORVQ0LjAgZm9yIExp bnV4IDIuNApKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogQmFzZWQgdXBv biBTd2Fuc2VhIFVuaXZlcnNpdHkgQ29tcHV0ZXIgU29jaWV0eSBORVQzLjAz OQpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogSW5pdGlhbGl6aW5nIFJU IG5ldGxpbmsgc29ja2V0Ckp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBT dGFydGluZyBrc3dhcGQKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IHB0 eTogMjU2IFVuaXg5OCBwdHlzIGNvbmZpZ3VyZWQKSnVsIDE2IDA4OjQyOjQ3 IGN2cyBrZXJuZWw6IGJsb2NrOiAxMjggc2xvdHMgcGVyIHF1ZXVlLCBiYXRj aD0zMgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogU0NTSSBzdWJzeXN0 ZW0gZHJpdmVyIFJldmlzaW9uOiAxLjAwCkp1bCAxNiAwODo0Mjo0NyBjdnMg a2VybmVsOiBDb25maWd1cmluZyBHRFQtUENJIEhBIGF0IDAvMTYgSVJRIDE3 Ckp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBzY3NpMCA6IEdEVDY1MTNS UwpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogICBWZW5kb3I6IElDUCAg ICAgICBNb2RlbDogSG9zdCBEcml2ZSAgIzAwICAgUmV2OiAgICAgCkp1bCAx NiAwODo0Mjo0NyBjdnMga2VybmVsOiAgIFR5cGU6ICAgRGlyZWN0LUFjY2Vz cyAgICAgICAgICAgICAgICAgICAgICBBTlNJIFNDU0kgcmV2aXNpb246IDAy Ckp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiAgIFZlbmRvcjogSUNQICAg ICAgIE1vZGVsOiBIb3N0IERyaXZlICAjMDEgICBSZXY6ICAgICAKSnVsIDE2 IDA4OjQyOjQ3IGN2cyBrZXJuZWw6ICAgVHlwZTogICBEaXJlY3QtQWNjZXNz ICAgICAgICAgICAgICAgICAgICAgIEFOU0kgU0NTSSByZXZpc2lvbjogMDIK SnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IEF0dGFjaGVkIHNjc2kgZGlz ayBzZGEgYXQgc2NzaTAsIGNoYW5uZWwgMCwgaWQgMCwgbHVuIDAKSnVsIDE2 IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IEF0dGFjaGVkIHNjc2kgZGlzayBzZGIg YXQgc2NzaTAsIGNoYW5uZWwgMCwgaWQgMSwgbHVuIDAKSnVsIDE2IDA4OjQy OjQ3IGN2cyBrZXJuZWw6IFNDU0kgZGV2aWNlIHNkYTogMTcxODk1NTAgNTEy LWJ5dGUgaGR3ciBzZWN0b3JzICg4ODAxIE1CKQpKdWwgMTYgMDg6NDI6NDcg Y3ZzIGtlcm5lbDogUGFydGl0aW9uIGNoZWNrOgpKdWwgMTYgMDg6NDI6NDcg Y3ZzIGtlcm5lbDogIHNkYTogc2RhMSBzZGEyIHNkYTMgc2RhNApKdWwgMTYg MDg6NDI6NDcgY3ZzIGtlcm5lbDogU0NTSSBkZXZpY2Ugc2RiOiA2ODgwNjM5 NSA1MTItYnl0ZSBoZHdyIHNlY3RvcnMgKDM1MjI5IE1CKQpKdWwgMTYgMDg6 NDI6NDcgY3ZzIGtlcm5lbDogIHNkYjogc2RiMQpKdWwgMTYgMDg6NDI6NDcg Y3ZzIGtlcm5lbDogTkVUNDogTGludXggVENQL0lQIDEuMCBmb3IgTkVUNC4w Ckp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBJUCBQcm90b2NvbHM6IElD TVAsIFVEUCwgVENQCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBJUDog cm91dGluZyBjYWNoZSBoYXNoIHRhYmxlIG9mIDQwOTYgYnVja2V0cywgMzJL Ynl0ZXMKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IFRDUDogSGFzaCB0 YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgMTMxMDcyIGJpbmQgNjU1 MzYpCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBORVQ0OiBVbml4IGRv bWFpbiBzb2NrZXRzIDEuMC9TTVAgZm9yIExpbnV4IE5FVDQuMC4KSnVsIDE2 IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IFZGUzogTW91bnRlZCByb290IChleHQy IGZpbGVzeXN0ZW0pIHJlYWRvbmx5LgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtl cm5lbDogRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMjAwayBmcmVl ZApKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogQWRkaW5nIFN3YXA6IDk5 NjAyMGsgc3dhcC1zcGFjZSAocHJpb3JpdHkgLTEpCkp1bCAxNiAwODo0Mjo0 NyBjdnMga2VybmVsOiBSZWFsIFRpbWUgQ2xvY2sgRHJpdmVyIHYxLjEwZQpK dWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogdmlhLXJoaW5lLmM6djEuMTAt TEsxLjEuMTIgIDAzLzExLzIwMDEgIFdyaXR0ZW4gYnkgRG9uYWxkIEJlY2tl cgpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogICBodHRwOi8vd3d3LnNj eWxkLmNvbS9uZXR3b3JrL3ZpYS1yaGluZS5odG1sCkp1bCAxNiAwODo0Mjo0 NyBjdnMga2VybmVsOiBldGgwOiBWSUEgVlQzMDQzIFJoaW5lIGF0IDB4ZTg4 MCwgMDA6NTA6YmE6YTg6ZmI6YmUsIElSUSAxOS4KSnVsIDE2IDA4OjQyOjQ3 IGN2cyBrZXJuZWw6IGV0aDA6IE1JSSBQSFkgZm91bmQgYXQgYWRkcmVzcyA4 LCBzdGF0dXMgMHg3ODJkIGFkdmVydGlzaW5nIDA1ZTEgTGluayA0NWUxLgpK dWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogU2VyaWFsIGRyaXZlciB2ZXJz aW9uIDUuMDVjICgyMDAxLTA3LTA4KSB3aXRoIE1BTllfUE9SVFMgU0hBUkVf SVJRIFNFUklBTF9QQ0kgZW5hYmxlZApKdWwgMTYgMDg6NDI6NDcgY3ZzIGtl cm5lbDogdHR5UzAwIGF0IDB4MDNmOCAoaXJxID0gNCkgaXMgYSAxNjU1MEEK SnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6IHR0eVMwMSBhdCAweDAyZjgg KGlycSA9IDMpIGlzIGEgMTY1NTBBCkp1bCAxNiAwODo0Mjo0NyBjdnMga2Vy bmVsOiBTR0kgWEZTIHdpdGggQUNMcywgRUFzLCBubyBkZWJ1ZyBlbmFibGVk Ckp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBYRlMgbW91bnRpbmcgZmls ZXN5c3RlbSBzZCg4LDQpCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBT dGFydGluZyBYRlMgcmVjb3Zlcnkgb24gZmlsZXN5c3RlbTogc2QoOCw0KSAo ZGV2OiA4LzQpCkp1bCAxNiAwODo0Mjo0NyBjdnMga2VybmVsOiBFbmRpbmcg WEZTIHJlY292ZXJ5IG9uIGZpbGVzeXN0ZW06IHNkKDgsNCkgKGRldjogOC80 KQpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogWEZTIG1vdW50aW5nIGZp bGVzeXN0ZW0gc2QoOCwxNykKSnVsIDE2IDA4OjQyOjQ3IGN2cyBrZXJuZWw6 IFN0YXJ0aW5nIFhGUyByZWNvdmVyeSBvbiBmaWxlc3lzdGVtOiBzZCg4LDE3 KSAoZGV2OiA4LzE3KQpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogRW5k aW5nIFhGUyByZWNvdmVyeSBvbiBmaWxlc3lzdGVtOiBzZCg4LDE3KSAoZGV2 OiA4LzE3KQpKdWwgMTYgMDg6NDI6NDcgY3ZzIGtlcm5lbDogZXRoMDogU2V0 dGluZyBmdWxsLWR1cGxleCBiYXNlZCBvbiBNSUkgIzggbGluayBwYXJ0bmVy IGNhcGFiaWxpdHkgb2YgNDVlMS4KSnVsIDE2IDA5OjAyOjQ2IGN2cyAtLSBN QVJLIC0tCkp1bCAxNiAwOToyMjo0NiBjdnMgLS0gTUFSSyAtLQpKdWwgMTYg MDk6NDI6NDYgY3ZzIC0tIE1BUksgLS0KSnVsIDE2IDEwOjAyOjQ2IGN2cyAt LSBNQVJLIC0tCkp1bCAxNiAxMDoyMjo0NiBjdnMgLS0gTUFSSyAtLQpKdWwg MTYgMTA6NDI6NDYgY3ZzIC0tIE1BUksgLS0K --========GMXBoundary326931026816093-- From owner-linux-xfs@oss.sgi.com Tue Jul 16 04:55:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GBtrRw028430 for ; Tue, 16 Jul 2002 04:55:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GBtrJA028429 for linux-xfs-outgoing; Tue, 16 Jul 2002 04:55:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailman.mnd.com (adsfw.mnd.com [208.226.69.17] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GBtkRw028401 for ; Tue, 16 Jul 2002 04:55:47 -0700 Received: from alpha2.production.mnd.com (alpha2 [192.168.3.105]) by mailman.mnd.com (8.11.6/8.9.3) with ESMTP id g6GBw6A10488 for ; Tue, 16 Jul 2002 06:58:07 -0500 Date: Tue, 16 Jul 2002 06:57:21 -0500 (CDT) From: Chris Bednar X-Sender: cjb@alpha2.production.mnd.com To: linux-xfs@oss.sgi.com Subject: Re: "raid5: multiple 1 requests for sector ..." In-Reply-To: <200108272236.f7RMarn16012@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I know this is ancient, but does anyone know if this little problem was ever diagnosed (or maybe even fixed)? I'm suddenly seeing it on several systems, and it appears to be causing data corruption. Yes, I'm using a kernel as ancient as the original report... > > > On Friday August 17, ak@dkp.com wrote: > > > > > > kernel: raid5: multiple 1 requests for sector 32029440 > > > ... > > > > kernel: raid5: multiple 1 requests for sector 40 > > > > kernel: raid5: multiple 1 requests for sector 76260224 > > > > (etc) ---- Chris J. Bednar Director, Distributed Computing http://AdvancedDataSolutions.com/ From owner-linux-xfs@oss.sgi.com Tue Jul 16 05:16:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GCG5Rw029537 for ; Tue, 16 Jul 2002 05:16:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GCG4mR029536 for linux-xfs-outgoing; Tue, 16 Jul 2002 05:16:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GCFwRw029508 for ; Tue, 16 Jul 2002 05:15:59 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6GCKeDt082553; Tue, 16 Jul 2002 14:20:50 +0200 (CEST) Message-Id: <4.3.2.7.2.20020716141844.03740500@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jul 2002 14:19:37 +0200 To: Chris Bednar , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: "raid5: multiple 1 requests for sector ..." In-Reply-To: References: <200108272236.f7RMarn16012@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 06:57 16-7-2002 -0500, Chris Bednar wrote: > Hi > > I know this is ancient, but does anyone know if this little >problem was ever diagnosed (or maybe even fixed)? I'm suddenly >seeing it on several systems, and it appears to be causing data >corruption. Yes, I'm using a kernel as ancient as the original >report... And what kernel was that? Not in a while. I am running a 2.4.18 kernel with a 3disk raid5 and have not seen these messages in a long time. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Jul 16 05:44:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GCi4Rw029934 for ; Tue, 16 Jul 2002 05:44:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GCi3BR029933 for linux-xfs-outgoing; Tue, 16 Jul 2002 05:44:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailman.mnd.com (adsfw.mnd.com [208.226.69.17] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GChtRw029905 for ; Tue, 16 Jul 2002 05:43:55 -0700 Received: from alpha2.production.mnd.com (alpha2 [192.168.3.105]) by mailman.mnd.com (8.11.6/8.9.3) with ESMTP id g6GCkCA14845; Tue, 16 Jul 2002 07:46:12 -0500 Date: Tue, 16 Jul 2002 07:45:26 -0500 (CDT) From: Chris Bednar X-Sender: cjb@alpha2.production.mnd.com To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: "raid5: multiple 1 requests for sector ..." In-Reply-To: <4.3.2.7.2.20020716141844.03740500@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 16 Jul 2002, Seth Mos wrote: > At 06:57 16-7-2002 -0500, Chris Bednar wrote: > > I know this is ancient, but does anyone know if this little > >problem was ever diagnosed (or maybe even fixed)? I'm suddenly > And what kernel was that? (gasp) 2.4.9. > Not in a while. I am running a 2.4.18 kernel with a 3disk raid5 and have > not seen these messages in a long time. Thanks; we're using 2.4.18 on some other systems already for >1TB block device support, so we'll give it a try. ---- Chris J. Bednar Director, Distributed Computing http://AdvancedDataSolutions.com/ From owner-linux-xfs@oss.sgi.com Tue Jul 16 06:11:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GDBORw030586 for ; Tue, 16 Jul 2002 06:11:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GDBOmb030585 for linux-xfs-outgoing; Tue, 16 Jul 2002 06:11:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from akira.ep-ka.de (akira.ep-ag.com [194.120.231.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GDBCRw030554 for ; Tue, 16 Jul 2002 06:11:14 -0700 Received: from eigner.com ([194.120.231.18]) by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id PAA20841; Tue, 16 Jul 2002 15:15:47 +0200 Message-ID: <3D341C83.4010305@eigner.com> Date: Tue, 16 Jul 2002 15:15:47 +0200 From: Klaus Strebel Organization: EIGNER User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: de, en MIME-Version: 1.0 To: ayatu@gmx.de CC: linux-xfs@oss.sgi.com Subject: Re: hard lockup - kmem_cache_zalloc References: <32693.1026816093@www20.gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ayatu@gmx.de wrote: > I've attached the output of 'ksymoops < kern.log > kern.log.ksymoops_ed' and > the messages logfile from after the hard-reboot. > I didn't bother to ksymoops 'messages' too as those dumps were already in > kern.log. > > The bester anwser I could get would be that this is most probably a > hardware-failure as a software-failure would give the anti-linux camp here ammunition > to switch over to an CVSNT-server :D > > Thanks in advance. > Hi ayatu@gmx.de, first of all, you kernel seems to be 'way outdated. There where so many changes in the last weeks (in fact, i should say mounths ;-)), you realy should consider an update. Im running SuSE-8.0's kernel with XFS-support on some boxes with Zero problems :-). The first oops came from uagentd (that's ArcServe's UNIX/Linux Agent, isn't it). Perhaps he has a problem with xfs (is ArcServe able to backup XFS-ACL/EAs ??). Ciao Klaus P.S.: For you anti-linux camp. I just rebooted both our 'Active Directory' Controller and our Exchange Server, 'cause Exchange refused to receive any mail directed to him from one minute to the other. Hm, last week i saw a nice signature : ' Microsoft Pullution Survivor'. -- Klaus Strebel UNIX-Engineer klaus.strebel@eigner.com EIGNER - Precision Lifecycle Management - From owner-linux-xfs@oss.sgi.com Tue Jul 16 09:52:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GGquRw005457 for ; Tue, 16 Jul 2002 09:52:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GGquhY005456 for linux-xfs-outgoing; Tue, 16 Jul 2002 09:52:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus.city.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GGqLRw004773 for ; Tue, 16 Jul 2002 09:52:22 -0700 Received: by zeus.city.tvnet.hu (Postfix, from userid 500) id E005B3C23713; Tue, 16 Jul 2002 18:57:15 +0200 (CEST) Subject: Makepkgs error From: Sipos Ferenc To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-42kozJgM/8ZFiWQ7Xzxo" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-3) Date: 16 Jul 2002 18:57:15 +0200 Message-Id: <1026838635.1273.14.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-42kozJgM/8ZFiWQ7Xzxo Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! This time on the other part of the code. Log file attached. Thx. Paco --=-42kozJgM/8ZFiWQ7Xzxo Content-Disposition: attachment; filename=dist Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=dist; charset=ISO-8859-2 make: Entering directory `/home/sferi/linux-2.4-xfs/cmd/xfsprogs/build' Wrote: /home/sferi/linux-2.4-xfs/cmd/xfsprogs/build/xfsprogs-2.0.6.src.tar.= gz =3D=3D=3D install =3D=3D=3D make[1]: Entering directory `/home/sferi/linux-2.4-xfs/cmd/xfsprogs' =3D=3D=3D include =3D=3D=3D rm -f xfs ln -s . xfs =3D=3D=3D libxfs =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D libxlog =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D libhandle =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D libdisk =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D bmap =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D db =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D freeze =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D fsck =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D growfs =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D imap =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D logprint =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D mkfile =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D mkfs =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D repair =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D rtcp =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D man =3D=3D=3D =3D=3D=3D man3 =3D=3D=3D make[3]: Nothing to be done for `default'. =3D=3D=3D man5 =3D=3D=3D make[3]: Nothing to be done for `default'. =3D=3D=3D man8 =3D=3D=3D make[3]: Nothing to be done for `default'. =3D=3D=3D doc =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D debian =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D build =3D=3D=3D make[2]: Nothing to be done for `default'. =3D=3D=3D include =3D=3D=3D rm -f xfs ln -s . xfs =3D=3D=3D libxfs =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D libxlog =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D libhandle =3D=3D=3D cd ../libhandle/.libs; ../../install-sh -o root -g root -m 755 -d /usr/lib;= ../../install-sh -o root -g root -m 644 -T so_dot_version libhandle.lai /u= sr/lib; test "SGI XFS" =3D debian || ../../install-sh -o root -g root -T so= _dot_current libhandle.lai /usr/lib =3D=3D=3D libdisk =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D bmap =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= bmap /usr/sbin ../install-sh -o root -g root -m 755 xfs_bmap /usr/sbin/xfs_bmap =3D=3D=3D db =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= db /usr/sbin ../install-sh -o root -g root -m 755 xfs_db /usr/sbin/xfs_db ../install-sh -o root -g root -m 755 xfs_admin.sh /usr/sbin/xfs_admin ../install-sh -o root -g root -m 755 xfs_check.sh /usr/sbin/xfs_check ../install-sh -o root -g root -m 755 xfs_ncheck.sh /usr/sbin/xfs_ncheck =3D=3D=3D freeze =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= freeze /usr/sbin ../install-sh -o root -g root -m 755 xfs_freeze /usr/sbin/xfs_freeze =3D=3D=3D fsck =3D=3D=3D ../install-sh -o root -g root -m 755 -d /sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 fsck= .xfs /sbin ../install-sh -o root -g root -m 755 fsck.xfs /sbin/fsck.xfs =3D=3D=3D growfs =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= growfs /usr/sbin ../install-sh -o root -g root -m 755 xfs_growfs /usr/sbin/xfs_growfs ../install-sh -o root -g root -m 755 xfs_info.sh /usr/sbin/xfs_info =3D=3D=3D imap =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D logprint =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= logprint /usr/sbin ../install-sh -o root -g root -m 755 xfs_logprint /usr/sbin/xfs_logprint =3D=3D=3D mkfile =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= mkfile /usr/sbin ../install-sh -o root -g root -m 755 xfs_mkfile /usr/sbin/xfs_mkfile =3D=3D=3D mkfs =3D=3D=3D ../install-sh -o root -g root -m 755 -d /sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 mkfs= .xfs /sbin ../install-sh -o root -g root -m 755 mkfs.xfs /sbin/mkfs.xfs =3D=3D=3D repair =3D=3D=3D ../install-sh -o root -g root -m 755 -d /sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= repair /sbin ../install-sh -o root -g root -m 755 xfs_repair /sbin/xfs_repair =3D=3D=3D rtcp =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/sbin /usr/bin/libtool --mode=3Dinstall ../install-sh -o root -g root -m 755 xfs_= rtcp /usr/sbin ../install-sh -o root -g root -m 755 xfs_rtcp /usr/sbin/xfs_rtcp =3D=3D=3D man =3D=3D=3D =3D=3D=3D man3 =3D=3D=3D make[3]: Nothing to be done for `install'. =3D=3D=3D man5 =3D=3D=3D ../../install-sh -o root -g root -m 755 -d /usr/share/man/man5 ../../install-sh -o root -g root -m 644 xfs.5.gz /usr/share/man/man5/xfs.5.= gz =3D=3D=3D man8 =3D=3D=3D ../../install-sh -o root -g root -m 755 -d /usr/share/man/man8 ../../install-sh -o root -g root -m 644 fsck.xfs.8.gz /usr/share/man/man8/f= sck.xfs.8.gz ../../install-sh -o root -g root -m 644 mkfs.xfs.8.gz /usr/share/man/man8/m= kfs.xfs.8.gz ../../install-sh -o root -g root -m 644 xfs_admin.8.gz /usr/share/man/man8/= xfs_admin.8.gz ../../install-sh -o root -g root -m 644 xfs_bmap.8.gz /usr/share/man/man8/x= fs_bmap.8.gz ../../install-sh -o root -g root -m 644 xfs_check.8.gz /usr/share/man/man8/= xfs_check.8.gz ../../install-sh -o root -g root -m 644 xfs_db.8.gz /usr/share/man/man8/xfs= _db.8.gz ../../install-sh -o root -g root -m 644 xfs_freeze.8.gz /usr/share/man/man8= /xfs_freeze.8.gz ../../install-sh -o root -g root -m 644 xfs_growfs.8.gz /usr/share/man/man8= /xfs_growfs.8.gz ../../install-sh -o root -g root -S xfs_growfs.8.gz /usr/share/man/man8/xfs= _info.8.gz ../../install-sh -o root -g root -m 644 xfs_logprint.8.gz /usr/share/man/ma= n8/xfs_logprint.8.gz ../../install-sh -o root -g root -m 644 xfs_mkfile.8.gz /usr/share/man/man8= /xfs_mkfile.8.gz ../../install-sh -o root -g root -m 644 xfs_ncheck.8.gz /usr/share/man/man8= /xfs_ncheck.8.gz ../../install-sh -o root -g root -m 644 xfs_repair.8.gz /usr/share/man/man8= /xfs_repair.8.gz ../../install-sh -o root -g root -m 644 xfs_rtcp.8.gz /usr/share/man/man8/x= fs_rtcp.8.gz =3D=3D=3D doc =3D=3D=3D ../install-sh -o root -g root -m 755 -d /usr/share/doc/xfsprogs ../install-sh -o root -g root -m 644 PORTING CHANGES.gz CREDITS README.LVM = README.quota /usr/share/doc/xfsprogs ../install-sh -o root -g root -m 644 COPYING /usr/share/doc/xfsprogs =3D=3D=3D debian =3D=3D=3D make[2]: Nothing to be done for `install'. =3D=3D=3D build =3D=3D=3D make[2]: Nothing to be done for `install'. ./install-sh -o root -g root -m 755 -d /usr/share/doc/xfsprogs ./install-sh -o root -g root -m 644 README /usr/share/doc/xfsprogs make[1]: Leaving directory `/home/sferi/linux-2.4-xfs/cmd/xfsprogs' =3D=3D=3D tar =3D=3D=3D Wrote: /home/sferi/linux-2.4-xfs/cmd/xfsprogs/build/tar/xfsprogs-2.0.6.tar.= gz =3D=3D=3D rpm =3D=3D=3D sed -e's|@pkg_name@|xfsprogs|g' \ -e's|@pkg_version@|2.0.6|g' \ -e's|@pkg_release@|0|g' \ -e's|@pkg_distribution@|SGI XFS|g' \ -e's|@pkg_builder@|sferi@zeus.city.tvnet.hu|g' \ -e's|@build_root@|/tmp/8896|g' \ -e'/^BuildRoot: *$/d' \ -e's|@pkg_var_dir@||g' \ -e's|@pkg_share_dir@||g' \ -e's|@pkg_log_dir@||g' \ -e's|@pkg_doc_dir@|/usr/share/doc/xfsprogs|g' \ -e's|@pkg_man_dir@|/usr/share/man|g' \ -e's|@pkg_tmp_dir@||g' \ -e's|@make@|/usr/bin/make|g' < xfsprogs.spec.in > xfsprogs.spec sed -e '/^macrofiles:/s|~/.rpmmacros|rpmmacros|' rpm-4= .rc ba --rcfile ./rpm-4.rc xfsprogs.spec make[1]: ba: Command not found make[1]: [dist] Error 127 (ignored) Done make: Leaving directory `/home/sferi/linux-2.4-xfs/cmd/xfsprogs/build' --=-42kozJgM/8ZFiWQ7Xzxo-- From owner-linux-xfs@oss.sgi.com Tue Jul 16 12:42:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GJg3Rw010382 for ; Tue, 16 Jul 2002 12:42:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GJg3pC010381 for linux-xfs-outgoing; Tue, 16 Jul 2002 12:42:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GJfuRw010351 for ; Tue, 16 Jul 2002 12:41:56 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA37458 for ; Tue, 16 Jul 2002 14:46:48 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA18775 for ; Tue, 16 Jul 2002 14:46:47 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id OAA79444 for linux-xfs@oss.sgi.com; Tue, 16 Jul 2002 14:46:47 -0500 (CDT) Date: Tue, 16 Jul 2002 14:46:47 -0500 (CDT) From: Dean Roehrich Message-Id: <200207161946.OAA79444@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - make dmapi use vnode pointer rather than bhv pointer X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 16 12:46:32 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123115a linux/fs/xfs/xfs_dmapi.c - 1.70 linux/include/linux/dmapi_kern.h - 1.14 linux/fs/xfs_dmapi/dmapi_right.c - 1.11 linux/fs/xfs_dmapi/dmapi_register.c - 1.18 linux/fs/xfs_dmapi/dmapi_region.c - 1.5 linux/fs/xfs_dmapi/dmapi_io.c - 1.5 linux/fs/xfs_dmapi/dmapi_hole.c - 1.5 linux/fs/xfs_dmapi/dmapi_handle.c - 1.5 linux/fs/xfs_dmapi/dmapi_event.c - 1.8 linux/fs/xfs_dmapi/dmapi_dmattr.c - 1.5 linux/fs/xfs_dmapi/dmapi_config.c - 1.6 linux/fs/xfs_dmapi/dmapi_bulkattr.c - 1.5 linux/fs/xfs_dmapi/dmapi_attr.c - 1.5 - make dmapi use vnode pointer rather than bhv pointer From owner-linux-xfs@oss.sgi.com Tue Jul 16 12:50:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GJoNRw010749 for ; Tue, 16 Jul 2002 12:50:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GJoNdk010748 for linux-xfs-outgoing; Tue, 16 Jul 2002 12:50:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GJoJRw010718 for ; Tue, 16 Jul 2002 12:50:19 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA45787 for ; Tue, 16 Jul 2002 14:55:10 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA23711 for ; Tue, 16 Jul 2002 14:55:10 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id OAA96585 for linux-xfs@oss.sgi.com; Tue, 16 Jul 2002 14:55:10 -0500 (CDT) Date: Tue, 16 Jul 2002 14:55:10 -0500 (CDT) From: Dean Roehrich Message-Id: <200207161955.OAA96585@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - keep cmd/.../dmapi_kern.h uptodate X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 16 12:54:48 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:123117a cmd/dmapi/include/dmapi_kern.h - 1.9 - match include/linux/dmapi_kern.h From owner-linux-xfs@oss.sgi.com Tue Jul 16 13:07:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GK7ZRw011441 for ; Tue, 16 Jul 2002 13:07:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GK7Zop011440 for linux-xfs-outgoing; Tue, 16 Jul 2002 13:07:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GK7URw011411 for ; Tue, 16 Jul 2002 13:07:31 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA44463 for ; Tue, 16 Jul 2002 15:12:22 -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 PAA59105 for ; Tue, 16 Jul 2002 15:12:22 -0500 (CDT) Subject: Re: Makepkgs error From: Eric Sandeen To: linux-xfs@oss.sgi.com In-Reply-To: <1026838635.1273.14.camel@zeus.city.tvnet.hu> References: <1026838635.1273.14.camel@zeus.city.tvnet.hu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 16 Jul 2002 15:11:15 -0500 Message-Id: <1026850276.27295.19.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk After Paco did a "make realclean" and re-generated his configure file from configure.in, this problem went away. -Eric On Tue, 2002-07-16 at 11:57, Sipos Ferenc wrote: > Hi! > > This time on the other part of the code. Log file attached. Thx. > > Paco > > > From owner-linux-xfs@oss.sgi.com Tue Jul 16 14:16:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GLGuRw015164 for ; Tue, 16 Jul 2002 14:16:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GLGuVg015163 for linux-xfs-outgoing; Tue, 16 Jul 2002 14:16:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GLGoRw015135 for ; Tue, 16 Jul 2002 14:16:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA89318 for ; Tue, 16 Jul 2002 16:21:41 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA47546 for ; Tue, 16 Jul 2002 16:21:41 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6GLFhs12831; Tue, 16 Jul 2002 16:15:43 -0500 Message-Id: <200207162115.g6GLFhs12831@jen.americas.sgi.com> Date: Tue, 16 Jul 2002 16:15:43 -0500 Subject: TAKE - remove some unaccessed parts of the xfs iocore To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More code cleanup. Date: Tue Jul 16 14:20:59 PDT 2002 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:123125a linux/fs/xfs/xfs_iocore.c - 1.34 linux/fs/xfs/xfs_mount.h - 1.151 linux/fs/xfs/linux/xfs_lrw.c - 1.158 From owner-linux-xfs@oss.sgi.com Tue Jul 16 19:29:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6H2TaRw028148 for ; Tue, 16 Jul 2002 19:29:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6H2Ta62028147 for linux-xfs-outgoing; Tue, 16 Jul 2002 19:29:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6H2TVRw028035 for ; Tue, 16 Jul 2002 19:29:31 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA47073 for ; Tue, 16 Jul 2002 21:34:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA95268 for ; Tue, 16 Jul 2002 21:34:23 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6H2SMd15531; Tue, 16 Jul 2002 21:28:22 -0500 Message-Id: <200207170228.g6H2SMd15531@jen.americas.sgi.com> Date: Tue, 16 Jul 2002 21:28:22 -0500 Subject: TAKE - fix pagebuf locking bug To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This one crept in about a week ago, I should have left this alone! Nathan hit it in testing, for some reason I never could. Date: Tue Jul 16 19:33:03 PDT 2002 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:123144a linux/fs/xfs/pagebuf/page_buf.c - 1.40 - fix unlock without lock bug in pagebuf, causes a BUG macro to trip also remove need for xfs_fs.h From owner-linux-xfs@oss.sgi.com Wed Jul 17 03:12:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HACWRw028987 for ; Wed, 17 Jul 2002 03:12:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HACWtX028986 for linux-xfs-outgoing; Wed, 17 Jul 2002 03:12:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HACNRw028902 for ; Wed, 17 Jul 2002 03:12:23 -0700 Received: from idcomm.com (IDENT:c5bCRafrlQMS2qKzBfwhoFaPfWj1+t9j@tnt01-ppp-095.idcomm.com [216.98.194.95]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g6HAIXl30258 for ; Wed, 17 Jul 2002 04:18:33 -0600 Message-ID: <3D354483.8475F82F@idcomm.com> Date: Wed, 17 Jul 2002 04:18:43 -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: TAKE - fix pagebuf locking bug References: <200207170228.g6H2SMd15531@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.0 required=5.0 tests=PORN_10,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > This one crept in about a week ago, I should have left this alone! > Nathan hit it in testing, for some reason I never could. > > Date: Tue Jul 16 19:33:03 PDT 2002 > 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:123144a > linux/fs/xfs/pagebuf/page_buf.c - 1.40 > - fix unlock without lock bug in pagebuf, causes a BUG macro to trip > also remove need for xfs_fs.h Out of curiosity, how would this show up? I'm experimenting on a new Redhat 7.3 install, smp (dual pIII), i840 chipset, scsi aic7xxx mixed with IDE. I am running "noapic" to avoid some i840 chipset issues (if they have been solved by microcode I will find out, but first I am getting it running with noapic), and compile the kernel and related sgi code with kgcc. This is 2.4.19-rc1-xfs, from cvs of about 2 days ago. This TAKE and today's takes are the first takes in a few days that were not on this cvs version (it is out of date by about 2 or 3 days). What I noticed is in copying a large subdirectory from an existing xfs partition, to an ext2 partition (cp -adpr, from one scsi disk to another), it copies a lot, then stalls. The hard drives stop showing any activity. I am running KDE during this, and had tail -f going on /var/log/messages. Not only did the copy stall, the keyboard became 100% unavailable, though the mouse still worked. I could focus on different windows, minimize them, so on, but no keyboard access. Top did not show any real cpu use or memory out of the normal. I couldn't even get to a console. But telnet from a local machine worked fine, and I could either kill the cp from the remote login, or kill the X11 session, and all was restored. If I copied the same directory via feeding "find" to cpio, it worked flawlessly. It might not have anything to do with xfs, but it seemed useful to report, and ask about (no oops or backtrace or other concrete data to save)...is this anything familiar? It seems like something deadlocked and stalled, I couldn't really call it a crash, nor could I say for certain it wasn't a KDE or a window manager or other issue. FYI, I am on the mailing list. D. Stimits, stimits @ idcomm.com From owner-linux-xfs@oss.sgi.com Wed Jul 17 04:59:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HBxTRw022257 for ; Wed, 17 Jul 2002 04:59:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HBxT4o022255 for linux-xfs-outgoing; Wed, 17 Jul 2002 04:59:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta02.algx.net (chimta02.algx.net [216.99.233.77]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HBxMRw022227 for ; Wed, 17 Jul 2002 04:59:23 -0700 Received: from wiley.ceo.com (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx02.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GZE0016U6V99H@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Wed, 17 Jul 2002 07:04:22 -0500 (CDT) Date: Wed, 17 Jul 2002 08:04:20 -0400 From: Danny Cox Subject: Re: TAKE - fix pagebuf locking bug In-reply-to: <3D354483.8475F82F@idcomm.com> To: stimits@idcomm.com Cc: XFS Mailing List Message-id: <1026907461.1184.13.camel@wiley> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200207170228.g6H2SMd15531@jen.americas.sgi.com> <3D354483.8475F82F@idcomm.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-17 at 06:18, D. Stimits wrote: > Steve Lord wrote: > > > > Modid: 2.4.x-xfs:slinx:123144a > > linux/fs/xfs/pagebuf/page_buf.c - 1.40 > > - fix unlock without lock bug in pagebuf, causes a BUG macro to trip > > also remove need for xfs_fs.h > > Out of curiosity, how would this show up? I'm experimenting on a new If a BUG macro is tripped (executed) the kernel oopses. It won't stall (well, actually it will: forever ;-), but it'll present a message about what went wrong, along with the C file and line number of the BUG macro, plus the usual oops output. Think of it as an abort() in kernel space, but it can't, of course, dump core...yet. -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Wed Jul 17 06:04:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HD4RRw023166 for ; Wed, 17 Jul 2002 06:04:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HD4RF4023165 for linux-xfs-outgoing; Wed, 17 Jul 2002 06:04:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HD4HRw023137 for ; Wed, 17 Jul 2002 06:04:17 -0700 Received: from user-uini6r0.dsl.mindspring.com ([165.121.27.96] helo=waltsathlon.localhost.net) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17UoYL-0006rk-00 for linux-xfs@oss.sgi.com; Wed, 17 Jul 2002 09:09:13 -0400 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 3EFD0EB0E00; Wed, 17 Jul 2002 06:08:28 -0700 (PDT) Message-ID: <3D356C4C.20806@mindspring.com> Date: Wed, 17 Jul 2002 06:08:28 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020709 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stimits@idcomm.com Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - fix pagebuf locking bug References: <200207170228.g6H2SMd15531@jen.americas.sgi.com> <3D354483.8475F82F@idcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk That sounds very similar to my experience with recent kernels from CVS. I found that upon the stall (oops), nothing more could be written to the filesystem and it was impossible to sync/unmount the online volumes, forcing a hard reset followed by a boot from my rescue CD. I attributed (possibly mistakenly it turns out) to the kernel being compiled by gcc 3.1 I've since gone back to 2.4.18-XFS and a different compiler and all seems well now. The one thing that made it hard to pinpoint this one for me, is that when I got the oops and nothing more could be written, I couldn't even see the output of the oops in my logs. -Walt D. Stimits wrote: > Steve Lord wrote: > >>This one crept in about a week ago, I should have left this alone! >>Nathan hit it in testing, for some reason I never could. >> >>Date: Tue Jul 16 19:33:03 PDT 2002 >>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:123144a >>linux/fs/xfs/pagebuf/page_buf.c - 1.40 >> - fix unlock without lock bug in pagebuf, causes a BUG macro to trip >> also remove need for xfs_fs.h > > > Out of curiosity, how would this show up? I'm experimenting on a new > Redhat 7.3 install, smp (dual pIII), i840 chipset, scsi aic7xxx mixed > with IDE. I am running "noapic" to avoid some i840 chipset issues (if > they have been solved by microcode I will find out, but first I am > getting it running with noapic), and compile the kernel and related sgi > code with kgcc. This is 2.4.19-rc1-xfs, from cvs of about 2 days ago. > This TAKE and today's takes are the first takes in a few days that were > not on this cvs version (it is out of date by about 2 or 3 days). > > What I noticed is in copying a large subdirectory from an existing xfs > partition, to an ext2 partition (cp -adpr, from one scsi disk to > another), it copies a lot, then stalls. The hard drives stop showing any > activity. I am running KDE during this, and had tail -f going on > /var/log/messages. Not only did the copy stall, the keyboard became 100% > unavailable, though the mouse still worked. I could focus on different > windows, minimize them, so on, but no keyboard access. Top did not show > any real cpu use or memory out of the normal. I couldn't even get to a > console. But telnet from a local machine worked fine, and I could either > kill the cp from the remote login, or kill the X11 session, and all was > restored. If I copied the same directory via feeding "find" to cpio, it > worked flawlessly. It might not have anything to do with xfs, but it > seemed useful to report, and ask about (no oops or backtrace or other > concrete data to save)...is this anything familiar? It seems like > something deadlocked and stalled, I couldn't really call it a crash, nor > could I say for certain it wasn't a KDE or a window manager or other > issue. > > FYI, I am on the mailing list. > > D. Stimits, stimits @ idcomm.com > From owner-linux-xfs@oss.sgi.com Wed Jul 17 07:01:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HE1VRw024502 for ; Wed, 17 Jul 2002 07:01:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HE1Vqp024501 for linux-xfs-outgoing; Wed, 17 Jul 2002 07:01:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HE0VRw024470 for ; Wed, 17 Jul 2002 07:00:31 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA52251 for ; Wed, 17 Jul 2002 09:05:25 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA44528 for ; Wed, 17 Jul 2002 09:05:25 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6HE0gD02747; Wed, 17 Jul 2002 09:00:42 -0500 Message-Id: <200207171400.g6HE0gD02747@jen.americas.sgi.com> Date: Wed, 17 Jul 2002 09:00:42 -0500 Subject: TAKE - merge up to 2.4.19-rc2 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Did you know this was out? Not much of an announcement, and it looks bigger than it really is - mostly mips platform changes. Steve Date: Wed Jul 17 07:02:09 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123150a linux/include/asm-mips/mips-boards/msc01_pci.h - 1.1 linux/include/asm-mips/galileo-boards/evb64120A/dma.h - 1.1 linux/arch/mips/sgi-ip22/ip22-gio.c - 1.1 linux/include/asm-mips/galileo-boards/evb64120A/eeprom_param.h - 1.1 linux/arch/mips/sgi-ip22/ip22-berr.c - 1.1 linux/include/asm-mips/dec/kn02ba.h - 1.1 linux/include/asm-mips/sgi/sgigio.h - 1.1 linux/include/asm-mips64/fpu_emulator.h - 1.1 linux/arch/mips/sibyte/swarm/rtc_xicor1241.c - 1.1 linux/include/asm-mips/galileo-boards/evb64120A/pci.h - 1.1 linux/include/asm-mips64/traps.h - 1.1 linux/include/asm-mips/traps.h - 1.1 linux/include/asm-mips/dec/kn02ca.h - 1.1 linux/include/asm-mips/dec/kn230.h - 1.1 linux/include/asm-mips/war.h - 1.1 linux/include/asm-mips/pgtable-bits.h - 1.1 linux/include/asm-mips/mips-boards/bonito64.h - 1.1 linux/include/asm-mips/irq_cpu.h - 1.1 linux/arch/mips/sibyte/swarm/dbg_io.c - 1.1 linux/include/asm-mips64/irq_cpu.h - 1.1 linux/include/asm-mips/dec/kn05.h - 1.1 linux/include/asm-mips64/mips-boards/bonito64.h - 1.1 linux/include/asm-mips/galileo-boards/evb64120A/cntmr.h - 1.1 linux/include/asm-mips/galileo-boards/evb64120A/core.h - 1.1 linux/include/asm-mips/galileo-boards/evb64120A/flashdrv.h - 1.1 linux/include/asm-mips/galileo-boards/evb64120A/i2o.h - 1.1 linux/include/asm-mips/galileo-boards/evb64120A/memory.h - 1.1 linux/include/asm-mips64/mips-boards/msc01_pci.h - 1.1 linux/arch/mips/dec/ioasic-irq.c - 1.1 linux/arch/mips/dec/kn02-irq.c - 1.1 linux/net/802/cl2llc.pre - 1.5 linux/mm/mmap.c - 1.47 linux/mm/memory.c - 1.76 linux/kernel/sysctl.c - 1.49 linux/kernel/ksyms.c - 1.129 linux/ipc/shm.c - 1.53 linux/include/linux/personality.h - 1.10 linux/include/linux/kdev_t.h - 1.8 linux/include/linux/fs.h - 1.155 linux/include/asm-mips/unistd.h - 1.12 linux/include/asm-mips/types.h - 1.7 linux/include/asm-mips/system.h - 1.12 linux/include/asm-mips/stackframe.h - 1.8 linux/include/asm-mips/spinlock.h - 1.9 linux/include/asm-mips/smp.h - 1.5 linux/include/asm-mips/ptrace.h - 1.10 linux/include/asm-mips/processor.h - 1.20 linux/include/asm-mips/pgtable.h - 1.16 linux/include/asm-mips/pci.h - 1.15 linux/include/asm-mips/page.h - 1.9 linux/include/asm-mips/mipsregs.h - 1.11 linux/include/asm-mips/jazz.h - 1.7 linux/include/asm-mips/io.h - 1.10 linux/include/asm-mips/ide.h - 1.11 linux/include/asm-mips/gdb-stub.h - 1.6 linux/include/asm-mips/errno.h - 1.5 linux/include/asm-mips/elf.h - 1.11 linux/include/asm-mips/current.h - 1.6 linux/include/asm-mips/cpu.h - 1.8 linux/include/asm-mips/cache.h - 1.7 linux/include/asm-mips/branch.h - 1.6 linux/include/asm-mips/bootinfo.h - 1.12 linux/include/asm-mips/bitops.h - 1.10 linux/include/asm-mips/atomic.h - 1.9 linux/include/asm-mips/asm.h - 1.6 linux/include/asm-mips/addrspace.h - 1.5 linux/include/asm-i386/processor.h - 1.32 linux/include/asm-i386/mmu_context.h - 1.15 linux/include/asm-alpha/a.out.h - 1.4 linux/fs/readdir.c - 1.11 linux/fs/open.c - 1.35 linux/fs/nfs/inode.c - 1.34 linux/fs/lockd/svcproc.c - 1.10 linux/fs/buffer.c - 1.108 linux/fs/binfmt_misc.c - 1.18 linux/fs/autofs/inode.c - 1.10 linux/fs/autofs/dir.c - 1.9 linux/fs/autofs/autofs_i.h - 1.9 linux/drivers/sgi/char/sgiserial.c - 1.12 linux/drivers/net/Config.in - 1.57 linux/drivers/block/genhd.c - 1.24 linux/arch/ppc/kernel/misc.S - 1.36 linux/arch/ppc/kernel/head.S - 1.32 linux/arch/mips/tools/offset.c - 1.9 linux/arch/mips/tools/Makefile - 1.7 linux/arch/mips/mm/init.c - 1.14 linux/arch/mips/mm/fault.c - 1.13 linux/arch/mips/mm/Makefile - 1.9 linux/arch/mips/lib/memcpy.S - 1.9 linux/arch/mips/lib/Makefile - 1.11 linux/arch/mips/kernel/unaligned.c - 1.9 linux/arch/mips/kernel/traps.c - 1.13 linux/arch/mips/kernel/time.c - 1.13 linux/arch/mips/kernel/sysmips.c - 1.9 linux/arch/mips/kernel/syscalls.h - 1.12 linux/arch/mips/kernel/syscall.c - 1.11 linux/arch/mips/kernel/setup.c - 1.14 linux/arch/mips/kernel/scall_o32.S - 1.11 linux/arch/mips/kernel/r4k_switch.S - 1.10 linux/arch/mips/kernel/r2300_switch.S - 1.10 linux/arch/mips/kernel/process.c - 1.14 linux/arch/mips/kernel/proc.c - 1.8 linux/arch/mips/kernel/pci.c - 1.8 linux/arch/mips/kernel/mips_ksyms.c - 1.14 linux/arch/mips/kernel/irq.c - 1.13 linux/arch/mips/kernel/irixelf.c - 1.16 linux/arch/mips/kernel/head.S - 1.12 linux/arch/mips/kernel/gdb-stub.c - 1.9 linux/arch/mips/kernel/entry.S - 1.10 linux/arch/mips/kernel/Makefile - 1.10 linux/arch/mips/defconfig - 1.23 linux/arch/mips/config.in - 1.26 linux/arch/mips/boot/Makefile - 1.8 linux/arch/mips/Makefile - 1.12 linux/arch/i386/mm/init.c - 1.34 linux/arch/i386/kernel/smp.c - 1.40 linux/arch/i386/kernel/process.c - 1.40 linux/arch/i386/kernel/i386_ksyms.c - 1.47 linux/arch/i386/boot/compressed/misc.c - 1.14 linux/arch/alpha/kernel/osf_sys.c - 1.28 linux/arch/alpha/kernel/entry.S - 1.24 linux/arch/alpha/config.in - 1.40 linux/Rules.make - 1.17 linux/Makefile - 1.173 linux/MAINTAINERS - 1.88 linux/Documentation/Configure.help - 1.134 linux/CREDITS - 1.72 linux/fs/hpfs/hpfs_fn.h - 1.13 linux/include/asm-mips/dec/tcmodule.h - 1.3 linux/include/asm-mips/dec/kn03.h - 1.3 linux/include/asm-mips/dec/kn02xa.h - 1.3 linux/include/asm-mips/dec/kn02.h - 1.3 linux/include/asm-mips/dec/kn01.h - 1.2 linux/include/asm-mips/dec/ioasic_ints.h - 1.3 linux/include/asm-mips/dec/ioasic_addrs.h - 1.3 linux/include/asm-mips/dec/interrupts.h - 1.4 linux/include/asm-mips/baget/vic.h - 1.5 linux/include/asm-mips/baget/vac.h - 1.5 linux/drivers/net/declance.c - 1.14 linux/arch/mips/lib/kbd-std.c - 1.7 linux/arch/mips/dec/setup.c - 1.6 linux/arch/mips/dec/prom/memory.c - 1.10 linux/arch/mips/dec/prom/Makefile - 1.6 linux/arch/mips/dec/int-handler.S - 1.4 linux/arch/mips/dec/boot/Makefile - 1.3 linux/arch/mips/dec/Makefile - 1.5 linux/arch/mips/arc/init.c - 1.8 linux/arch/mips/arc/identify.c - 1.7 linux/arch/mips/arc/console.c - 1.8 linux/drivers/char/ppdev.c - 1.28 linux/drivers/block/cpqarray.c - 1.36 linux/drivers/scsi/ips.c - 1.24 linux/drivers/net/starfire.c - 1.25 linux/arch/i386/kernel/smpboot.c - 1.28 linux/include/linux/pci_ids.h - 1.59 linux/drivers/scsi/sim710.c - 1.10 linux/include/asm-i386/pgalloc.h - 1.13 linux/drivers/char/agp/agpgart_be.c - 1.33 linux/drivers/ieee1394/raw1394.c - 1.15 linux/drivers/ieee1394/ieee1394_core.h - 1.12 linux/drivers/ieee1394/pcilynx.h - 1.9 linux/drivers/ieee1394/pcilynx.c - 1.18 linux/drivers/ieee1394/ieee1394_core.c - 1.19 linux/drivers/ieee1394/ohci1394.h - 1.14 linux/drivers/ieee1394/ohci1394.c - 1.21 linux/drivers/ieee1394/ieee1394_types.h - 1.12 linux/drivers/ieee1394/ieee1394_transactions.c - 1.10 linux/drivers/ieee1394/hosts.h - 1.9 linux/drivers/ieee1394/hosts.c - 1.12 linux/drivers/ieee1394/Config.in - 1.8 linux/drivers/scsi/scsi_scan.c - 1.24 linux/fs/autofs4/autofs_i.h - 1.7 linux/fs/autofs4/root.c - 1.11 linux/fs/autofs4/inode.c - 1.10 linux/fs/lockd/svc4proc.c - 1.6 linux/arch/mips/defconfig-decstation - 1.9 linux/arch/mips/defconfig-ip22 - 1.10 linux/drivers/net/tulip/media.c - 1.12 linux/drivers/net/ioc3-eth.c - 1.18 linux/include/asm-mips64/io.h - 1.8 linux/include/asm-mips64/inst.h - 1.4 linux/include/asm-mips64/ide.h - 1.8 linux/include/asm-mips64/errno.h - 1.5 linux/include/asm-mips64/elf.h - 1.8 linux/include/asm-mips64/current.h - 1.4 linux/include/asm-mips64/cpu.h - 1.5 linux/include/asm-mips64/checksum.h - 1.5 linux/include/asm-mips64/cache.h - 1.5 linux/include/asm-mips64/branch.h - 1.5 linux/include/asm-mips64/bootinfo.h - 1.7 linux/include/asm-mips64/bitops.h - 1.8 linux/include/asm-mips64/atomic.h - 1.7 linux/include/asm-mips64/asm.h - 1.5 linux/include/asm-mips64/addrspace.h - 1.5 linux/include/asm-mips/highmem.h - 1.5 linux/include/asm-mips64/sn/sn0/ip27.h - 1.6 linux/include/asm-mips64/sn/sn0/addrs.h - 1.4 linux/include/asm-mips64/sn/kldir.h - 1.4 linux/include/asm-mips64/sn/gda.h - 1.4 linux/include/asm-mips64/sn/arch.h - 1.5 linux/include/asm-mips64/sn/addrs.h - 1.4 linux/include/asm-mips64/xtalk/xwidget.h - 1.4 linux/include/asm-mips64/xtalk/xtalk.h - 1.4 linux/include/asm-mips64/serial.h - 1.7 linux/include/asm-mips64/unistd.h - 1.9 linux/include/asm-mips64/ptrace.h - 1.6 linux/include/asm-mips64/processor.h - 1.13 linux/include/asm-mips64/posix_types.h - 1.4 linux/include/asm-mips64/pgtable.h - 1.11 linux/include/asm-mips64/pci/bridge.h - 1.5 linux/include/asm-mips64/pci.h - 1.11 linux/include/asm-mips64/page.h - 1.6 linux/include/asm-mips64/system.h - 1.7 linux/include/asm-mips64/stackframe.h - 1.4 linux/include/asm-mips64/spinlock.h - 1.5 linux/include/asm-mips64/sn/sn0/hubpi.h - 1.4 linux/include/asm-mips64/mmu_context.h - 1.8 linux/include/asm-mips64/sn/sn0/hubni.h - 1.4 linux/include/asm-mips64/sn/sn0/hubmd.h - 1.4 linux/include/asm-mips64/sn/sn0/hubio.h - 1.4 linux/include/asm-mips64/mipsregs.h - 1.9 linux/arch/mips64/defconfig - 1.19 linux/arch/mips64/arc/identify.c - 1.6 linux/arch/mips64/arc/memory.c - 1.7 linux/arch/mips64/mm/init.c - 1.8 linux/arch/mips64/mm/Makefile - 1.6 linux/arch/mips64/mm/fault.c - 1.11 linux/arch/mips64/lib/strnlen_user.S - 1.4 linux/arch/mips64/arc/init.c - 1.4 linux/arch/mips64/mm/andes.c - 1.10 linux/arch/mips64/lib/dump_tlb.c - 1.5 linux/arch/mips64/lib/Makefile - 1.6 linux/arch/mips64/ld.script.elf64 - 1.5 linux/arch/mips64/kernel/traps.c - 1.8 linux/arch/mips64/kernel/unaligned.c - 1.7 linux/arch/mips64/tools/Makefile - 1.6 linux/arch/mips64/sgi-ip27/ip27-berr.c - 1.6 linux/arch/mips64/config.in - 1.17 linux/arch/mips64/sgi-ip27/Makefile - 1.8 linux/arch/mips64/defconfig-ip22 - 1.12 linux/arch/mips64/kernel/binfmt_elf32.c - 1.7 linux/arch/mips64/kernel/scall_o32.S - 1.9 linux/arch/mips64/Makefile - 1.10 linux/arch/mips64/mm/r4xx0.c - 1.11 linux/arch/mips64/mm/loadmmu.c - 1.7 linux/arch/mips64/kernel/syscall.c - 1.10 linux/arch/mips64/kernel/signal32.c - 1.10 linux/arch/mips64/kernel/setup.c - 1.9 linux/arch/mips64/boot/Makefile - 1.5 linux/arch/mips64/kernel/linux32.c - 1.14 linux/arch/mips64/kernel/scall_64.S - 1.11 linux/arch/mips64/defconfig-ip27 - 1.11 linux/arch/mips64/kernel/Makefile - 1.6 linux/arch/mips64/kernel/entry.S - 1.8 linux/arch/mips64/kernel/head.S - 1.6 linux/arch/mips64/kernel/r4k_switch.S - 1.5 linux/arch/mips64/kernel/mips64_ksyms.c - 1.10 linux/arch/mips64/kernel/proc.c - 1.7 linux/arch/mips64/kernel/process.c - 1.8 linux/arch/mips64/kernel/r4k_genex.S - 1.5 linux/drivers/ide/pdc202xx.c - 1.14 linux/drivers/ide/ide-pci.c - 1.21 linux/drivers/ide/ide-features.c - 1.10 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.12 linux/fs/ramfs/inode.c - 1.16 linux/drivers/net/pppox.c - 1.8 linux/drivers/net/pppoe.c - 1.19 linux/include/asm-s390/unistd.h - 1.9 linux/include/asm-s390/uaccess.h - 1.9 linux/include/asm-s390/spinlock.h - 1.6 linux/arch/s390/kernel/entry.S - 1.17 linux/arch/s390/mm/fault.c - 1.10 linux/arch/mips64/kernel/smp.c - 1.10 linux/include/asm-mips64/sn/nmi.h - 1.3 linux/include/asm-mips64/sn/launch.h - 1.3 linux/include/asm-mips64/sn/intr_public.h - 1.2 linux/include/asm-mips64/sn/intr.h - 1.2 linux/include/asm-mips64/smp.h - 1.6 linux/include/asm-mips/hw_irq.h - 1.4 linux/include/asm-mips64/sn/klkernvars.h - 1.2 linux/drivers/ieee1394/video1394.c - 1.16 linux/arch/mips/cobalt/Makefile - 1.4 linux/arch/mips/cobalt/int-handler.S - 1.4 linux/arch/mips/cobalt/pci.c - 1.4 linux/arch/mips/cobalt/reset.c - 1.4 linux/arch/mips/cobalt/setup.c - 1.4 linux/arch/mips/defconfig-cobalt - 1.6 linux/arch/mips/defconfig-rm200 - 1.6 linux/drivers/media/radio/radio-sf16fmi.c - 1.10 linux/drivers/md/raid1.c - 1.17 linux/arch/mips64/ld.script.elf32.S - 1.3 linux/mm/shmem.c - 1.31 linux/drivers/char/drm/radeon_state.c - 1.3 linux/arch/s390x/kernel/entry.S - 1.12 linux/arch/s390x/mm/fault.c - 1.8 linux/include/asm-s390x/spinlock.h - 1.6 linux/include/asm-s390x/uaccess.h - 1.5 linux/include/asm-s390x/unistd.h - 1.6 linux/drivers/net/gt96100eth.h - 1.4 linux/drivers/net/gt96100eth.c - 1.5 linux/arch/mips/mips-boards/malta/malta_setup.c - 1.4 linux/arch/mips/mips-boards/malta/malta_int.c - 1.4 linux/arch/mips/mips-boards/malta/Makefile - 1.2 linux/arch/mips/mips-boards/generic/time.c - 1.4 linux/arch/mips/mips-boards/generic/pci.c - 1.3 linux/arch/mips/mips-boards/generic/mipsIRQ.S - 1.2 linux/arch/mips/mips-boards/generic/init.c - 1.3 linux/arch/mips/mips-boards/generic/gdb_hook.c - 1.3 linux/arch/mips/mips-boards/generic/cmdline.c - 1.4 linux/arch/mips/mips-boards/generic/Makefile - 1.3 linux/arch/mips/mips-boards/atlas/atlas_setup.c - 1.4 linux/arch/mips/mips-boards/atlas/Makefile - 1.2 linux/arch/mips/math-emu/cp1emu.c - 1.5 linux/arch/mips/math-emu/Makefile - 1.2 linux/drivers/media/video/w9966.c - 1.5 linux/drivers/net/wireless/orinoco.c - 1.9 linux/include/net/bluetooth/bluetooth.h - 1.5 linux/include/net/bluetooth/hci_core.h - 1.5 linux/net/bluetooth/af_bluetooth.c - 1.5 linux/net/bluetooth/hci_core.c - 1.8 linux/net/bluetooth/lib.c - 1.5 linux/include/asm-mips/time.h - 1.3 linux/include/asm-mips/fpu_emulator.h - 1.2 linux/arch/mips/kernel/smp.c - 1.5 linux/drivers/net/au1000_eth.c - 1.6 linux/drivers/net/au1000_eth.h - 1.3 linux/drivers/ieee1394/sbp2.c - 1.9 linux/drivers/ieee1394/sbp2.h - 1.7 linux/drivers/ieee1394/nodemgr.c - 1.10 linux/arch/ppc/mm/ppc_mmu.c - 1.4 linux/drivers/sound/nec_vrc5477.c - 1.6 linux/drivers/sound/ite8172.c - 1.7 linux/drivers/net/starfire_firmware.pl - 1.2 linux/arch/mips64/sgi-ip32/ip32-timer.c - 1.3 linux/arch/mips64/sgi-ip32/ip32-setup.c - 1.3 linux/arch/mips64/sgi-ip32/ip32-pci.c - 1.3 linux/include/asm-mips/linux_logo_dec.h - 1.2 linux/arch/mips64/sgi-ip32/ip32-berr.c - 1.2 linux/arch/mips64/sgi-ip32/Makefile - 1.3 linux/include/asm-mips64/mips-boards/malta.h - 1.2 linux/include/asm-mips64/mips-boards/generic.h - 1.2 linux/arch/mips/defconfig-atlas - 1.3 linux/arch/mips/defconfig-malta - 1.3 linux/arch/mips/defconfig-pb1000 - 1.3 linux/include/asm-mips/mips-boards/malta.h - 1.2 linux/include/asm-mips/mips-boards/generic.h - 1.2 linux/include/asm-mips/linux_logo_sgi.h - 1.2 linux/arch/mips64/defconfig-ip32 - 1.3 linux/include/asm-mips/dec/ioasic.h - 1.3 linux/fs/jffs2/dir.c - 1.4 linux/include/asm-generic/tlb.h - 1.2 linux/drivers/i2c/i2c-keywest.c - 1.2 linux/drivers/ieee1394/amdtp.c - 1.2 linux/drivers/ieee1394/dv1394-private.h - 1.2 linux/drivers/ieee1394/dv1394.c - 1.2 linux/drivers/ieee1394/dv1394.h - 1.2 linux/net/bluetooth/hci_conn.c - 1.2 linux/drivers/mtd/maps/pci.c - 1.2 linux/drivers/net/sb1250-mac.c - 1.2 linux/drivers/net/tg3.c - 1.4 linux/init/do_mounts.c - 1.3 linux/include/asm-mips64/time.h - 1.2 linux/include/asm-mips64/sibyte/sbmips.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_defs.h - 1.2 linux/include/asm-mips64/ip32/machine.h - 1.2 linux/include/asm-mips64/ip32/mace.h - 1.2 linux/include/asm-mips64/ip32/crime.h - 1.2 linux/include/asm-mips64/gdb-stub.h - 1.2 linux/include/asm-mips64/exception.h - 1.2 linux/include/asm-mips/vr4181/vr4181.h - 1.2 linux/arch/mips/cobalt/irq.c - 1.2 linux/include/asm-mips/sibyte/sb1250_defs.h - 1.2 linux/arch/mips/defconfig-ev64120 - 1.2 linux/arch/mips/defconfig-ev96100 - 1.2 linux/arch/mips/defconfig-hp-lj - 1.2 linux/arch/mips/defconfig-ivr - 1.2 linux/arch/mips/defconfig-osprey - 1.2 linux/arch/mips/defconfig-pb1500 - 1.2 linux/arch/mips/defconfig-sb1250-swarm - 1.2 linux/arch/mips/galileo-boards/ev64120/Makefile - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/Makefile - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/burner.c - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/evb64120A_Setup.c - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/gt64011.h - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/ns16550.h - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/pci_etherboot.c - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/sbd.h - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/sbdreset_evb64120A.S - 1.2 linux/arch/mips/galileo-boards/ev64120/int-handler.S - 1.2 linux/arch/mips/galileo-boards/ev64120/irq.c - 1.2 linux/arch/mips/galileo-boards/ev64120/promcon.c - 1.2 linux/arch/mips/galileo-boards/ev64120/setup.c - 1.2 linux/arch/mips/galileo-boards/ev96100/Makefile - 1.2 linux/arch/mips/galileo-boards/ev96100/init.c - 1.2 linux/arch/mips/galileo-boards/ev96100/time.c - 1.2 linux/arch/mips/galileo-boards/generic/Makefile - 1.2 linux/arch/mips/galileo-boards/generic/reset.c - 1.2 linux/include/asm-mips/cobalt/cobalt.h - 1.2 linux/drivers/net/wireless/orinoco_pci.c - 1.2 linux/arch/mips/hp-lj/Makefile - 1.2 linux/arch/mips/hp-lj/gdb_hook.c - 1.2 linux/arch/mips/hp-lj/utils.c - 1.2 linux/include/asm-mips/au1000_pcmcia.h - 1.2 linux/include/asm-mips/au1000_dma.h - 1.2 linux/arch/mips/kernel/irq_cpu.c - 1.2 linux/drivers/sound/au1000.c - 1.4 linux/drivers/sound/hal2.c - 1.2 linux/drivers/sound/swarm_cs4297a.c - 1.3 linux/arch/mips/mm/c-mips32.c - 1.2 linux/arch/mips/mm/c-r4k.c - 1.2 linux/arch/mips/mm/c-rm7k.c - 1.2 linux/arch/mips/mm/c-sb1.c - 1.2 linux/arch/mips/mm/c-tx49.c - 1.2 linux/drivers/video/neofb.c - 1.3 linux/arch/mips/mm/pg-andes.S - 1.2 linux/arch/mips/mm/pg-r4k.S - 1.2 linux/arch/mips/mm/tlb-r3k.c - 1.2 linux/arch/mips/mm/tlb-sb1.c - 1.2 linux/arch/mips/mm/tlbex-r3k.S - 1.2 linux/arch/mips/mm/tlbex-r4k.S - 1.2 linux/arch/mips64/mm/tlbex-r4k.S - 1.2 linux/arch/mips/sgi-ip22/Makefile - 1.2 linux/arch/mips/sgi-ip22/ip22-int.c - 1.2 linux/arch/mips/sgi-ip22/ip22-mc.c - 1.2 linux/arch/mips/sgi-ip22/ip22-setup.c - 1.2 linux/arch/mips/sgi-ip22/ip22-system.c - 1.2 linux/arch/mips/sgi-ip22/ip22-time.c - 1.2 linux/arch/mips/sibyte/sb1/Makefile - 1.2 linux/arch/mips/sibyte/sb1250/Makefile - 1.2 linux/arch/mips/sibyte/sb1250/pci.c - 1.2 linux/arch/mips/sibyte/sb1250/time.c - 1.2 linux/arch/mips/sibyte/swarm/Makefile - 1.2 linux/arch/mips/sibyte/swarm/cfe_api.c - 1.2 linux/arch/mips/sibyte/swarm/cfe_api.h - 1.2 linux/arch/mips/sibyte/swarm/setup.c - 1.2 linux/arch/mips/sibyte/swarm/smp.c - 1.2 linux/arch/mips64/mm/tlb-sb1.c - 1.2 linux/arch/mips64/mm/tlb-glue-r4k.S - 1.2 linux/arch/mips/vr4181/common/Makefile - 1.2 linux/arch/mips/vr4181/common/irq.c - 1.2 linux/arch/mips/vr4181/osprey/Makefile - 1.2 linux/arch/mips/vr4181/osprey/prom.c - 1.2 linux/arch/mips64/mm/c-sb1.c - 1.2 linux/arch/mips64/kernel/time.c - 1.2 linux/arch/mips64/kernel/pci-dma.c - 1.2 linux/arch/mips64/kernel/irq.c - 1.2 linux/arch/mips64/defconfig-atlas - 1.2 linux/arch/mips64/defconfig-malta - 1.2 linux/arch/mips64/defconfig-sb1250-swarm - 1.2 From owner-linux-xfs@oss.sgi.com Wed Jul 17 08:18:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HFILRw025724 for ; Wed, 17 Jul 2002 08:18:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HFIKvY025723 for linux-xfs-outgoing; Wed, 17 Jul 2002 08:18:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HFI8Rw025695 for ; Wed, 17 Jul 2002 08:18:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA54865; Wed, 17 Jul 2002 10:23:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA24040; Wed, 17 Jul 2002 10:23:02 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6HFIJ314987; Wed, 17 Jul 2002 10:18:19 -0500 Subject: Re: TAKE - fix pagebuf locking bug From: Steve Lord To: stimits@idcomm.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D354483.8475F82F@idcomm.com> References: <200207170228.g6H2SMd15531@jen.americas.sgi.com> <3D354483.8475F82F@idcomm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 17 Jul 2002 10:18:19 -0500 Message-Id: <1026919099.1402.50.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-17 at 05:18, D. Stimits wrote: > Steve Lord wrote: > > > > This one crept in about a week ago, I should have left this alone! > > Nathan hit it in testing, for some reason I never could. > > > > Date: Tue Jul 16 19:33:03 PDT 2002 > > 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:123144a > > linux/fs/xfs/pagebuf/page_buf.c - 1.40 > > - fix unlock without lock bug in pagebuf, causes a BUG macro to trip > > also remove need for xfs_fs.h > > Out of curiosity, how would this show up? I'm experimenting on a new > Redhat 7.3 install, smp (dual pIII), i840 chipset, scsi aic7xxx mixed > with IDE. I am running "noapic" to avoid some i840 chipset issues (if > they have been solved by microcode I will find out, but first I am > getting it running with noapic), and compile the kernel and related sgi > code with kgcc. This is 2.4.19-rc1-xfs, from cvs of about 2 days ago. > This TAKE and today's takes are the first takes in a few days that were > not on this cvs version (it is out of date by about 2 or 3 days). This bug showed up as an oops, so you are seeing something else. I am tied up with other things right now, I will point Eric at this. Steve > > What I noticed is in copying a large subdirectory from an existing xfs > partition, to an ext2 partition (cp -adpr, from one scsi disk to > another), it copies a lot, then stalls. The hard drives stop showing any > activity. I am running KDE during this, and had tail -f going on > /var/log/messages. Not only did the copy stall, the keyboard became 100% > unavailable, though the mouse still worked. I could focus on different > windows, minimize them, so on, but no keyboard access. Top did not show > any real cpu use or memory out of the normal. I couldn't even get to a > console. But telnet from a local machine worked fine, and I could either > kill the cp from the remote login, or kill the X11 session, and all was > restored. If I copied the same directory via feeding "find" to cpio, it > worked flawlessly. It might not have anything to do with xfs, but it > seemed useful to report, and ask about (no oops or backtrace or other > concrete data to save)...is this anything familiar? It seems like > something deadlocked and stalled, I couldn't really call it a crash, nor > could I say for certain it wasn't a KDE or a window manager or other > issue. > > FYI, I am on the mailing list. > > D. Stimits, stimits @ idcomm.com -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jul 17 10:19:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HHJURw027536 for ; Wed, 17 Jul 2002 10:19:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HHJUWv027535 for linux-xfs-outgoing; Wed, 17 Jul 2002 10:19:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HHJNRw027507 for ; Wed, 17 Jul 2002 10:19:25 -0700 Received: from paragon.slim (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.11.6/linuxconf) with ESMTP id g6HHVJs23694 for ; Wed, 17 Jul 2002 19:31:19 +0200 Subject: XFS progress? From: Jurgen Kramer To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-2) Date: 17 Jul 2002 19:20:42 +0200 Message-Id: <1026926442.1498.10.camel@paragon.slim> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi guys, I just read on the LKML something about a feature freeze on October 31st. I know this is way off but does XFS still make a change to get into 2.5 before that? What is the current status? Cheers, Jurgen From owner-linux-xfs@oss.sgi.com Wed Jul 17 10:57:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HHvlRw028450 for ; Wed, 17 Jul 2002 10:57:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HHvlKo028449 for linux-xfs-outgoing; Wed, 17 Jul 2002 10:57:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HHvfRw028420 for ; Wed, 17 Jul 2002 10:57:41 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA54558; Wed, 17 Jul 2002 13:02:36 -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 NAA81399; Wed, 17 Jul 2002 13:02:36 -0500 (CDT) Subject: Re: TAKE - fix pagebuf locking bug From: Eric Sandeen To: stimits@idcomm.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D354483.8475F82F@idcomm.com> References: <200207170228.g6H2SMd15531@jen.americas.sgi.com> <3D354483.8475F82F@idcomm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 17 Jul 2002 13:01:22 -0500 Message-Id: <1026928882.6871.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-17 at 05:18, D. Stimits wrote: > What I noticed is in copying a large subdirectory from an existing xfs > partition, to an ext2 partition (cp -adpr, from one scsi disk to > another), it copies a lot, then stalls. Can you define "large?" :) How many files, how large are the files, how many subdirs etc. Just so I can try to recreate your test. If you have KDB enabled, a backtrace of the cp process might be helpful. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Wed Jul 17 11:15:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HIFVRw028815 for ; Wed, 17 Jul 2002 11:15:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HIFVB6028814 for linux-xfs-outgoing; Wed, 17 Jul 2002 11:15:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cogent.jatosoft.com ([216.170.207.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HIFIRw028785 for ; Wed, 17 Jul 2002 11:15:23 -0700 Received: from [192.168.0.10] (unknown [216.170.207.50]) by cogent.jatosoft.com (Postfix) with ESMTP id A27EB8004E2 for ; Wed, 17 Jul 2002 13:04:27 -0500 (CDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 17 Jul 2002 13:20:12 -0500 Subject: Software RAID, a bit OT From: Ben Gollmer To: XFS Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi storage gurus! Hope you don't mind me asking this on-list, but I've gotten some very helpful storage-related info from here in the past. I'm putting together a server for a small group of developers; we have no real budget, so we're trying to keep things cheap. Here's our hardware specs so far: 2x P3 700 MHz 512 MB RAM 2 Promise PCI ATA-133 controllers 3 Seagate 80 GB HDDs This server is going to handle file sharing, e-mail, CVS, and a bug-tracking database for us. Our project has some rather large files so we need a good amount of storage space. I was planning to software RAID 5 the HDDs together for a total of 160 GBs. I have been enjoying XFS on my workstation but I know it has had problems with software RAID 5 in the past. Are these problems fixed now? We also considered trying to grab another 80 GB drive from somewhere and do a RAID 0+1 (still giving us 160 GBs storage) but I don't know if Linux software RAID handles this well. Most of us run the -aa kernel tree on our workstations but I have no problem running SGI CVS kernels on the server if they are reasonably stable. Any input would be much appreciated :) Ben From owner-linux-xfs@oss.sgi.com Wed Jul 17 11:26:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HIQMRw029135 for ; Wed, 17 Jul 2002 11:26:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HIQMja029134 for linux-xfs-outgoing; Wed, 17 Jul 2002 11:26:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HIQGRw029098 for ; Wed, 17 Jul 2002 11:26:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA46513 for ; Wed, 17 Jul 2002 13:31:12 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA08385 for ; Wed, 17 Jul 2002 13:31:11 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6HIQRB21938; Wed, 17 Jul 2002 13:26:27 -0500 Message-Id: <200207171826.g6HIQRB21938@jen.americas.sgi.com> Date: Wed, 17 Jul 2002 13:26:27 -0500 Subject: TAKE - fixes a couple of btree assert trips in debug kernels To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Looks like the optimizations in the btree code which went in last week confused the compiler (or me) in a couple of cases. Back out a few optimizations which stops the asserts from tripping. Steve Date: Wed Jul 17 11:29:46 PDT 2002 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:123164a linux/fs/xfs/xfs_bmap_btree.c - 1.125 - be less aggressive caching btree block contents outside the block From owner-linux-xfs@oss.sgi.com Wed Jul 17 12:13:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HJDdRw029800 for ; Wed, 17 Jul 2002 12:13:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HJDdVZ029799 for linux-xfs-outgoing; Wed, 17 Jul 2002 12:13:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HJDTRw029770 for ; Wed, 17 Jul 2002 12:13:30 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6HJIQLN032157; Wed, 17 Jul 2002 21:18:26 +0200 (CEST) Message-Id: <4.3.2.7.2.20020717210933.03a9b170@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Jul 2002 21:17:21 +0200 To: Ben Gollmer , XFS From: Seth Mos Subject: Re: Software RAID, a bit OT In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:20 17-7-2002 -0500, Ben Gollmer wrote: >Hi storage gurus! >This server is going to handle file sharing, e-mail, CVS, and a bug-tracking >database for us. Our project has some rather large files so we need a good >amount of storage space. I was planning to software RAID 5 the HDDs together >for a total of 160 GBs. I have been enjoying XFS on my workstation but I >know it has had problems with software RAID 5 in the past. Are these >problems fixed now? The only problems XFS had/has with raid5 are performance issues. They are not really problems in the sense that they break stuff. And performance fixes still occur every once in a while. The real performance fix for raid5 is still in the works, untill that one is submitted everything still works and you can use it. I do it, I have a software raid5 with a internal log and I still don't consider it extremely slow in the sence that it is not usable. And the good thing is that it will only get faster in the future. >We also considered trying to grab another 80 GB drive from somewhere and do >a RAID 0+1 (still giving us 160 GBs storage) but I don't know if Linux >software RAID handles this well. This works just fine. I already built one for testing and it performed and worked well. Just create 2 raid 1 devices and stripe those 2 raid 0 devices together. So something like this: md0 = hda + hdb md1 = hdc + hdd md2 = md0 + md1 >Most of us run the -aa kernel tree on our workstations but I have no problem >running SGI CVS kernels on the server if they are reasonably stable. Any >input would be much appreciated :) I am running the current CVS on some test machines but not on a production box yet. We decided to replace the broadcom gigabit cards(for intel e1000 cards) so we don't need the tg3 driver from 2.4.19 anymore. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 17 13:23:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HKNLRw030628 for ; Wed, 17 Jul 2002 13:23:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HKNL3x030627 for linux-xfs-outgoing; Wed, 17 Jul 2002 13:23:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HKNERw030599 for ; Wed, 17 Jul 2002 13:23:14 -0700 Received: from idcomm.com (IDENT:YmRpv7FZpn5X34SKfZHmOGXoUBGgylo1@tnt01-ppp-147.idcomm.com [216.98.194.147]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g6HKTRl28247 for ; Wed, 17 Jul 2002 14:29:28 -0600 Message-ID: <3D35D3B0.18C09544@idcomm.com> Date: Wed, 17 Jul 2002 14:29:36 -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: TAKE - fix pagebuf locking bug References: <200207170228.g6H2SMd15531@jen.americas.sgi.com> <3D354483.8475F82F@idcomm.com> <1026928882.6871.6.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > On Wed, 2002-07-17 at 05:18, D. Stimits wrote: > > > What I noticed is in copying a large subdirectory from an existing xfs > > partition, to an ext2 partition (cp -adpr, from one scsi disk to > > another), it copies a lot, then stalls. > > Can you define "large?" :) How many files, how large are the files, > how many subdirs etc. Just so I can try to recreate your test. > > If you have KDB enabled, a backtrace of the cp process might be helpful. > > Thanks, > > -Eric I suddenly realize that you will probably all be laughing at my idea of "large", this is just a subdirectory with about 50,000 files, total size 2.8 GB (du -h -s .). Most of them are either .tar.gz or rpm files. Whatever is wrong, piping to cpio instead of using cp -adpr fixes it. I don't have time right now, but I will try to get an strace on it tonight. D. Stimits, stimits @ idcomm.com From owner-linux-xfs@oss.sgi.com Wed Jul 17 13:52:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HKqDRw001686 for ; Wed, 17 Jul 2002 13:52:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HKqDTc001685 for linux-xfs-outgoing; Wed, 17 Jul 2002 13:52:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf06bis.bellsouth.net (mail106.mail.bellsouth.net [205.152.58.46]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HKq1Rw001653 for ; Wed, 17 Jul 2002 13:52:01 -0700 Received: from TAZ2 ([66.156.5.159]) by imf06bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020717205829.WTGT1185.imf06bis.bellsouth.net@TAZ2>; Wed, 17 Jul 2002 16:58:29 -0400 Date: Wed, 17 Jul 2002 16:55:51 -0400 From: Greg Freemyer Subject: re: Software RAID, a bit OT To: Ben Gollmer , XFS Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020717205829.WTGT1185.imf06bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6HKq1Rw001657 X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ben, If you can scrap together another $500, I would consider dropping those Promise controllers and adding a 3ware controller. As I understand it, with the Promise controller you can still only do one disk seek operation at a time. This eliminates the performance advantages of RAID. Someone please correct me if I'm wrong. With the 3ware it does the RAID in hardware and does overlapping seeks. (They have just changed there model numbering scheme, so I can't remember what the new model numbers are.) If you stick with Promise controllers, I don't know if RAID 1+ 0 will be any faster than RAID 5 or not. I would guess they will be almost the same speed. All the RAID performance descriptions I know assume your hardware supports overlapping seeks. Greg >> Hi storage gurus! >> Hope you don't mind me asking this on-list, but I've gotten some very >> helpful storage-related info from here in the past. I'm putting together a >> server for a small group of developers; we have no real budget, so we're >> trying to keep things cheap. Here's our hardware specs so far: >> 2x P3 700 MHz >> 512 MB RAM >> 2 Promise PCI ATA-133 controllers >> 3 Seagate 80 GB HDDs >> This server is going to handle file sharing, e-mail, CVS, and a >> bug-tracking >> database for us. Our project has some rather large files so we need a good >> amount of storage space. I was planning to software RAID 5 the HDDs >> together >> for a total of 160 GBs. I have been enjoying XFS on my workstation but I >> know it has had problems with software RAID 5 in the past. Are these >> problems fixed now? >> We also considered trying to grab another 80 GB drive from somewhere and >> do >> a RAID 0+1 (still giving us 160 GBs storage) but I don't know if Linux >> software RAID handles this well. >> Most of us run the -aa kernel tree on our workstations but I have no >> problem >> running SGI CVS kernels on the server if they are reasonably stable. Any >> input would be much appreciated :) >> Ben Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Jul 17 15:30:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HMUvRw007957 for ; Wed, 17 Jul 2002 15:30:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HMUvbx007956 for linux-xfs-outgoing; Wed, 17 Jul 2002 15:30:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from endeavour.uwyo.edu (endeavour.uwyo.edu [129.72.10.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HMUlRw007921 for ; Wed, 17 Jul 2002 15:30:47 -0700 Received: from CONVERSION-DAEMON.endeavour.uwyo.edu by endeavour.uwyo.edu (PMDF V6.1-1 #40460) id <0GZF00H0103KZJ@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Wed, 17 Jul 2002 16:35:44 -0600 (MDT) Received: from asuwlink.uwyo.edu (asuwlink.uwyo.edu [129.72.60.2]) by endeavour.uwyo.edu (PMDF V6.1-1 #40460) with ESMTP id <0GZF00H0W03JY6@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Wed, 17 Jul 2002 16:35:43 -0600 (MDT) Received: from localhost (fletcher@localhost) by asuwlink.uwyo.edu (8.8.8/8.8.7) with ESMTP id QAA09860 for ; Wed, 17 Jul 2002 16:35:43 -0600 (MDT) Date: Wed, 17 Jul 2002 16:35:43 -0600 (MDT) From: Walter R Fletcher Subject: re: Software RAID, a bit OT In-reply-to: <20020717205829.WTGT1185.imf06bis.bellsouth.net@TAZ2> To: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: asuwlink.uwyo.edu: fletcher owned process doing -bs X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I am NOT a storage GURU, but I can vouch for the 3Ware 7850 RAID controller. I have eight 120 gig Maxtors in a RAID5 configuration mounted as one enormous 860 gig XFS partition. I have users writing to this filesystem via NFS from a number of Sun, SGI, and Linux systems. I've had a few NFS related reliability snags that I'm slowly tracking down, but have nothing but praise for the 7850 itself as far as economics/performance is concerned. It's fast (directly comparable to a 250 Gig SCSI RAID we have attached to an Ultra80) and simple to set up. So far, the money seems well spent. -- Reid Reid Fletcher, WB7CJO Senior Systems Analyst / Unix Systems Administrator Department of Geology and Geophysics P. O. Box 3006 University of Wyoming 1-307-766-6227 Laramie, WY 82071 Internet: Fletcher @ UWyo.Edu Are we all roadkill on the information highway? - Jeff Greenfield On Wed, 17 Jul 2002, Greg Freemyer wrote: > Ben, > > If you can scrap together another $500, I would consider dropping those Promise controllers and adding a 3ware controller. > > As I understand it, with the Promise controller you can still only do one disk seek operation at a time. This eliminates the performance advantages of RAID. > > Someone please correct me if I'm wrong. > > With the 3ware it does the RAID in hardware and does overlapping seeks. (They have just changed there model numbering scheme, so I can't remember what the new model numbers are.) > > If you stick with Promise controllers, I don't know if RAID 1+ 0 will be any faster than RAID 5 or not. I would guess they will be almost the same speed. All the RAID performance descriptions I know assume your hardware supports overlapping seeks. From owner-linux-xfs@oss.sgi.com Wed Jul 17 16:05:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HN57Rw009654 for ; Wed, 17 Jul 2002 16:05:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HN57o5009653 for linux-xfs-outgoing; Wed, 17 Jul 2002 16:05:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HN51Rw009603 for ; Wed, 17 Jul 2002 16:05:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA60387 for ; Wed, 17 Jul 2002 18:09:58 -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 SAA47003 for ; Wed, 17 Jul 2002 18:09:57 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6HN8fn15449; Wed, 17 Jul 2002 18:08:41 -0500 Message-Id: <200207172308.g6HN8fn15449@stout.americas.sgi.com> Date: Wed, 17 Jul 2002 18:08:41 -0500 Subject: TAKE - mkfs tweaks for v2 logs, minor cleanups X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fix up log stripe unit specification options, and update man page. Also fix suffix handling for data su/sw options (disallow unit suffixes on -d sunit,swidth,sw and -l sunit). Add s (512-byte sectors) as valid suffix. Date: Wed Jul 17 16:09:25 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-testing The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:123208a cmd/xfsprogs/VERSION - 1.50 cmd/xfsprogs/doc/CHANGES - 1.73 cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.10 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.31 cmd/xfsprogs/mkfs/xfs_mkfs.h - 1.6 From owner-linux-xfs@oss.sgi.com Wed Jul 17 16:48:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HNmhRw010255 for ; Wed, 17 Jul 2002 16:48:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HNmhgJ010254 for linux-xfs-outgoing; Wed, 17 Jul 2002 16:48:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta04.onolab.com (smtp.ono.com [62.42.230.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HNmdRw010226 for ; Wed, 17 Jul 2002 16:48:40 -0700 Received: from ono.com ([62.42.230.26]) by mta04.onolab.com (Netscape Messaging Server 4.15) with ESMTP id GZF3OQ01.SGD for ; Thu, 18 Jul 2002 01:53:14 +0200 From: To: linux-xfs@oss.sgi.com Message-ID: <2d1af2eb46.2eb462d1af@ono.com> Date: Thu, 18 Jul 2002 01:53:13 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: Shrink a Filesystem X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When will XFS support shrink a filesystems? From owner-linux-xfs@oss.sgi.com Wed Jul 17 16:49:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HNnRRw010328 for ; Wed, 17 Jul 2002 16:49:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HNnRIb010327 for linux-xfs-outgoing; Wed, 17 Jul 2002 16:49:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03.onolab.com (smtp.ono.com [62.42.230.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HNnNRw010297 for ; Wed, 17 Jul 2002 16:49:24 -0700 Received: from ono.com ([62.42.230.26]) by mta03.onolab.com (Netscape Messaging Server 4.15) with ESMTP id GZF3SF04.YQZ for ; Thu, 18 Jul 2002 01:55:27 +0200 From: To: linux-xfs@oss.sgi.com Message-ID: <2c4702f960.2f9602c470@ono.com> Date: Thu, 18 Jul 2002 01:53:57 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: Shrink a Filesystem XFS X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When will XFS support shrink a filesystems? From owner-linux-xfs@oss.sgi.com Wed Jul 17 23:39:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6I6dLRw017549 for ; Wed, 17 Jul 2002 23:39:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6I6dLTf017548 for linux-xfs-outgoing; Wed, 17 Jul 2002 23:39:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6I6dERw017520 for ; Wed, 17 Jul 2002 23:39:15 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6I6dkCA035873; Thu, 18 Jul 2002 08:39:46 +0200 (CEST) Message-Id: <4.3.2.7.2.20020718083136.03b65b98@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Jul 2002 08:38:44 +0200 To: , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Shrink a Filesystem XFS In-Reply-To: <2c4702f960.2f9602c470@ono.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 01:53 18-7-2002 +0200, jm_garcia@ono.com wrote: >When will XFS support shrink a filesystems? Untill someone creates this functionality. And so far no one has stood up to take up the effort. The SGI folks won't do it. It takes a lot of time and honestly I think it is better spent getting XFS in the mainline kernel. The only option to make a partition smaller is by dumping the drive with tar,cpio,xfsdump or whatever is available, mkfs.xfs a new partition and restore. Sorry that is the only option currently. XFS able to scale to larger disks but not the other way around. And making a filesystem smaller during runtime is even more difficult. Apart from the problem that a lot of the systems I admin don't let me rewrite the partition tables during runtime anymore. Or at least they don't like it. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jul 18 00:58:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6I7wgRw018897 for ; Thu, 18 Jul 2002 00:58:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6I7wgKg018896 for linux-xfs-outgoing; Thu, 18 Jul 2002 00:58:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6I7wPRw018859 for ; Thu, 18 Jul 2002 00:58:25 -0700 Received: from hermes4.atos-group.com (hermes4.atos-group.com [160.92.18.11]) 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 AAA04631 for ; Thu, 18 Jul 2002 00:59:23 -0700 (PDT) mail_from (Valery.Brasseur@atosorigin.com) Received: by hermes4.atos-group.com with Internet Mail Service (5.5.2653.19) id <34Y3HNQ0>; Thu, 18 Jul 2002 10:00:31 +0200 Message-ID: <8D7D56C6ED3DD411998D009027DC685E0874E157@srv-grp-s1.segin.com> From: =?iso-8859-1?Q?Brasseur_Val=E9ry?= To: "'linux-xfs@oss.sgi.com'" Subject: oops in XFS Date: Thu, 18 Jul 2002 09:57:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am using 2.4.18 + XFS and got a Oops last night. the partition is on a Compaq Smart Array with on logical volume RAID 0 (striping 128K) using 3 disk. mount options are : /dev/ida/c0d1p1 on /mqueue type xfs (rw,noatime,nodiratime,logbufs=8,logbsize=32768,osyncisdsync,kio) this partion is for Postfix mailqueue. here is the Oops trace : Unable to handle kernel NULL pointer dereference at virtual address 00000018 printing eip: c01d225d *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010286 eax: 00000018 ebx: f55a7d18 ecx: 00000001 edx: 00000000 esi: d77d4c6c edi: f1e29a00 ebp: d7dfdd44 esp: ca781d4c ds: 0018 es: 0018 ss: 0018 Process cleanup (pid: 13114, stackpage=ca781000) Stack: 0000001c ca78033b c02d204f cfc4a710 f55a7d18 00000010 00000000 00000000 00000045 00000000 00000001 0000000a 0000000a 00000040 00000000 00000000 00000000 cfc4a710 00000004 0000001c ca78033b c02d204f cfc4a710 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 39 42 18 0f 84 91 00 00 00 83 7c 24 28 00 74 2f 8b 46 08 89 <6>VFS: file-max limit 65536 reached Reading Oops report from the terminal Unable to handle kernel NULL pointer dereference at virtual address 00000018 c01d225d *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 00000018 ebx: f55a7d18 ecx: 00000001 edx: 00000000 esi: d77d4c6c edi: f1e29a00 ebp: d7dfdd44 esp: ca781d4c ds: 0018 es: 0018 ss: 0018 Process cleanup (pid: 13114, stackpage=ca781000) Stack: 0000001c ca78033b c02d204f cfc4a710 f55a7d18 00000010 00000000 00000000 00000045 00000000 00000001 0000000a 0000000a 00000040 00000000 00000000 00000000 cfc4a710 00000004 0000001c ca78033b c02d204f cfc4a710 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 39 42 18 0f 84 91 00 00 00 83 7c 24 28 00 74 2f 8b 46 08 89 >>EIP; c01d225d <===== >>ebx; f55a7d18 <_end+351e0d5c/384bc044> >>esi; d77d4c6c <_end+1740dcb0/384bc044> >>edi; f1e29a00 <_end+31a62a44/384bc044> >>ebp; d7dfdd44 <_end+17a36d88/384bc044> >>esp; ca781d4c <_end+a3bad90/384bc044> Trace; c01d1e0d Trace; c01e3cd1 Trace; c01e2869 Trace; c01ddde0 <_pagebuf_file_write+d4/1f4> Trace; c01ddfc3 Trace; c01e27fc Trace; c01e38cf Trace; c01e27fc Trace; c01df48a Trace; c0136c07 Trace; c010705b Code; c01d225d 00000000 <_EIP>: Code; c01d225d <===== 0: 39 42 18 cmp %eax,0x18(%edx) <===== Code; c01d2260 3: 0f 84 91 00 00 00 je 9a <_EIP+0x9a> c01d22f7 Code; c01d2266 9: 83 7c 24 28 00 cmpl $0x0,0x28(%esp,1) Code; c01d226b e: 74 2f je 3f <_EIP+0x3f> c01d229c Code; c01d226d 10: 8b 46 08 mov 0x8(%esi),%eax Code; c01d2270 13: 89 00 mov %eax,(%eax) is anybody can help ? thanks valery From owner-linux-xfs@oss.sgi.com Thu Jul 18 02:37:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6I9brRw021140 for ; Thu, 18 Jul 2002 02:37:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6I9brFq021139 for linux-xfs-outgoing; Thu, 18 Jul 2002 02:37:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6I9blRw021111 for ; Thu, 18 Jul 2002 02:37:47 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) 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 UAC00691 for ; Wed, 17 Jul 2002 20:57:59 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g6I0HtQR13863222 for ; Wed, 17 Jul 2002 17:17:56 -0700 (PDT) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA38347; Thu, 18 Jul 2002 10:14:09 +1000 (EST) Date: Thu, 18 Jul 2002 10:14:09 +1000 (EST) From: Nathan Scott Message-Id: <200207180014.KAA38347@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: judith@sgi.com Subject: TAKE - man pages X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jul 17 17:15:48 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:123210a cmd/attr/doc/CHANGES - 1.25 - annotate minor changes since last version. cmd/attr/man/man3/attr_set.3 - 1.6 cmd/attr/man/man3/attr_get.3 - 1.6 cmd/attr/man/man3/attr_multi.3 - 1.6 cmd/attr/man/man3/attr_remove.3 - 1.6 - Fix synopsis section - several parameters suggested type** instead of type*. From owner-linux-xfs@oss.sgi.com Thu Jul 18 03:55:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IAt2Rw023367 for ; Thu, 18 Jul 2002 03:55:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IAt25h023366 for linux-xfs-outgoing; Thu, 18 Jul 2002 03:55:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from 64.51.17.18 ([218.91.69.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IAoJRw023215 for ; Thu, 18 Jul 2002 03:50:33 -0700 Message-Id: <200207181050.g6IAoJRw023215@oss.sgi.com> From: YXGLASS To: linux-xfs@oss.sgi.com Reply-To: BYXYLHT@PUB.YZ.JSINFO.NET Subject: =?gb2312?q?_=BA=CF=D7=F7(GLASS)?= Date: Thu, 18 Jul 2002 18:51:36 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651" X-Spam-Status: No, hits=3.3 required=5.0 tests=SUPERLONG_LINE,CHARSET_FARAWAY_HEADERS,DIFFERENT_REPLY_TO,SUBJ_ALL_CAPS version=2.20 X-Spam-Level: *** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable =C4=FA=BA=C3: =C8=E7=B9=FB=CE=D2=C3=C7=B5=C4=D3=CA=BC=FE=B4=F2=C8=C5=C1=CB=C4=FA,=C7=EB= =C4=FA=D4=AD=C1=C2. =CE=D2=B3=A7=CA=C7=D7=A8=D2=B5=B4=D3=CA=C2=B2=A3=C1=A7=B9=A4=D2=D5=C6=B7= =C9=FA=B2=FA=BA=CD=BF=AA=B7=A2=B5=C4=B3=A7=BC=D2=A3=AC=B3=A4=C6=DA=B7=FE=CE=F1= =D3=DA=C5=B7=C3=C0=BF=CD=BB=A7=A3=AC=D6=F7=D2=AA=C9=FA=B2=FA=B2=A3=C1=A7=B9=A4= =D2=D5=D6=C6=C6=B7=A3=AC=B2=FA=C6=B7=BB=A8=D1=F9=B7=B1=B6=E0=A3=AC=D3=D0=C9=CF= =C7=A7=B8=F6=C6=B7=D6=D6=A3=AC=B8=F7=D6=D6=D0=A1=B6=AF=CE=EF, =C8=C6=CB=BF=BC= =FE=A3=AC=B9=D2=BC=FE=A3=AC=CA=B5=D0=C4=BC=FE=CF=B5=C1=D0=B5=C8=A3=AC=B1=A3=D6= =A4=D6=CA=C1=BF=A3=AC=BD=BB=BB=F5=BC=B0=CA=B1=A3=AC=B2=A2=BF=C9=B0=B4=BF=CD=BB= =A7=C0=B4=D1=F9=B6=A8=D7=F6=A1=A3=CE=D2=B3=A7=BF=C9=D2=D4=CC=E1=B9=A9=B7=E1=B8= =BB=B5=C4=D1=F9=C6=B7=B8=F8=C4=FA=D1=A1=D4=F1=BB=F2=B0=B4=C4=FA=B5=C4=D2=E2=CB= =BC=C9=FA=B2=FA=A1=A3=B1=BE=D7=C5=D2=D4=BF=CD=BB=A7=CE=AA=B8=F9=B1=BE=B5=C4=B7= =FE=CE=F1=D7=DA=D6=BC=A3=AC=C4=FA=B5=C4=D4=B8=CD=FB=D4=DA=B1=BE=B3=A7=D2=BB=B6= =A8=BB=E1=B5=C3=B5=BD=CA=B5=CF=D6=A1=A3=D4=DA=B4=CB=D6=D4=D0=C4=B6=D4=C4=FA=B5= =C4=C0=B4=B7=C3=B1=ED=CA=BE=B8=D0=D0=BB=A1=A3=B1=BE=B3=A7=B4=B4=B0=EC=D2=D4=C0= =B4=A3=AC=B6=E0=B4=CE=C8=D9=BB=F1=D5=FE=B8=AE=BC=B0=D6=F7=B9=DC=B2=BF=C3=C5=B5= =C4=B1=ED=D1=EF=A3=AC=B1=BB=CA=DA=D3=E8=A1=B0=D6=D8=BA=CF=CD=AC=CA=D8=D0=C5=D3= =C3=B5=A5=CE=BB=A1=B1=A1=B0=B0=B2=C8=AB=CE=C4=C3=F7=B5=A5=CE=BB=A1=B1=B5=C8=B6= =E0=CF=EE=B9=E2=C8=D9=B3=C6=BA=C5=A1=A3 =A1=A1=A1=B0=D6=CA=C1=BF=C1=A2=D2=B5=A3=AC=B4=B4=D0=C2=CD=BC=C7=BF=A1=B1=CF= =B5=B1=BE=B3=A7=C9=FA=B4=E6=B7=A2=D5=B9=D6=AE=D7=DA=D6=BC=A1=A3=B3=A7=B3=A4=C1= =F5=BA=A3=CC=CE=CF=C8=C9=FA=C2=CA=C8=AB=CC=E5=D4=B1=B9=A4=BD=DF=B3=CF=BB=B6=D3= =AD=C9=E7=BB=E1=B8=F7=BD=E7=C8=CB=CA=BF=B9=E2=C1=D9=D6=B8=BD=CC=A1=A2=D0=AF=CA= =D6=BA=CF=D7=F7=A3=AC=CD=AC=C4=B1=B7=A2=D5=B9=A3=AC=B9=B2=B4=B4=BB=D4=BB=CD=A1= =A3 =B1=A6=D3=A6=CF=D8=D3=C0=D0=C2=B2=A3=C1=A7=B9=A4=D2=D5=C6=B7=B3=A7 Baoyin Yongxing Glass Arts Factory =C1=F5=BA=A3=CC=CE tel:86-514-8266376 fax:86-514-8261553 www.glass-cn.com First please forgive me of writing to you without your permit . My factory is located in Jiangsu Province of Main Land China., we are specially in making all kinds of glass crafts for holidays, our products varied from spun glass to mouth blown glass ornaments, there must be of some kinds fit your favorites. We will attract you with the high quality products of competitive price. We can assure you that both of us will get benefit from the cooperation! We own about 150 skillful employees at present , and we could ensure you prompt shipment and good quality. Your designs are welcome. Your early reply will be appreciated . Best wishes, Liu Haitao --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651 Content-Type: application/octet-stream; charset=iso-8859-1; file=19s3.jpg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=19s3.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAARgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABAMDAwMDBAMDBAYEAwQGBwUEBAUHCAYGBwYGCAoICQkJCQgKCgwMDAwMCgwMDQ0MDBERERER FBQUFBQUFBQUFAEEBQUIBwgPCgoPFA4ODhQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQU/8AAEQgAfQBkAwERAAIRAQMRAf/EALsAAAIDAAMBAAAAAAAAAAAA AAUGAwQHAQIIAAEAAQUBAQAAAAAAAAAAAAAABQABAgMEBgcQAAEDAgQDBAQGCg0NAQAAAAECAwQR BQAhEgYxEwdBUSIUYYEyFXGRwSMkFkJSM5NkdJTUFwixskOjw1SEpLQlZaUmoeFicpJTY7PTNDWV JxgRAAEDAgQDBQYFBAMAAAAAAAEAAgMRBCExEgVBURNhcYEiMpGhsdFCBvDB4SMUUmJyQ/GCM//a AAwDAQACEQMRAD8An6c9Oens/p9tOZM2pZpEuTZra9Jkv26K44465FbUta1KbJUpSiSSTni4AUVg Ta10o6ae0rZ1iIoCK2uH6/3LD0Sopx0p6YaQfqbYanOhtcMZfesOQEqKRXSzpbmE7LsP/q4fH71h qJUooldKulvPSlWzLGls0Diha4eSeJI+a44g+jQSpsbqNF2tnTfpE3cJESVsWxu2WYv5gqtsUyoq 3KDUlzl+JIOehQpxpiLWFrak4q0vY7AN8UNf6U9OW5DkZWz7FVpakFabbEAJQaf7rtxa2hANFmcK Gigf6X9OgydOzrGFDOotsT/pYs0jkmoEPb6a9PVEpGz7KFVpU22LT/l4cNB4Jlfe6V9PA34dn2PI V1e7YnH71haQOCZD09Muni6oO0rMFAZq93RR8XzeJBoPBJUZXTXYQ1BO1bMn4LdF4D4G8PpHJJZr 9R9o/pr9ze4bf7s+qvm/JeVY5HmPePL5vL0adenw6qVpiFBq8FFbf048PTHZhTXUbFayR/ImsQar xknFh8ONpAA1VqSOwDjh0yulYKQKChPE0zwxUgu6CSsE8D2YVFEITedwOWW62yJGYbkSXuZKWHlB LbbEQJK1KAzVqKkoCRxKsCdyvRbR1IrWntK3WduZX50Wpo2EwLai8W+GpM14GS3EmOhsMKIqhpQI zooitVDA2S5vDFrAaBjUHMKQbEJNJOXLGqya13ZF2euLSnGnJUCSuO+5HJW2pYJrQ8K1Chlgzt9w Zog4inBVXUBjdQ8cVbWkUUlYyPD1YJhYlVaaTqIFONAMKmCSv6QloZZEUFcOUqIW60hJKgnPjhVq kAhEpdHVApqniPlxICoTFZPl/wDoHVTL6n1/vPEPr8Eyf+ns2nTjZqOATY7YK99IbWItyU6pkZug ZUU0qCap788PRLNEE3EKoTXw50r3YanNOrzNwC1ZGlK9n7OHCS8/daupA271J245bm256rKGZNzg PZsPfPJfQyvtFdAKvVjJJaid2kq+Ocxg04rUbX+tleXOl96kSmUHe7r7irU8lIVHaaeVqGpKsyWh kn7bKuOtf9sNMTA13l0+bnUcfFYRfN6lS3HlwWVdGOrkZ/eN9Y3Y4iJJ3LITKjyahDCZY1akEZBP MKqg8K5Y5mKyEDdAzC1zXBldqOC9Eu6So0GWVD8PbiapVNYTUJ+M4nRNRXmXAGQgjIDI+gYRSQWe /pWQlQ01I7uOHCRQCfMQkqK+Pf6OGLKJFZJ55H6eObXw/VLR/edcVf7MuCjRNPT+Wpvp/tZt5QP9 UW/lgfa+Vb44ZowCmmFu4pCvCfGMTomUk3cVutMRU65S0RGAPbWePoA4k4aieqyvcv6wqmVOMbVi hazVKZsoZZ9qWx8uFQlKqw6XInXac/crg8qRNkrU6+84aqUpXE4229sQaqtzlZ89LZY5CXDy+1I4 Y6F17IxmlZ9AJqhy1KJJIzOOdlcXYlaAnLbvVnfu2UIZg3d12I3kmLK+faA7gF1IHwHGaqktb2v+ sfCluNx932/yq8h56JVTfwqbOY9ROEAE62233223a3t3C0TW5kFz2XmTqTn2HtB9BxEtKSA3Kagu KTqqTkTWlD/nwgEqpbnSk1OQOdMziwCqZZRz0/pqrXw/VrR6vP1xD/Z4Jke2jc9GytttqIom1QB/ sxkDDMppCkVWvW82NvxzIcXzJBryI4Oaj3n0YlWiaixzcG5rtuSYZVyfKwPubQyQhPckdmKwEihb aM69uCEEVTioEq40ABw4fLg1GygVRK5WkAkEfBhPYmBUSmwkgihBzArWg9OB0kStBUBGfD14yGJT quQjL4cLpJqo9tbd+4NnTfOWWSW0rI58VRJZdT3LT8ozGIOYWp6rcLPviBuqJ5yKeVLSB5uKo1U2 o9o709xxXTDBJRTLguiqKqoZZcMPkks485/9X5tM/q/p/nta4p/2eCdTWq+tW/ZdmcdJ0tW6IABk SrkIAGEDRo7kgs+uFwk3aWuVIUSpZyHYlPYBiLWkpKFDDim1upbWptunMcCSUpKuFT2VxpaADQnF KhpXguyAezBGJVuVhKVVoBgmxVFS8pRGLy2qaq+EdVCaerFboCUtSgUypNRpzxmdBRT1KZdtmtRW p7sZxEF8lLUkpPKUU8QFcK4xhzC8tBxGY4q0scAHUwKhKOOnOlfiGLjGCFXVc2+6TbJObuEFzQ62 c0n2VJPFKh2g4FSs0FWha1AvLF4t7dwjHSlY+cQeKFjik/AcQzSKT+Yj9J+vVl7j9VfOcMUfX4JJ at7dz3DEs9mtbLkp1qCwrktAqPgZSVKy7EgYzOla0AvNGiiujjc80aKldY1rmSbk3aI7R884vlcp WRSrt1d1O3GuW4jjj1g4BSjge+TpgeZaFv52x2PaVl2xtvW6w446/cLioafMvMnlrpTIp1cOwUxz O1da4unzTYEUDW8gcUf3EMt7dsMZrXM9yzlpuvDHocLKrlHFFI8RTlMq4OQwErM51Eah2VbiaaK5 8aZ4Kx2yyumAREbaeKa8s0xo/jBUfyAhc2xutVqilKVrjNLarQyaq9FdK9s2bqB0VVtnci0Rrbbp 7qDcWieZH4uhbyRwSkqBSqhyyNMeFfcT5Nu3gSR5vaDTmMiu8sGtuLTQcc6D4U+S8x7t2xd9l32V t+8tpTMjFKkuIIU26y6Apt1BHFK0kEY7y0vWTxCRmTlzk9u6J5Ycwhc6xXqNbGrzKt8hi1SHOSxN dbUlpbgGrSlRABNM8ZJriKRxa1wLuVcVIwSMbqc0gKxtS6KiSHIS1UZkjwjsDieHxjGVjuCrUvmR +kDmdvujT6/M1wq/ueCSv9HJ062XKPKty0onLtj6UFboZBbRH1rTqNR4kpKaduA+6QMdZ+fIub8U X2mQtuAQK4FaPuq929v3x1U2/a2LezuO3ptkO3NoDrcVcgct5wqUM16UjxU9onHO27Hvc20e70O1 HtAxA7kcmDY4zctqS5oA/wAjxwQiXtHcu+07fs9ugMwIG2rUxDk3F9ZYYK3VF5Ti9WWolwV0jPic FLa/t7Rz5Huq6R+DRicPKFhnspZtLQMGNxJ7cU8vfqpbjRapN1sd8h3tEVkO0jtrS26qviQ05VST pA1FR8NO3Bfbfu62fN0pWOjNac/ghlxtbmgeYVPA4ePikOw7aU84AtPA0Pqx7VDCAKrjJ5tJIW0b J6aC6vtR2Wy6+upQ2niaCv7Aw1zdMgZqdgEFfM97tLcSn6P0qhPPNRHAlhTq0tqW7kEEmh1fBgc/ dA1pcBXu4rKxz3PDa0xomS9fqwbKcjM+cvkiM68rQJAQ3ySoioGfDLvVjlz90XDnHRCHAduP6rso NtaBi4lL22ukadl2Tc0G13YX/bO4YchTLbQ5b6jGZW2tPzZUAVKUkIKa17cecfcO7x3V1bTFhie0 0IdwGoLtdug6UT2E8RTvcswct1sZ2vZusW6IK5V9jWd+GYspKFRxLhKLWtxKqkOCmSacVcMsDLqS dt0+whNGPkrUf0uxIHYjcEULmC4l9UbRUc+XyWWdXN0XuVtbbm3bwUCRIQm9utNkBDSZCNDTSU8R pRxqc8Etks42TyvZ6WnR38ysG93DnQxtd6nDUfyCxhtwtPIdTkpBCh6sdE7By5JXfMf4v532Puuv q59cSr5/BMinTWDc7vfLHabM0l2fKjFlpC9Gmi4x1klZAFE1NezA/dJGi3q7Job+SI7bXrinb8Fp fTi2xJdihpv5Ag2O9rlOtygFQ3YURAXISQCFLKVEGlaU4VrjmNxmLJSY85GUwz1HBq6WwhL4NMho 2N59yfYd521JRL3tfpkmPstKX0wdrutIQmewPC0p2qvnSpSvClIo2KHsxghgmY5tvEA6Y5vz086c qc+K2Szh7es40YMm8/xwSbc+rm7N0vvw4cpyz7dfISi0w1ltvlIQG0IWU01AJSBThj2X7c+2ba0o 9w6kvF7s6nOi4Hct1kmFG+VoyTPtptpthJIGqgx6RwXAzOJctZ2heDCdQ4y4UOtEKStJopJ41wOu 4BI2hFViNWmozTtcdwxnYi3nFqXLcUorWSKEEVz7a1wGhtHBwA9IUC6uJzKQ7j1y3JtiX90RcrXq Tz7dIzQpCE6AlCuKMu7txddbDbTsoQWO4OaaEHn2rotuv5oziahAdxXhO1rbC6tdPJsx7pxdXinc m2orwachTwiooKHQkKzJp2A/ZDHnO5Wwvi6xuwBcMH7cn9Y/GYXoFpOYiJWCrOLc8+X5hUerDCbx 0ps8KA/oSibGemRpCvpoiXN4uNvOJCQSlQUM144DaZTFevdKPM1rmjlqb286LrbyPqxlseTyzuAr 8arz51mlIe33LjtEliExGit1BSKNtD2U0GkZ5J7MdZsY02gJzcXH3rm9+dW6IGTQB7kpx9sXaZZ3 r602kQWlFKdZot3T7WgdoT24vlu42yiMnzfDvQ5ljK+IygeUe/uQPnf1/r/syn79jXXzeCwI1tJq ZbJNgubzCkx1JjlDhqlJC0ADMcK4H3LmyRuYDjRErNj4pWPIwrn3rTokKIiXcrZMaLL62p6+QtIU lT0h1kBBFRoUlBUUkZ+jHOvkJa14NQC32CvtxXVsiGsx89VfEhSdcLouFcrPsT3Yi2w9sxQEIKuY 6vzgDyStdTWiCNI+PPBv7btHRl80h87zj4IDvU7SWxt9LR+n47aoLtHa26bwxJm2m0SpkWA35iW6 02SlDQpVRrSvHsx6lbbrbREB8jQTzIXLy2crm1DSnWJcX7f9DmNLjym8lsupLbiT6UqAIx1jJA5t QarmpbYtdiKIzB3WYrv3Snfnh6hVOt6opJ3zqYUOZWooKmlBhtIVAtCsx3JuFUlavESD6cUyygBF YIKK/wBF97izb0TYbp9I2xudDlqusFdFNqElBQhdFZBSVEUOPMvuyHqQddo/ch8zT8V1+0vIf0zk /wCP4wPetL3Fa5rW5TuW8MKG1RYkw7mrxBKzZnEpZdS0fEoaNKkDgaHPHkzLnqwCMf8AoZKj/uMQ vRGwiCYuHo0ebvrVYJ1ojuo3/ebikOrtk51LsCU6jTzGyhIAJA06hSigOBx1uzStNoxgzbWo8Vx+ 8wyNuC5w9QGWWSKi0uojtW+5OLYcsUdtiHERXQqY6hLsgLHeUrAOBzpquLm463Gp7BgEbbANIaTT pNFBzcRqd7lkNR9YKdnkKerncMdNx8Fw9MU82IPi3Wh9EsPJRBiu+71EAFpllsLKDn4kqz78sAZC BUUpifN3811EOrS06q+UeXsATHKvlzs+74MuS2lCbnJjT4859HMSUKVy3VZghaVUz+DGVluyS3c0 fQC0j4dy1TXDorkDg8tIPxT3MhWO1753RvXerDV9tkWKyIz7jaw27LdQkpU2jw+JNEoorIVJwNt5 5pLaO3gJY9xNeYAPHvWme3YyZ9xKPK0Cnem7Ye5+t+4Y6L/ZdqWpzbOtxxFtKkwhISW0qQhBCwol KPYA9qpyON7tt2mM6JXvL8auBrQj1FYBeXZGoANbwrnT8c0S6qXuxdWOnsvqE2wu2b62y4iHeLXo OppHMKFodIGYBUOUo+kHHU/b91Ntd220c/qQzeaN3ggd3aNlgLgKFla1zrhh+a81C8uJIIVQj5Me qfyVzXSXorYextkWfp0OoPUdqXdpl2WmNarFCQsymXFKPLXywoFesCpKhRI9OPOdz+5Lqe5dbWjm sEfqkJFAR+XBdFbbYGNDntrUVyOXLDihfuTo3vW7fU5q1XLal9uCuXa7lLbWynzGoJSkoWogpIB1 I414HAN277vat6zpI7iMeoNpgOJwRJ1naSeUNdGeGBx7u1KfT/opuH9Jc9ucuOmzbLlKflXF86Ik tyJR1ptBUU/dAUqPcMLevuKGSzAjOp8zcBxFcCfD3qqy29zJw59Q1pHDn+MVS3Fujd++dx70snT+ Y5eLLIYU/JluI5SvLpSlDrTGqpCHVeFtBoVfHgTbWMFpDFJONLhh7cq9ozROW8muHSQw4tOPszpz qkmzdV7vDt8fb+4YrN4ssfTHCZKAX2o4SUKQ2eFaHiRq9ONtxtMbnGSMljjjhkSsltvT2NEUzQ9o wxzCrbovL1tnXBmEjmW+8IamW+QpRUW0PNBBUk/bafAe7EbSASNbq9TKhw8aqzcLoxPeGCrZKOaf Ciz3SPrDp/Af4XByvmXMca8U27DutmYgwmb6XEtMJZeYcbCSFJSmqmlVzAXwqMCLuGQ4x0xH/B8E d2+6jbRsmABqPl4o1dpsq9bat96abeVD2/LVFQKlaGI7jnMbRrIyPdXFUDBFM5hOMgr3mmKuuJOr AyVuHTdTwqmnqlejJ2hbaNrAvshN0YckalveTS0UNDWKIIKiqo01qnuwP2eDRdOBpWMacOdarfvN xrtmUyfim+yz2t5Obbv8DzCLJZIiIrlvhytFybuMFKVecQylQKkj2a9g4Yxy6rPqsw1yOqHEeUtd 9NeC1QabrQ4HyNHprSh7uKLdRLhdNubV3Xu27+Qae6jOtRYlkjro/GRG1BTj7aTUu0FSSSNXHPBH Z6Tz28TCS22BcXcCTwHYsF9SBsta6nUAFOFPxkvNaJBStKqBelQOhWaVUNaH0Htx631VxQFCvdqt 4W6+osu8NkymHVObffg0bbJXDluJS4lMlCFHJCkUSlAKhpTXLHgl1D/Gkkt5QadQO5ax388e5eh2 v70RPDhyGWX595WTbyvd8d6YW6duuaJm65N8jqsd7LXlpMhLK00cSCEqCU1XUkCuWC1i2MX7xA3T F03a21qAac1nuAWW7Q41cHDTTDjyVH9ZnqnNuCYWyoboSosNv3ySgJDjtQOWytaQCsDTrJI7aYu+ 19sDm/yHitCQz5rJu8/Q/ZYSAc/05dqzjo3uWHYE7pYkxX5Dkm3eYbVGc5dUwypZQ5/oEqSe/LLB L7gtXy9Khp56e1Q2K4ERkqMdNfYkN+2RWNvpu80rRcbi+o2xlJToMds0dcWPaFVHSjvxvbKTLob6 WjE9vAfNCXxNEPUdXU4+UdnE/JSO3WVcduW+3SUtcm2POJiOJQEvFtadRSpf2QBOXdiMcIbM54r5 hjyTy3Dn27WO+k4c6USvQ/WOn4F/C41/Uh6ktxpAiV4Flv8AaDERknBTrtC7XBUG8bNRJCLXfWkr cjrIShcqMdTKqkcQfTgZextBbNTGM+45oxt7teqHg8Yd6sbekt32IvZV6fW2+lRRaHFeMIeBOlnx EaU6iaHhxxXcNMbhcRj/AC7ua0WsjZWG2lNP6TyPJLr7V223dFsKU7AuUdVNSCW194II7DxGDMT4 rhgODmlBntkt5CDVrgoptxn3SW7OuUlyZNeUVvPvrK3FqUakknvJwRgjbGNLQAOxUPkc81caqJJN cE2FUFMG2d2bk2hPbum3J7kGW2oL8NFNqI4akKBSr1jGa7sIbpumVocFoguZIfQaVT5txe4d6XGJ vrqHe3Wtp2B8PNSpIBbcfDiXPLxWqaTqUAV6Rwxy94IrVhtbOOsjxTDgObijdv1J3ia4dRrTn8kC 3Nv2NfepE3e8i0RpMZ5ZCICkaGlpQ3ykOFOYCzQLPZXBSLaHMsW2+rS6mY5rFJesNz1dOpvI8kfV P6ZzmrvuS3suWhmTGEOXbNVV61jUpTYGXjKdIpl8GOUngv43Mhedek6mu7O3uXQW8lmWPlHlqKFv ySCWZG7Jrt8mttxrYyUR2WQeU0EtoIShFPtUpqqnE/Dgk4i3b021Ljj480JYw3Luq/Bg9nd811uz glySWxSO2AhhAAQAgdwSABjbBFobTisFzN1H1GXBKvK/xTp/AK/v2LvqWRRwUn3fEP8AwG/2gxAJ 1diOpYfbdc1aUKCgUGigQa5YhIC4EK6F4a4E8FLdJTUq4PS44KUuELzyOo8SPXhoGlrA08FO5kD5 S9vEpoRu+DfrfHte7ISH3WAEIvjRInJQFKNFVyWBq4U4JGMQsXRPMkDqf2H01/JEBfslaGTtrT6h 6let/T+z3sqcs27LeGEIU86i4aozrTaQM118J46fDxOLhus8OD4XE/24hMNuikxZK2nbgUPuu3dv WlhSm9wt3GVRJQxFZNCT3qUcqUzwXsb26ncKxdNvMlZLi0hiH/oHnsCK9NNotbr3A21MZ59qiUem tFwMJcH2LZcNKaqGudaVwvuDcv4lv5D53YD5qe02QuZqO9LcStB6h7dguyZcq4l9yyQkNyrPa4D7 TUNiJI8KGmva1PmgLiRnjjNrv5IwGMIa51dTnAlxIxq7+3kukvbON1XOLiG0oBgOWHMpXuvSiKX4 CLVe2Y7tyS6oWycD5iMplGsturT4K09OeDEf3LIGnqM1afqbka8kNk2MOI0Opq4OSDarJ5l6Q/IK XWYilIRHSofSHUEDTmRRGdVHu4Y2XN451A0Yu9yGW9qKlzsmn2/omOSwyGUpSnSQCpSUmqAok00J 4JAGWWK4IdGJxKlc3GsaW4BB3GDq9H+TGtYEv8n/ABjo/s2v84xH6lGi+t0Qm029dOMZk/G2MRCk FyY6ieGeEkuvlaihwkxXHu9+lW/F6O3DgpqKMsPIoVtkdxpjSySijRchak/LjW2chR0pu2fv2TtV EmKI6ZEGWoLfRUpXqSlSAQQc6VrQ9uAu6WDb2hJo5uSL7duBtSfLUFXHrtZ5klibZYNzakMOIeba 1JcY5qeKtCqpFcZo4LgNLHlrgcO2i0S3cDnB7Q5rga0rhVWJMjcN1b5T60WyMta3XQxm84tzipRG QJGWWFFYxsNT5lVLuEjxQUb8VXjwYkBstxk0P2SjmpR9JwRKGKdQq2KjPDpVVTlhyoOXcT8uHCZL vKT9etNMvdVafymnHEfqUFHbXbmLLbgmJFU2IrGhSpLiVFPLFCUiOaGnZU4gMlNcKduXbEjen6U5 +b4SQXUO3GmUSN+Uufm+EkVYadutBphxeH8ac/N8JJWUPXf+JRNPpluU/o2FinXyHpn7pCtx/wBa WsH+jYlinRKE/Pr81b7WT+OrGX5IcOdSgEUMjcFFcu3QdNMtM96nqpDwxqpKEv7kp/4+FX8ed/NM MUlUU/fdWUCF6PprtK/kmHTFfKfv/L/7CH+Wu1/omEmVQPX6p+hRKfjbn5thxVIoLzbr9c9XlI3m fdVOX5lzRo8z7WvkV1Vy06OHb2YX1eCiv//Z --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651 Content-Type: application/octet-stream; charset=iso-8859-1; file=25s1.jpg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=25s1.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAARgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABAMDAwMDBAMDBAYEAwQGBwUEBAUHCAYGBwYGCAoICQkJCQgKCgwMDAwMCgwMDQ0MDBERERER FBQUFBQUFBQUFAEEBQUIBwgPCgoPFA4ODhQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQU/8AAEQgAoABQAwERAAIRAQMRAf/EAKcAAAMBAQEBAQEAAAAAAAAA AAUGBwQDAggBAAEAAwEBAQEAAAAAAAAAAAAAAQIDAAQFBhAAAQMDAgQCBQYKBQ0AAAAAAQIDBAAR BSEGMUESE1EHYXGBIhSRodEyIxWxwUJSkpOjs3QIcrIzJBbwYqLC0mNzgzSktCUmEQACAgIBAgUC BAcAAAAAAAAAARECITEDQVFhgaESMnEikcHhBPCx0UJSEyP/2gAMAwEAAhEDEQA/APey9q7Ze2ri JkvBY2Q+5j4ri3HobC1rUphBUpRUgkkk3JNemIlgPQdq7OXLJd23iSyBcXgRrajmO3WYUjara2wu +Gv8OYiyuNsfGFv2daAQjo7tbYKYoLe2MSXFDQ/ARuR/4dFBaQl7u27sLGtw50rERIqHpCYK1w4j HuIlBSSotlBQSm3UFdPUOVqjzJqkrozVcM8YLanl+Wsk5jMZGyENmY+xHlyoqStbbRACghwK6AfC m4arvILX93b8DvI2ztdxHdawGNQgDUCGxf8AqVeCTFybidvMrAGDgdFwFERWb/1aaEA9jE7X6dMN BuBfWKzr/o00IUE5zHbebweVW1iITTyIb6m3Ux2kqSvtK6SkhNwQeFZxDB1Kvsh9prZ23upIKzjY Qvw0EdH4a5mdS0HUNMukgjp090cferBMpiLaf7ih1qta/jyoyYwF1wuOR0jttNquCTzphBG8zXFf dWOT1XScgxzvwSs1Lnc8bNXZ02LNCcDLFwQudMKb6adyjw4TJsLyJaPginrKUKNiRxv6KuYVpClS 3lJZUegABV+R8ayAcH+qMkjp6lEAEk+iqKIFFvOvrOOnoUdPhnuB4/ZqpW8BLDs9CnNrbcSnRRxk LX1R0VzSdK0MPSttSuoE29nDWiY5uzVtsFxFwVAgeNuBv66JhfTK7jie4mxcUVqUddOVESRT8zJK vuHFRFNp0yqXBI6ftCC0sdN/zRUOav2t/QKt0M+xkIc288rgfjpQHq6qfh0ybDZ/sANCRzHIV0GB 8suIaBaAH460iwBJcxxZGnvDQg+NMmAEZdnrxWRWoWKYr5HsbVWlNAgtGyIwVtPbriCSRi4V7crx 0VynUtBTIS3YzZbAN1aqFvkp5MzBLVeKEp5W01pZMZEREkthtJI/OtqDaimLsUvNZhTeMwqVcVZF HK3BpVT5fgwdT+8umFObckEABAmyrE/06PEL0DZiJLSiDYpJFhroKvoEAiS0rqISSogXIPooowtS kFa1JSkoVfUHj7KYUxZdpScLkhxtFfN+f9kqg+xi0bKd7OztuJbTe+KhK6uGvw7ZNcrOqujZk/ti nq4XplozPfbT20o6CUDVRGpNZmRviNQoyeoglR4BQ04VkzQTbzjcbXGwSG02Px5NuRIaP00vL8PN E3s9+VxSra8rqACkzZZv61itxdQLQbaYSpLqSekXNvCuloUwTGWSjrHIWuedADYrTGWS8onkeI9N PAoIyyEJwmXBVdfwcmw9HaVSsJWtkR1u7O24tNgPuuHqf4dArlZ0rQeXGSXEIc4eI8aJgw3GYZQL 2Bte/poyMZn1ISgHpB52seFZaFZJvNZSZE3azDdlhzIqum3INjj8tLzP7PNEbbNnlnFCcBMTfX46 Vbl9Yg01Gk2GukG2EnqdZ6STcjpqwATlQW7tkFA1AtRSMxUmJUhJb58j+CnXcQE5VsnA5VS1Duph yL/qlUjMXLYDKVbI2yLC/wB1wSPbHRXO9nUtDGlltN+q3UOArBPT7anfdGgtypdIwHyj3wzHVY66 /TTpyKyUb/koVldoEK6QmY+sk8gEo+mo83w8yb2MXlx0rw88t6oGRl2vzF01WjywJYQfYaDb7mhH MX429FWkwHzLa3Lgi1r2JooFhGyCVpdvqb8b8NKfBMD5lJVhMr4CHIJ/VKpGMi5eXxI2ftdX5P3V BGv8M3XOzpWkMTqSSVnRKTqOdB4CzytagLk6AePO1YyBk1CZDZSo+vlx0rJwK0SfzWZjxcts5ptV 1FUtxy3EC7KRw9dbm0vqStgYPKKPKlbayMptpZhIycoF+1mwQlCrdXDqtyoV+TQaaGdz/rOlatLX 6fRV0zMA5uQoIWkG+uiqZAYgz5CwT0jXlTiMD5F1bmEy1za0OR+6VSthLjsJ+2yttp8MZB/8dFc7 OhaGV11QbJJvfhz0pWMDnJJAPunxJogMD8xfbJSARbgOFNUDI/5jyXZG8dvokKuhLDqk24AKdQNB y4UnNpfUiw15Vz/htuT0BZSo5GQQDw+qjUjSsnlhosDO7NU3JSsLvzCjrT7HeANnXXXElQP1tbi/ Cqp4JsSJ0kqcUFGyrADlYinkQwZBwDCZOwJKoj4/ZqqbG6Fo2PICNn7dB1IxsIf9uiovZeuhjclW QbJPLjwoMYGypSrKSdPQPVW0B5Ba5gQypROp4j1UyaFZI95Sfid+4loG/bjIFvDreJ/FSc715ke4 V8tXC5Cns2vae4R6ihNDTY9HgoTsNHUhy1vG3O1PQZoCbidS0hIaN7cb8qskTYgvrSp9RXxBv408 iwZsk6kYfJ9saGK+PlbUKVmK7sly20dv+jHRP3CKgzoroPLk9aSDwH5IrDAlbhc6vC9rUpm8A6eE ttqIVYnUC1NViNElnu9/zDZJ95LKI6APWVrtScu0iT0xj8qUKeZyJTylg/pNimjLNTRUlMgIso3A v0kcKbwKwKu5WVBJ/J0tb0VRCNE2mFSHDrci/DjTIkzPMWVYfI/wzx/ZqoDdCu7OcP8AhLCC+gx0 X9wioPZdaDLSivUnQ/MKCGZjeUGR031JtcVoF0YJyS4yQeokDQ+unqKyVwGhK8x1hYPbRKYaX06G yWbnjzqXJ8yT+I1+UbCFHMI6rJDzSzfwIWn/AFadfJh49FfejIQwk3uBrTRkrIi7oLfSbq15DSrJ E7Eunqs6pIJte9za9FCGKQvqxOQtr/dnvk6DSmK5s1R/wthU8D93xf3Kaky1dBhLgSem9tP8jSJD GR95S7pQApSdeI+qnjxovsCTk51qSEE6qtYcrGigNiH5a4yVuPzNei49oyJT+Rf7TYIT1dptYGp0 FgmoclovnwFSlB7yhSljL5qK8LWaStSVcbtSHUHT21dpq8fUWpSctPHR0N3tqLD6apBR2J9uV67d xqPppkhGyaZF/wC1XrTCGF58fdc5F7kx3bEelBpQlc2g8BtzDa6iBF+ZlNSeyi0GFOlXvpTe2i1D gCb2pQyYO/0vEfKeetZox1L6AlbylobQ0haypZskBCSvjrxtRRmBP5TA/K808TLGocelPLNuSo7p P4a4ObNv47lOPTO5gK2pvkFBPay8bILFzwdamrun1Atmva56Q1bu2clbZaCL2RfWkqcVa/AcvbUJ Kizn5hU1qfdtpTrQjZO5yiXCb+0caEmMry7QJaTxLLmvjdBpepiubTf/APm8UjwhR7evtJFI9lFo JiV0BXjy8TQCD+/dxS1e94+HtoNmBu6sl8HtrJOJNlutdhr+k8ej5bEmgn1A9Dd/KNB+H35iVrFi ph9YHH67DxHzCuLditfibvNuEISMVlg10uYvP5KI88LW7L86QgpPPQuIPtr6Dn+7ib7W9Gkzz6Yv PdCxKcBaWlQsPZXEdQrZqQksWBuQNKZMUR33AXCTQAZ33B8DIH+6WB+iaBiobXfKMFjNdfhGB+zT SPY60bXnSQbHieIoNjHJahokXuTb6aXoHqKe+5pebi4lm6l37zqQPy13Qj5utVC2idmXH+VSE6nf rTwSeyyzIZFxw7UdCSf0lkVOtPsb7R6grfMPt/QafNfbknLQt246OyHi5mMkGnLG6HVwo2SYShXA hSo7lx+ca9W39ud1rjyj+cAq3/rso05nz/Ug7ORMzGsSFX7i0AOg8etOh+fWuTWBk5Qv5eSS2UJ0 A4m1aTMUHFXUV3oSAyynOph62nuKFhw4VkBlI269/wCpxqSbARWdP+WKHUogu4CoXB4agClYTKZQ QorUfdQCVHwAFzQgwpY16NmdzRpcklcdt8OuIP1VpbHUsepKE9I9R8ale3REGpPqz+VuApWUayZc BEiLOlhIHEOvttezVBpq3/52+qXoP7Ysn4fmUne+RYizd3RG2+5kserF7kjsgi6w1247ote/1U6n wVrVvbNKvwfo20X/AG/JFrViZTX4o+R90YyNg92ZvAxlj4NqQt6CeRYcsto/q1o+Sq2bee5yceJQ mZRKQ2oFWvE0mCrFR0ELUOVKzSZX27R3iVAEIVYeOhrLYGPeFeKIGNvw+GZ/dilex1oYFP8A2F0+ GposIu5iUpOLndskOFpQB8ArQ0vUFtHfyw2Lltxv5H4d5LbcDEv5M+71hYDCuhFuVybE1z22vEnW y0fZHk75Vbj8uVw9yzMgw9jjhHUZDHpQtLwfW+uUAkqITZIIHUfk50tZf2x1/QomnnwJz5ybtzWN 37JyeIaS6zufBxo8aOUlay1JZU5fQ26klKTp4V6FOVVrR/4z+Zy34n9y7shW5Ny5LdO72crkmUx5 7kNLb7KE9CQmOksosnw6UJqbu289ylKe1+QEyKOoLPC3GmKivISNTfhpegzA+QSWXDrbpP4KVPIH ooOIsMTj+riYzNv1YrPYy0by6otdCePhQCZkxA6hxt36rqShQ9BFqDNEnfb2SnYOFOisPSos4RPu 9b0d1LbbrfcUUJWDqUONqIuOCk2oJNvHj6nFeKOWi/8AlzuTOdjLPplz8/DeYQ4wvvqcSiMoEvMp S6Qm4Sr2eFK+K13KtGPU6f2v7ynEmnxyfu6drTTBa3fm3WdsY3G41cpmZPkuPvEFKW4cfoH2aVHq IsgE6aChTjt7YmUC/NNnZL2+p88BxUrKz83Ke763kpjxnenoK22+LnSeHWq5A8KsssKmJMEtfUhX LjThkWnmyonQW4i9BmMklr+7vG1rIUfmpUshehsxmTxreMgpdnR0rQw0lSFOoCkkIAIIvcEUWsmT UG1WZxI6emfH9P2qPpoQwyj9Rl8VwOQjAHh9s3/tVoYU0epkrbc5jolzoqwBoRIbCwf81QVcUEmC zTC8LzE3Jh4bkHD77VGiLbSyhlRhuhtCeAQSkdJPAnnTKUJ7agvKbufz7/xG5tyu5tzud5KJktKm G3ACkKbYSoNp6QbCya0N7NFUDXczj1qN5kew4faot+GmhmlGN/JwFpIEtn2OI+mjBmwUuVEPCQ3+ mk/joQbBwkSYpiPpS82VKbVYBYJJt66CWQt4P//Z --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651 Content-Type: application/octet-stream; charset=iso-8859-1; file=28201.gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=28201.gif R0lGODlhoACAAPcAAP///zk5OWNjY97W1pyUlFpSUlJKSkpCQkI5Oa2UlGNSUlpKSikhIWtSUq1S SoRSQoRza62UhL2Ue3NSOca1pWNSQpyMe3NjUhgQCIyEe4xzUs61jHtrUu/GhM6lY2NaSr2cY62M SnNrWnNjOa2ca+fGa5SMc5yMWt7WtbWtjJyMSvfvtdbOlO/nlK2lWrW1rYyMhHNza6WllO/v1oSE c2NjUpyca73Ga73GjHuEWqW1a1JaQr3GrZy9c6XOc4Sca2N7SlJaSr3nlHucWkprKWNzWnu1WmOU UkJzMUqUObXerZzOlFKESkp7Qnu1c3PnY3vGc3vWc2PGWjmEMYSMhMbnxoyljFq1WkqcSlK1Ukre UjGUOWO1axh7IWPec0LOUhiMKWOUa2PGc3vOjErea4TnnEq1Y0rGa0qEWmvGhGvejITOnFLvjFLO hErnjIz3vWNza5TWtVKEa2v3tVrvrUqMcxjvnEpjWmvGpVr/xmvvxlKMe0qEc2OcjEJ7a1KcjEJr Y1q1pcb372utpXPGvRDezufv76Wtrb3GxpSlpa3e3mOEhKX//4ze3jn3/4z3/2P3/xjn91Ln9xDn /3OttXPn9zne91KcrTm1zhDG72OEjITn/2PG3krG50KctTGlxhjG9xC15yFSYznO/xi17xi99xC9 /1rO/yFzlDFje0qlzhhjhGutzkp7lDm19ymUzhCl7yljhCFaeylznCFrlCml7xCM1lJreylSayFK YzmEtSlrlCFjjCFrnBCc9xCl/xgxQkql5xBztRCE1jlaczFSaylKYxg5UhhCYxCM5yFKa5ytvXuM nIylvWuEnIyUnKW1xhgxSsbO3iEpOSk5Wq21xqWt1vf3/729xnt7hFJSWkpKUtbW7zk5QikpMSEh KVpaeykpOXtzpWtjlLWt1ntrnOfe95R7vXtjpWtSlMa13s6t93tSrTkxQoxjvZRjzr2M7zEpOYxr ra173qVz1rVz74RKtbWM1s6U9+e1//fe/5SElEI5QjEpMYx7hAAAACwAAAAAoACAAEAI/wCpHYt2 rKBBgwIPHqMWrSHBgQYJJlwYsWA0YAMfPsyI0aJCj9EESnTYEGJGiyRPqiypEaJDkxhZhsyYkqTN myhdSiw4caFAakAR9lQ49GDRoh+TKl3K8+BGpiahIiX41OPJp1g/EkRGkScyarko/jQ2EejPpj+D Ig3aFGFboU6XJizbdi7UuHLv6oUaVmzXgrm4HuN61iAywWYRfi17VmCutF2/unXLWDJdo3TZ/gVM TfJAcJM3f0S6l2iuwMhOg03NOvBj1UBTL0x9Wpq9evfOyRMHrnfvcefUpQNqLDW14q+NkwVb8LDn w4EFGu/8VfCxsJ3BdgYs2dq43unWuf8b7+7du3Po6d1Tl4DsYs/NuVrHbLCv0ea5lKHOZez04f77 KUMbf6cRiIsxxgBjjjnX6OPgg/rkkw8+8OADwIUYZgjADN1QUwxZp/WnX3GrnSbgQqhRF6Ix3RjC jTTSIAIjNzSuc0+F+TioIQDmALBPMWAVSB1rhw02mHNHCuZckUoSiYyAygho4pNRRokLlFEaeKUy uJyGy5cIFgMHANhUk8iZZ5JD4zUYGlPMlwfiApQBJahwAAIrxENNl126EkwwugDwiClZ8rdCBSMc gCAyxnTZaKPFmCMNNoec+cwh1dBI44LaGKPfftAdJmBrTi5p6pKohVollLgUQyWVVq7/GuWTW8LZ qjHW5HNNMW+2Gg0A21CjzZjZEMMrn1VeCacyoJgyiSOTJCOtL9T+YoopnQxayjWVWDvJt5MIUyUy XeqnDIJdGiLALYs0Y40hhtxBjDHqcCNhufm5duqpo/Y7qqmzYrkllwPLCivBBedSK6+94rLILbEQ Q0wscFwT68VVgvKLtbBYey0olkwCySSmbEytLSgnM8zKtnziiS3JArLHHkp4IMQYe7b6Ja/G0NCH HGFYEYchAIxRhhppCEFCwbJi2fTBTTsNddRVyiKrsrIMrKwyWX9JzC23KENMKrEsAgA4xaSibK1c X+mHGFG84QQSTAhy4R5/xAEAI4/0/y0ImxlycIUZhC9LcKy2wjnvNVVUsYQSgvydBh1+bE31uFRP fTnXUVrNteef4yKL56OT3rbVV46uTCq3PHMHr6mk4gw0F2qSisSj3z66xLVmTYzoEqeiDSIDVJpN DXAsAkMVAFyjCCORfyF9MYgj3qqxby7TisRfL7IPNmJ/ufn45Mta+vmjr6I6+uy3f34sZMuSyujM CKCNNmBrckgMjrOBxRBcyIIhIIcIGWTACgIowAEMYIBbfMgYcIDDMp5xOAbyoxtuukUMFCCAGMhA BhagQAYsAIMM0AACMWiACARABXYJAA5UAAABYnE+zoGOajfc3A1VZyWGvQl2t4DTh/+I8Qx+8KMd SERiPJIYjyW2w4lJfOIRjxiEA+wgBz/IYg/CwIQjMKEJSngBD1KQggigYAY84EEi7tCN+zHwAEg0 YgDk2I1utMOIBjjAAQpQBQpsQAIg2NANdIAFLGQhC4UEggsOwIQjLrGJkGxiOOIxyXBY0pKSvKQl D2ACE1gBQfxhmMQYhqBSivKBDwyTm4rBvVto4g6AAIQmlpEITdxCAHcA2y3kkLxFRBAQt7jDHQRA TD5Q4ZiL8GURhCnMGtwhCEGogTRrAM1oQnOazhRmEYoACDgUQQ58kEMyk7mHRcyMnDObWRjSaU51 mjMM61xnH/YAT3WqE57tDEMd6jD/s33ucw/+rIMcwLnPgRp0oLvghUJ3wVBezEKhsVCoRCdKUYom dBUJhSgvVlFRha6CoxKNKEdlsVGOxmIXIC3pR0cqi5V+tKXqiygvYvHRksaCph+9KUxf6tKe+pSn P1WfUFcK06K6dKfqSygtaMGLhjKUqbygBUN3sdSJUnWhTV3qUjMaVYlCFatNrShXOzpRqKa0og/1 6EVBetazqnQVqKhpTVVa0rcGVa53vetbJhKSlmjFKZchzVuk8teKJIQqWnmJXjbSEGBQxSYqyUlM cALZl9xEsfcZzWDsotnBVqQ0PtGLZvJCH9DmpCSfTUpPNFKVqChkJz5JjHRCu9fI/1xmNpOZD1qG UhiINIYoggUKbHny2/v01rOq7SxekrKRx3RGQKuh7WMWg5zrRCc5ZjkEODpVnMWYxSxfwc5mLUNe 8G6HMrFpTn00mxjafvc6zABHOs7h3GmAQx7nAEdn7HPb0HT2vJyhDYDysyjXaOc4A1oOf4xxi3ys 48H3uMc86PEOCpunHvVIhzjeUcogJQe7QhpQivwzoOmQ6zq0IQyByGKO7Q7AHumo8DzgsQ4JOWhB AMCgf4y02euo5SO6dYsx1Jsf6EDpSQPSz5NcU6BHNZnAjUpEjwB3IXNs6hrXWJCVX4QIbEjDEIA7 zqf8UyBcQGc/BWIUo3IhAEN02f/LRLvGi9QxKURwY0F37lGOU0kkAKmISNM9VZKqU6olUWNzrPFX fg4Hp0YJkVeLUAebEAFmMFO5eds4Vq8WvWhjKGIUo5gEKECBsldeoha1OMWFrmEIC+yiF7boGyQ8 da7+gKk/j8LymZohDQDEAHvOOAc96vEOc3lKX/vaV6qW9K9SrapgTCtXlhK3M50VwxkP9qEcrOGM 2xGjABRIHJd6RQ1WCOIUrjgFLKgFi2+VbGPw3ti1RPYIvsEiGb+49y8cjbCdAakYG6AGIuCQS2c0 gxsAGAD2vpSfLYkKc6vSHJJhtS+qMc1KWuvcsuDUtXEzI3bcYwYNwKEsYsyABSz/wAEVAOHoNxEj BgAY6CI6ETJHQOLmkqgEIyrRt0rgbQ+BGAMa4mAGNrDhDSXAWa2o3apbzGAJThjDGOJgt6LFoQwr sAExysf1y+Wwc1Yr3emaJotYJAt1n/ua2sQmi1s0gwqLyBrnopSKXu1w7soQhRrUwAY30IEOc6AD ACLHiEb07XaGO5zFt0aMRNzia19LBCK0cfGuW75qYXff+mpYQxt+7nO5iwEK8fc1Z5hDBgknhuY3 rwwZOKEPZGADHd4wh9qX4QqOwAMX0vAGNZgBBS7QAA5w8Tu2EV8WW9/dHYD1eFbeghlw3zrZV/V1 r5cvEYfI/iFekH3uax9N4A8//5oOIYMI0EAEClDANgxQgDcakR8nYEEOciCCHkQBC2Y45BeSIAgy wOGFYXAH4BBMDAYH2iAALyANdRRFDNgOQRADMVAABqgN2wAIw/IDNkADUSd1axAHcVAFh5AN3mBH DMgP8eANkcREkaRHCyQCEEAFubQuxERMt8RMNshMB+JDvIM9Y0MMAhcBPIAI3fcCXfYMcLANTVRH JGhHdnRBTngAHgAANiACJyAC29QEYqAEGzSDAXA/AmAA/KBHCDCGBSAAk0RJZ7hEASADGqABFXAA ImAB7rcAHVACHXACQIAETUAEEzACFfCHH0ADy4AADFQAQZB+25SIRQCB0nQBDf9QAF4YQREES8VQ IGUWGLjWZMiQTH/QiZyITuX0B+O0CJ44iuTUTn9wTqZoiuWUTq74ijPDB3vAB7RYB7R4i7hIiwOF iwcFTuE0UH6wi70YTrqYi7IIi64Iiuy0B7fAjMnYjIvAB7r0MLcgjbjIVEpFVhQlVV0FVik1VhIF jllFVm6ljRQ1VxAlU+joUnXFUauAUy4Fj3aVPisFj3mVVzQUVEy1VKiQUFQlVbTQC/uoVbwgkPs4 VdgoVf9IVQupUFX1j/vYVVX1VQMpkVUFVleljdwYVhIFUkxVjtm4jymFVyvlUXS1UWHFVjRFVz11 F4JlWiChWq01EId1FY81E4j/pRSMxVg0MRAx0ZOoxVqWlRMucQwdcZOXRVmeRRqcRRTI5ZSisRSo xVzJBZWvdZXDRZUr4Vo6CZQRgVgzOVpLuRaE1ZRPqZWhMZNYkZNoaRVceRczqRN+9ZZB+RDvNRq9 pRbtZRo/lpd1gVxZiVx3mVnHlVmipVpMaVoM4ZR6+V5zwRZ6GVuQsVvB1V/EZVyG+ZJLaZWGGZcw uVhw0RW8lV7a4WONiSJ7+V3bwRh5+ZixtVejaZVB0ReNsZf+1ZSa+ZlGERjxYRiT0R+QkR13qRaI sV8oghZesR3VcVyEARXW4ZiYoZrEBRnSkF+v+Qzb4JJ6EWQHER2hwiiOERbe/2UWr2FesBENBAAO 53AcQAEbpkkWPtFdy9GerKGXjDKf3+VcqumY+qkZalEOulEO45AO6BAc+TAP4IAO8xUUQ/acPHYQ hJGb9cFkZLYa2iEbzmVgqqEf1EAO81Ae7zBjN1IhFFIO5VCgxBBeBlYcy/Gdh6GcJJZi2xFozvUe 2IGJYGEMiPAd5fAMA8AO6WAPFUYP8zAPN/Jg17ANyMGbSoJijwkfkgmh0rFfJSIkIdIl09El5Lki paQO+mAODyIh+EAh9UBh9ZAP4/AO91BKYfJk/WFijsEag6Ea3YVgQUIcQQIkwDANezoQ+QAO7BCo 7jAhOQIhDnINwHAas2Fm1/8xp0rSF0XyoPIxH0UiJeaiKlKSZglmiSIyImQBI4aqIRECAF+6ZdJQ DdVgDdLADYADSp+CKvpCZgYWXkO2CNjADMzwDM+wDMuAquqgDtaQGxG2HmCaIR5iiWT2oqYSo7Lh HKmSrNnBGp7icIGhZMoAFlySJZ5qInFyII62Sh/CJgNAI9JADqtqZZemIYZAAzKwAhHwKGsGKtCB pajSKCyAABMQAWQSDasEDNeADWWCquTQq+cqruyJbMp2Ksu2rAoLMOSTL1WSLwrDJ47SrbzCI5Oy DNpXDat6adrAMLc2sd5aDCTwAAyAAttgDYwwCpBQCS17Cr+QDMawDTKwABD/4CGJozAA0iiacA0Z i6qUBjgDYA4OJg+XWK3JRipn1rALixrls2jmEjVfQitwQg1gOgCaZgwAIA3L4AyUkAgAACnIQiRR cgyMcC3O8iykYAvDIAwdo2rX8AiQcC2/YAmQ4AjQwiUEImKQsg0AoA0DyAy9lmkHcgj5UA/4QAwF 0i/OcWT8kmIMm2wD8yrPZj1rYys/1GjVsA7jALKJwA3bUwwCgAjGknhXYghoS7feQjLxlrqpOwmP cA13+y1yQmtxgnGO1irVEAPsogmCSyZoUw0Xkq0RdzBQIypINiuNm2xSezlLV7niAyYAcAg/RC+t cDupsAiGwG/ZunGu4Auu/zAKplAKv+ALJjMyqhtv1lIJmWALKjMMvuAstiBtxHcHPzBGi3AshasN gEAMviu8NJAGKSAA0xoltGYw4/NwmPMqmlM+a8NoxJs4vPJxqsc6AkBBykI9EUwwrAQAMnAJnfAs Nvct0GIJlgAKo1AKpFAKpeAKnjAIb6AEuOAHeLAGONADSzAGahC9TEcMMrAEYZAGYwA5G4I0RrMC d0A1CtN1DTw+oCM+V9M2UIxxPEzBY5MK+vMmirc2aAAFZcAETDAEfcAMKYAC/DQzg0B4fHMK9fYI ADAHeqAHb2AGXLAGI3ADQ1AHU5yta2clEpMDPPB6Y9CBbPIMeNABVdAol/9XPhRHfaATdp2jcVnj OaKDcWenLA6kNrFTNtp1Mb8DwYgDCHXQA1zABWJgBltABDkABEcwBI0gCIpQBW9AB25ABm3QBqJA bcmScZibCA+DCFBwBl6gBAKwNZVXeVFseTwEelGzzJWcLG2zy1RQDLfgJrHjDIdwNqMkOrosblUz NmtwDcnkgaxmCIRANPuACJFzDYhgDKlgPrvcKqz0JTzgDNxDDIugCTJwwIvcz8yceesDdp1HOgFt Q7lTDNiAS7zSCs5gCBsALDREfKnDQ5UsfapHDIhABfAku3kgCHrACHHAB3nTBnjwBmwwA1KwBVBQ AVbyyNVGfKkwABTMSsn/dA25IH1M88Q4hHdchz4GDdDuoww0VEM6VTpDrQ0UQEz9qwn6TAPMMwBK YAzIpz7sMzY0UAJ1cgReLAfPFAQzaAAt4AI3gANwsAB3YAE8MANh6ynF1zXEhwJwYABjaCyAUA2z ZA6fHMlgZ9BVs9Pw/HXvc1NDXXY0NNSFzT6fU9QkJT/edtG4AAcKEAP2IwCaEAVZ0AZd0AVNUAZQ IAQoUAQyQAM0oEBhiAC88kKC0A9gaER6xA8vBInbsA3DRAXboEcGoAAFkH4isNsLIALasAj2EwPZ EAMBENu2fQAKoEICAAEZ4A9UAAd5bX2mo9d9zTX33Nj3nN1fwy4ntACr/90O2nBH3XBB7TDe22BE 3bBE461HH3ABQzAEYgBASYAFAKAEyGM/BwiBL/RC2fB+/NAPAdANAX5ETxQAT4REAcADMkAA2lAA CsTKTHAFaWDKYlDhYiAFR3DbNGAB5WcBAvBElJRJmNREIH7gJB6GEIAgj/c1qcSmbmIsuVttvNJK 1AAAAC4AR0SCSaTjcdSASNQNB9ACCLADReAETPADNGAFP+AEUCB6GmABIqBCUo5+CiADM2CC4QDi Z9gOWY5E3hAAKCABIuDderQAAtCGGmAD8/cDQDB/q5wER/BEZ4hJmlTnlvQN8VAALggBEGAC57dC cKAa98kfojBgZKZpLv9Xui33IYtQDc+wCNmwCM8gABy02zQAA1QQA9sETVa0A0GwTTRABQQAAyng 53wuAj8AAzIgCEsQQRBIAzlgAguwAAcw3vwwhgGAAAsgA/sQDwHw693AAxSwAhLwASokAjGA7DFA fyJwASKATUWw24qITYD4Ad5NgfejDcOk1JIIB7cATP3b4riGYF5S6CuWC52Y7uqeiuve7urOia2I jPIOUAAVULOIi36Q7/q+7/seS/7+7wAf8AI/8ADvBwR/8Aif8LHECySFkgv1jjJFUjLF8BAFUoK9 UTQlUoJtUukDUbKwC2X3jiBPUlTN8DgljxqfUy0VUfZ4UhtPVDBf2FT/rfJH1VI7dfPpg1RUzT47 3/M53/Ab6VXhWFXliJLuqFZgRVZcxVYOL1dvVVcd2Y7u2FN25fRT71MzlVc6r/NA5fOjo1JGRVRR RQsP5Y9ONfbc+JBT5VXY2I1jFZFoz1UZVfTdqI1Hf5Kr0PZR71FHz44Ob1MlGfhVT5I+hVJarz4F OQsTeZFa1QtZNZFov/hjH1Zkn5EDqVRQJY51/1UZpVQhqfcTxVEb+VV8b5ImiVd/D/V3b/UlZfhX P/hTv1QGqVW0r/iNT/uo0FRPtZCLn5C0gApaBZG/H/zEn5ENNfYZtVVxT5EOKfdWRfp6v/YOSY7g uI5Qn/Wlb/0cdZWl/8WZnlmVNRkVU0kSRTGUagkSfWUX41+UflUTNUETYGmUMlGXl+WWRmGXSvEY XEmWJgEQ0Y4JPFYwGsGDBQ0OVKjwIMKEBBsqpGawokCMDicyXPjQYEKGGSV+xPiw5EeHHjdSbDiy YsGXx6hRGynT5saRJQVepKmRo0aEMFFyzEh04MGLLCcmpCkyqFNgKCOGNLlwptKVMWMK3bpyIs2Y NZfC7Emx61CvKbkO7LnzaMuyHUWalZiz6EmJFfVqFfs1602fQr3mTbuypl2xfTeebSn47U/DaetG m6lXYS6vjPcuLty54VbGlD1/fkx67OiQpw2DDJqaYWVjNyvrNUattv/lq6b9sqSGebPl3Z9zA/7L GKvnuMeL2jT+1eVb3DJxVxbMk/nwl9F5I5etNexf4g67Gt9cGCTwwKXTJj0e/nJwpZrXkh4uG/V7 stJHE3ZfuDnv/77Syi9kkMltNumou2pBshjMJTvgAlwPtATBy2pA1SzM7D76qEHmGAMVjBAwCCu8 LkEERzzQvvzWO25FAFnUbUMOa/wtRZhCnG06mXRMca/sGhQORR2Fg7A+Hof7cDsMtwtPviUlXMlA EI/J5cOtMJOuwJuWLLAiXHKc6coQqXywtwWXvBJFEGP6Erv59EsTS/0cE4wZAqIqaEkN4cusvj2R uTI2Lct86UFjzvT/cNHetgQGm2OMoTJNRduslEQko4zURPuAHHAzLutcphx5sjNmnHnc5KzGC0Gk s8crMSsQM0QfJHNMKo8hAJx0epP0x4pyUWbTRsvbs6IPP3xwPTo9hOnBN3OlbUF5wAHnnIvUQQed aoNsKFcn2xsvF1oNvLI3cn1b0pjbQLztXZqqKWecc9QZp6cdZ0LmNg/NjbKyZQVFFtn3uEzWSnAF lXZWY+6RZ95x0lFnHXXuecced9xJR551+u2Kz7QO7qxAgT0u+U1y0dxX5VxiI4edet6B55x77jlH HnTmFUeee9Ih18DbWj7TQKLPJXlfWyWtbdAiDT1W0HOpmabnceQR/+didjLO+Bya4VFHnWz0TfhY hUCe0qujie6XXIRxUZvhWBMll5ya6bH7HbzfsXuemMdB1bZ3lwXY1jE9THRlHRUV+txEbStQ0pYr iwaAcbQB5xp70nFH73ngwSefdSg255rCSRabwVDJrtLsPWUitzaiBRYUF2OUEVb2XHD52VbM1NEn H3NAXweeeea5mx588BFHY9oTDdo2x2U/XNIQyaSVeiuzbxy2paHnBhwAMk+nnno+z+d8ffQB4JoB +J012TXL9nDNlwxmvezHY7XdemSUSRvqdKXLeXeQhj7MkT4E/i4f+CAePrjhO0MAQILrGwA2tgG4 wx0tZbsjk8LS5v+r2KzPEIbgBjdGaA5zrEMffMPH7xIIAANyAwDRENqXLPW/ZOHQVa6yX7+o179Y BXFW/oPb4uTWMmPg4hkFPGACE5gP9enjGlO8BglHeA0JDmAbHLSVB98HNYXxLmUAWEYZywiNamDj azY7h+fuQQ5zTHCC22DX4X4mNhySrINHi5QG/+c/2xERarobYgAF+Dq5FYN2uKBG+q4xOgleQx/c WMfoHmmOEkoDEdWABjakgUUAsOuQ5ApkANNmvUR9IxHYSEQiXiANQ2BSGtigpTS4gUl1xBEAA4hG MUQZK3TtMYdg/CIPY7dHo+1RGYLcnf/IpIwk5i53ymgeEnFRjJb/FYMa21jGBK+RSRSicIqRHKEh sGiIAQgAmwFMFC5sB7V3Qo6dBejACQ7hzRcMAADcwEY10mhLWx4QlBjEHgf7pccvnRKHBx2mB5fZ PyJeCZD9A6DudGc7SS3Sokkshj41CY0yXgONn5zgIYhhDEUWAw4z6IAHKjCBFayAdvtzJ9I+tDRA GqMbF2BBCUpwAgxi8BjSUEc1DrGMVi6jGtJgKjewWEebuq1AgswjQz+Yx6kGkmTLfOgyJbo/JHp1 kXVcZDGeAYB+LuMZz0jEMrCBCFhOMBvEoB0i20kNbWxgAwzAAQCKUQxgIOIUp6jEIx4hCVP8QljG CMIISvABUdpO/3dhNQYADCGNZRxCs4ewZQRhCEXbpCuMzvwZMXn4M6nq8J3wrClXXXvRZboTFxdt Xl2padFi3MEcuczkAMoJyl0S46+LpKaw3EkNQYBiFKFgJBUQkAMW+GIUozjFNQRxCleYYAQp2MZg gyE3rrazjn89hCGwUUJQJoJdz1DHO+rxS4UJcn9Y1eNqhZk2rhYDou7kKjJmK1u3wXaa2IQm7f5q iHUAIBt/1YY0djkAfZqXrv+dKTQtvAxOgMIUpnCEJCZhC1sM4xK+qMUpJEiBGiTDF76AxCY28YhP ULOOy6xj7nBhCAJoQhPOYMY1sHHSvyYCHshj19FIe98/0heHsf917WuF5T/+MpmrFEbpNaExum0M V5sKFu4tEHENRc62uNRsMjU2PAk0OwISsPBFMlTsi2swghGkmIQvKsEIR6C5FKCwxW0nu9hFAkMb lrvFMhyM0mIQo4X4mMdkH0pR/kHUi0aeKn272mRMX1rTFJZtw/KBjZQmuhrWSAUxiHFWcAzXz807 xiVY8epKjGISkHDEhn9x6w3b2hSTqASuDfvh1/7XxmM1wAtucYsdKwIAL0g1LdN30ds5k6KAJOJE qa3krWI6ypmWsp+VEebZ3oJjqf5rZZ0Ri2KkYhF+BfdtqXkJWLhC3r74xYpHYYle31rfuN71rB8B CUagORT1Fgb/V6e5al/iQhuJ0MaxmWENCfrjpIkAB7QfKlH+9i/KlYYot6f6TG2LecqcJjOnr+nO YoCPHlUuhiEoEYtSO6MP2uDvf8m8TE4MIxnD8IWtk6HmSSR23/re8CMY8YhIwKLErlhxL4I9WybY oAUloEYxFpGNO9xBE8yAhgSJkeUoP9m1Hcd0x7P66P5KetvczrRsV83pYlxjHsOlhjVgToxUUMEQ NS+5mHEBi3xveMW/2DCtg75vWIDYFjsfxjAUPwn/GhwQS5iBCoQA7tkW4xbasEEMZFCFanBDCWpQ QxpYQAFqaDrTZJ/otPt7bdazXfYA9vs1hyvmRNzC1KnQRDYG/1B7k892F6loeZ7RfPxJ5DmxG4aF m90MC+jTQQm1o50frCCEFLggDXto98kVKYMljGENVohDBJeQBjV4YQwtAESTYy97+Gdb27JY+2ul XIybBx8Qt0gFLvCuiRrIhrezvSj7K2JAgWvYgz04PjVTM0iAhErYhMEarE74gz8YhDJIA2pYAjRg Ai4gvTLoPgpLNGKgACtIgzUogzgQhPUpAxVcghX4A6+CPxqsQVmQBW3jtigDsCnrO2WAhli4QVNj BhqoOGqihgNAAiAAAiLggA5ggVtQJOGqAh4ABAX8gweMBEf4N0joBEbYhEqoBAv8g0DAAzw4Azp4 AyXQAL9TBv/6i63MS7RbAAAlcALxW0EJGoMyWL8/qL8a/MMm88PXW6YbxMH8I8Qe/C9i0IRUcENZ UDdDwDt3oj/6wwVZoCtjgII3qAIlaII0GIQ/MAQ58AMLpIQ4kzNGEIRxaoQ4UARoSIAKAAIuCAM+ oDAfHLlEK4YliIMxQME3kCAliKlouDlALMZMM0RDXDtLdMPXMkSuQkZq0r1YUAa8i4VngIO/yj9i iC1npKYrAEEh0AEjQIAXYEFUNCxGkAYlsAE9dIMzOIM20MGam8cjrIIwqAIsOIMxEIQqeAM/6DZj DMgbdMNt60ZEtMQ2xMFkHDn+o6tUuIVYSIRnMMK++6/+G0j/utpGU+MCLmgDj3QDN2ADOlCDOFME RtADPaADOui/W+w2W1TEZ1gEUzuEReiDQxiHgMxJTCtERDzGJutG/upG+ksE4ZotYoiFQaCBAUiF i6Qrako3HOTBbrvEa1AERVDFKhIErXwBbNCGVCgIY+i/ZZSyHVQ1XFiEZtA9U9OEW8gARTJGg9TJ gUTEuVSGICREnvzJglQGTbiDRbgmYmiFS+g6dVBL+jO1S6RLZsRB/LtB3aEERiCEZuCDQViEAjAA BwMAQWgDPDADOYACJ3A7srQ9ElSGRGiFUjO1RXiGQ+C7Z9RJGyxEhazLxbzLNwRIx5RN+juEfdgG QDC1VmCG/whKAN3LzaAsxGVEzBs8BgkyBBkYgGewygHIBjgwwzmYgyvyAi34giNwyiirRMzTBmZQ S2I4NorbxriMS9j8ydkcSN1cTEfMTZ6ERjfEu1IDAAsQgDvgP2dYBgoYgGsghkIUUMdcRku8RBy0 gj3AAzrIA0jQA0EwhDxwgzx4hDr4g0ZQgzZQAzYYgxFwgRzAv7ajq0tMBThABJk0NfNMBIVkRm5L T9jUzRsMQhmdTUeMz/mcT6ZMBV64hgYQAEDYz1tgBhEgAAnivxqVTbpiASdwgiUQAiG4AZ8qARY4 BAMwgCj9AAZgABsQgiKYomdIIgGlprqkPxkYBAMIAFMjhv87WCsAKE7Xikr1lL05PUbdbIVbkFEa TVI+lU2Yk4UYEIBB289FOIQMsIIpUoIoOIM9GIRjkIU9lYVcuIUYUIArNTXNg4NsoII+SIVtEIBt AIcsA4RFEIAYgIEMyKcBmAEq8E1A2IYZkIECuAMDQIB2oAFTSwQ40AQu87u5dEZoVM86fdFVuMFi 1c1ixdE+ndFCpNFUiAUClQVmEAA4AAdt8MtEUAIv+AIssAEbOIIlcFIlsAIZCFQBQIAACAD/yzpt uAYKMAEN0AAR0IBKLQBt2AZtKIYCOIBKNYAFkAERkAEayAAIMAEIgAARMIBqZQZtgAMYAAAKoM7U FIU4tdH/1zzIFv1Vn0RPXoiFSA3Cj4VU3fRYnoxWMi3P3qOCDKABGoiAAliADMgGAxiCLFCDLZiC LugCNXgCFKiBA7CCGiiAy+QHAbgFQQ2COzgAfuiGbuCHdmiHbnjaeBCADIiBQdOG3xy0bTiAGoiB GKACGviBJTgEf8gGbYgBGmCrrY3adgiAA3hauOUHflDaA/gAARABGqACvX0GK+hbArACApABwR1c wi1cwT22ojVa/RSAxM06xjXaW9jPrLsFOPDaBrhSpTWAdpDbA+jcpWXabggCGQCCKbCCHjiCNzgC KJCCLOCBOWCDIIUDOLjWO2jYQYODROiGAGiHeNAGqIXb/6hl23boWqqd3asdgh9wAi5wAihIA/RT gzGIAwOI2nio3upth3CIB+yNh3Do3u21XuuVWwToXAiIATnEVAP8K/UVLvVd3/ZtX+HCVGLwWgPw XKZ9WqeFWtCVW7nd386tgB0AAiYYAi5YgiWAgisAABrwWrClAWrNhgyggkRABASIgX1dWn4IgPvl 3evF33gwgCItAqH9gCY4gjDAAjG4gjTgAjEQA9a9ghjIAAuAAAFQAKXt3niYhu7FYR7e4ezFYe3l h35ANOdhF18aL7KaLY4KM2OIwiqLhmfoX9BtBwGAWyvm3SuGWs4NAgAIYCZgAiDIgSg4giaVgRSQ ADTWAP8O0ICDhQAbSAEKEAANFl7g3VztbdvqRQEU2AANqAA//gAUkKATwAEdOIIU2IEJQAAiyIIG kNrq9WHuhWQfDgdvCIdv8IYDgAANMAELiAAaWBwkygViEIVyU5phS6n/Ul8DAwRDYDh0/d0sxmK4 vWPgZVocWIERKIIcKIKw/YEhGIIoEAFhhoAGKABhFloFeFkT4IF9cNrrBV/rDYA7qAIJEAEL6Nwr VQAR+IAR+AAb+IAL+IEcyIElBIIkyAJv4N5HnuR4qOQdjge3PdgcQFsaQNgGqIFFoAK5AZojMiRy uSbiQ19Utj1jkIZnoIK77WTBXeAYloFDeAbqhANBXdv/6g0AeOaHB+iABhDmHNCGGiiCNOgBxh3p GsDXbdiGpm0HBFjpA4ABbcjeR27nGIiAGeCABliAA9gBE7hXfNWGNdYAG8iBH6ABeb0AYY6BIiiC Gljqjy4CYWbqGlCABmiAnh40aqVW2VUn4folUD6iIkY07wsz/IvDv2LLO0iEZkgEtpRdODBaa9UG QRVUAygAbfZau0bqpM5rvU7qrGPqAqiBIAjsIIDqGriDvd5rwP5rwA6CBViAIBCBGhBmERhpuxbU q71W2r0DxnXczc66YshXQPgrOqojuUFilEK09kU0YggE1h4E1+6DPgiEQYjtPvgD2B6EQIDt2t7t 3bbt/9oewz/YgzFchEWwQAUs7uJWQOWugzrYA+bmgzrgAzmQbj+obuu+bkDwA0DYbu7mbu3ubvD2 butGg/G+bvPWbvTObvNW7+pGAzQA7/QOb/nmAwWkb+W+b/zOb/q2b/vO7/reg/4GcD4YcAIvcAMf 8OqebgI/bwZvcPTGbu/O7u12cPZ28Ae3bj7AbgvXcEBoBQ//cA/XhDF0BhD/cBIvcRRPcRVvhV3Y BQ9v8Rb3WBlvBRl/1hq3cZhjShmHVBnv8T8FWUhdBZINwlSQhVU48j4t1iMvVhpVcmQ1cmQ91iQ9 Vl6ocitfBSvP8irHciuPBS2/8i/f8i/n8i/fBTHP8v8lX3JeOPI1T/Mtx3KPTXOSXfIix/IlB3JZ aHNjVfI0T3PZ5HMnN9ZYQPIlL0Qp/3My5wUzt/JFR3Mw1/IWf3NIf/RVaHQxV3M1r/Jd4HI2v/Q1 b/NVoIU+H3U/V3JQR/I1H/RRN/JCX/VWJ3VM73NWZ3VGz3JaCHNcN3NaMHNLx/Us73VH/3ROV/RE H/Y23/IWz3Q2t/NRf3NSZ3VYj/ZSf3VCr3ZZ33VgD3ZeuPUq53ZGp4VbB/dduPUW93Zcj4VFr3Rg j3Quh3Fkf3MvT/U13/Qrt/OOJfNlJ3VVl3Zod3VpH/VNh3ZwF/dt3/aBD3dwt/Jd13Rut3RsJ/hf H3f/Lud2b+d1bN/2RP90eu90NGfzdD92Z5fzIx/0VCf5f2f2Pg/5Uz95LB93iy94XS/3gwf3Xih3 XTd4hf/yikf4MKd4c+/2jtfyn3d0jhf2Yo/1S7f3fJf2kGd5JJ+Fgx93g9/1mZ96clf0qW9xVEj4 XZgFg5f6gi94co/0qM95TY90rDd3S1/3TTd3fNdyZgd6Mbd0exd1Yu/0Yc/3lc/3mZf6rZ95ce96 rBd8qJf6W4f6r3f5gR/3gTd4xE/7bnd3uZ98ne95r8f6ia91LLf7oef4Yb/1pf/0vV96NjfyxAd8 cP97mg98cY/6wHf5wofxwMf5hFf0cBf7Xe8Fqq99HkVf9HBfd5wPdawX+3nP+YZ/dF+HezB38zF3 9i0PCAA7 --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651 Content-Type: application/octet-stream; charset=iso-8859-1; file=29209.gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=29209.gif R0lGODlhFAE1AfcAAOeVmPKdpvrX2/jp6/iotvu/yfi1wvzJ1+LK0dpylePU2fva5uzT3Mu1vdFS h9iSr96uxfzM5MWYsu/U5Onk5/zj9PXs9OTM5Ozc7Pz0/OTc5O7k9OTk9PT09uTs/Oz0/OTs9Jqb nLzc9Ozv8Zqrtq62u6zU7KTU7OT0/I/E3JbM5Kbc9L7T3dvs9KzU5D+ZvIjM5ITE3JLU7DqqznzE 3Zzf9I3D1KTU5Kzc7Iart57Bzcbq9oiboUi42Fy61FesxWa71VubrnTE3HnM5JzU5KTc7JG6xqfL 1bzj7tXz/EymvGTE3Feou2equ3S7zXzD1IzM3JTU5Jzc7Kvm9bTU3JqmqVu1yGa6y3TE1HzM3ITM 3JTc7JTEzqzU3LXc5dro62rE1XPM3HK3w4vW5H67xoTCzpbM1rbr9aTU3Kzc5LTk7JzU3KTc5Kzk 7HvEzITM1IzU3JTc5HiyuYzM1JTU3Jzc5KTk7LfHyWrEzHTM1HzU3XzM1ITU3Mn3+pzk5ovJzHem qLTT1MHc3b3T1Lv09YTU1Izc3IzU1JTc3KTs7JTU1Fd8fKz09Jzc3KTk5JTMzKzs7JzU1Im5uaTc 3Kzk45TExLTs7JzMzKTU1Lzs7K/c3KzU1Mfq6tj8/OT8/OT09PL8/OTs7M7V1W+WlbTk4pa5uKjL ydX29IvGwYiqp5/DwL7k4ZTc1Jzc1Kzs5NHi4JTMxJvUy7f066Tc0sbMy6zd0qjUyrTd1Mr165XF uIu1qp/Nv5a2q+T89MDe09j16X7EprfXyXKBerrt1ez89KXewIGslZXbsnTKlYXTornkyMzo1m25 ha3Pt2Wscuf36cjkyPT89LrduJ/Vm4iOh97v2pjThdrg2IzFcbfcpsvmtbLTloCrU9rvxGeIPcbN tNXeoLa8iff46vz89NzYctvVifXz1pOOWbuxavTrrPbtwuvbkufeu+DTqtzAequcdbiXWtnBl+rh 0HFULZp0Q9nQxNWqfd/DttSfj9GLfuKspfDQz81nZfz09OTc3Pz8/CwAAAAAFAE1AQAI/wD9KfAn UMFAgggTKlzIsCFDDQk1SIQYkSDFiRIt+suIEOPGiBcxitwosqTJkyhTqlzJsqXLlzBjejzosKZN ijYXjuw4kSRHnD5D7vwps6jRo0iTKkVKU2DOpxWhgrzIU6PVjCNdBl3KtavXr2A1NG0qtSZHqSdJ PvS5tWjbsHDjyg3rlCDZskCr6lUIMWtfrH89vp1LuLDhwxMNln2aF6RVtSghE/WLuLLly0sXa9ZJ 1bFJjZMxix5NOubm0xbPdpyadnDp17BfO2xs9uNN1Y9TexSsNbbv33Q1q6bNefff1EElA1/OvPLN 3Fd1gv7I0jVo0RMmNN+elIJp1LP5Tv9+az2026ICFkQ4IIC7e67eW4N/jtw88wULDhyYcCCC+v3v BXgUBfGVhFpPnl0n4EQTVPBPBesZYEB/6kVQ4IIYqkSgBhciyFlOuAnG04ITLPBPBhUcUEAAARTg XwQRZAhfWN4ReGGBG05kY3w7EgeYbeKxZtx7/jBQ4gIZZKBeAQawaIB/FSwgEn8MSGQjhx3KWBKO XfGoY44n7XglcXvhFNKIWmqgIowRoJifAQQ4iV+UEzFwAH4xElSPPE4RiMEAE4xZWZZggpVlmGNu eKhIYubYUE8/6ZbmSfzh118G/QigIpwEEBBBlFVqsI9+mBYQjzjxxPMPO6emKs89+xT/MJCgLy3K kpdWFsqhSTUyqquVWHKJ5ZeNXkkrj8XihuZxrqnUrGgMVOndkVFWkME/AhSg7YRsGsAABUz2pwA7 7pSjDjnqlLOOOu2Uk0468ZgTDzzssHOPAsPWupKiX+abLEqCNporsjjW2GGxxvKb68C9klmVmZBq eQCnBRxQQbVR4rdtpxUzOWEBBKyIjzvroLNOPPfcA4A++uSjTzvtqBPPOum0k8465rAqD60A52gw rsH6irCwxA7NpaIFJ/yz0UwrTMFDEANp34LZBsCxpvrpp63HLBIgoQEugh2BPe7Ycw8CHC7Aaade 37nPAOzgk47M6qRjTjv37PwrRl4u/13ooQkH2zfDPQa9q5gLC45004wz6phaeg0po8Yreg32tl97 zTbbE06ozzr2aKAkBVWz2LXXFWddsTwyx/NuzvXsuiWwBBf+87CI/6t77Xwv3jvjQxO+t3jMSrbV s/ep1yTnX0vIttWbB5BAAAbA404D/0SwdZwAnN6phFtXHOU+7MDrjjvomOOProUDK/vewCed++0+ 614004r3+q+OVBko6aSMWk+cOLe5OJnOdF4DQAISAABywENrYOPUATfXPLHhBwMauIfrygGzeKyP fk1T3PviB7z8kXBxJ9wfhzwTGAACLAJrK2CnDkhDCS0wH+7ABwEYqDkaIvB74NPWAv8qEKgNbGAf +jDX3O6VKIGhsEf1S6EUp9g4FPJthaz5nwsZNTHvzdCHYEwAP+Bhj+517wAE0EcAugfG72lLP/5Z wAQYsLUDtMMd7XBVFZP1RCr68Y9NFNjhhASxLYokWwboXvRMB4BGOpKRCuSHO+DBj3zkw4yOBECn 2Oi9N75IgG3zjwLUwQ6atUNvgEylKlc5tOJMDYBYAxn0DJjJWtbSktbjhy75kQBL1pIAjWSk1cB2 p/+oqJj4IZA/ypeudOyDldCMJiA99BlDSoQ/+mmS6dQYTADgIx/4wIctLTlGdOxSl5a8pDdZtjIW BZNjcWQTlEZnsHqQrRxmk6Y+91n/wkJak1FqOuaKHKmPTAbgm+m8JMtapkt6UPKc6fRmOFfGTTa2 bYgVWk8FLJBMMS3zbu5AJT9HStICIc+Q/dEenGi4sgcQIKGWZBkEANBQeDx0lxHFhz4mWlCLTuxO F6uQpSyEMHKV6x4mLKlSUym5f5akRALQJiRBBgCYWjKc+WgoOmyK03SGE6HizOSTnnSxKPUna4Fq pTrU4Q52fHCpcE0lW5x6RdlpID8HDOZOIVAAfNjUqll1KDqwcQ54ABas3gxm1j4V1Dqm1W82UsD5 yuEOBMT1sn5s6j8RJkt3riwc78AHAhpwjnnQA6aVpMc8uMENa2DjsOCMaCOJ6Z9Y/1bssUzzBwfZ KlLM+rZxdPUV1vQjgFGpCJhrtAc2WMuNc7yDGt5w7jumm9V8qJYb3uAGYenB3TG+IxzWsAY6fClO 1LEnfAX4FgntUQ50uOMeG/itfPFHmS1OQFPo9djX1Kjc5TL3HM7FRjiwQWAA25QezGXtPBZMj3cI OLzWeEdsFXq5CHorhRpo1x3jMd8Oq5CuC8Caf7KmIszpY8D+TfCDCaxdb3iDu/BARzhY6+JzYFfF 1uDGPMCJUH10KmUXluIG7lEueHDYw0i2lQv5o1/nfS11prLGNljMXGxsIxtTdm1zvXHg76IDuy4O s5hZew5w7lShC7WsH0eWx3tgIP/JHQ4uh9B4uW01eWvx2MY2tMxabLBDz+AARzjCYY8Dw/i7YvbG PBLNWgnzOJzv0Mc9zlEFCuCLQJfeEQP2sQ/1NqoeNkNHO+IL599mSMkTUZsb30hirRWgHeAg8HIF HGi8peweCIWHagv7DnRM99cABnB2tYuPXxf7uyf+9XcHHYIS1MMfuG4kx9jTqA3Uo2TwcHOpfetC QgkAiKy2VgX2kapwoOMbrIrHl8ORKpQVIGUtw6VN5wGP6Rr2qvgotLC9IYzQFvsc3vjuO4INcAAj Gx8B8GVeCyAAI4lJHjBjVVK3zc/t7C1fW5rA2j52j3bUg1U21i424gE2csfDHij/R9k9zmzJd+ga xvLuajj7umB8OO8eAwd4jRPtXEsu0JELpF6J97MjeZAMHr2lOEkt3jBioURt0DvAPgas3RmjeM/x 2NRO7YHmr+Y7ndyFeTrRqVMDCGAAUSWo2e8RjoLPmLk1Du0C5x70FpFYADbagDzi0et2KH2pTvXO AkBGgHgMWMqtHXA4ttGOb+BNWwmXtgFW7nWEWle13Y0ohbUlgH4MYFMF2Ed6FoBzkfeZxQA+Jy95 abXUaQrvOzrf9Uj994o35+KHM9iu8lN4bIR3G4MWdDjuIYDhbgqIk99p5S15DtVyFZyaBKYmK6Yp /AwAP9YfANrjIesUu5Ya4dDl/9zXCICPwTECuL0HyuGhgNqPFDOovqKtwEQgeYB3z9bQRjvCIY/i h3hiT+Zq4fJulfdN5yAMzedQlSRO1GNn7OF//ZAB14d9CzAA4zZjw4YN0zBo33BO0/M9IaYe+AF7 BKJ37AAP7TBx7jdNo0F/AMUzuac/FKANU5YN8VAPaDd6FFgBn0di6GUAyvdNxSYMwkAN1FBapoVm qIMkIYh92ud5IeZ/IYZiBCZl20AN3cVL0fckFgAhQxQBb5Z37WA9R7aC0VQai4IsvMJH8sAOp+R/ 2qd9FTgA/ZApArg1+1VVlkQNi9Bv1CAMpqVa8/AOFAU+o6eDcwKFUeh/7SBrVv8IWvSwS8M0IW6C UQvQKPYQD+cAX2YITfCHNHXFMPwjPFiyD7DCHgtQh3I4h1Hog3i4SY2UD0RIDSHAA0EwClsVdvPA AxKgD+DTPAyXMUMUhyM4en8WXr7XDOEnfiCIJGWVMY0iD+tAD+9Fe53IgogBiuwjSPETK6NXAf0Q gnQ4gSOoOpiTRgGgD+8wiyEwCkHwjsawVTF2gNTwDqhTYWa3g9rHg8WYHgIADnq2Z8vIegRwABz1 jBdjio2iDijoDm91jX80KLTTPvTFNE2YijmYHp5XfflRYvrVKfogAVXAA6NQkiUZBE2Qkk0ACOgQ dibJAyVwOVkjhYlogfw4giH/1g5YdmXfcEnDlCJANUQXow7ocA71QAG0Fw/lQA/4AJFMZRhRlCgT p4I7sorW8g8TKIfGV2IVdA8NQAI5AAhiaZLuqJJNYAyYBw/nYAyAwARBAAgN4Ho0OSc2KYzYJwDy oA3foGflFTJwJJRldQ/o4F7x0AA7kg7Nxw5OGZGGwiuHY0LCQ0KrOADX4nnEaEweuV8NUAIkkAqe yQMkaZJiuZJiOXD0cA7oA1qAkJJBkAoNcCfF940Y9YwUOHpTFw7fIAES8AA+JpOAGSX1IGjwMA/x 0H56117ZZo2LSULZCEIIQ5WNQoGpeCJ1GI6W4pHa4pXfwAu6IJaemQpiGZ7i/xmexnAO9XgOvlYO VbCarAkIJIAAxTibGEOOOLkADUCERUiLvSghFIJ9NoIAbNdr73APTzMv9ECgy4lhl1E7gLSDSYIp 5HiH91ACVcALkiAHGJoDOYChHNqhYikHYjlo8Yie31WL4wkIo9AAsfmbtIl9dsmHi9CH+gkBEIAA NroPuIWUGvANalkO8bAP12Y9nJig8bOgvwNZ8ZN9/XAiEDqMd9gO28ALpdChVJqhGHqigMAL4VAF 02UP0xUCJnqiJZAeUIKQZiqMCFCSMboIMFkFomAQ0oIw/vAN4NCS75AO7tBg0EmkMNicSEpC1leB EYgpidiR2dl4pXChHEoGjP9KBhyqoRr6qIAAoqnAC575DvYQDp4JlmEppjRpl2VlkxRYAjwwkiYp DCRwB7QAnfVQlNugLvEwiHzaT3Exf79iNCbkhEMUgdaJKcP1at9QApLQqIw6rJIgCZCarJGKrHKw oZ2aA7xQBVWQAyRQCjlgrcqqoQggAEFlpoBJnwhQBSQwrpxKriVAC6LQNOjWkvNiZMo5q4JEIxoC OLgTSDYinZR5IhdzLf93APfwDaVgBEYwrMV6rNlqsMu6oXJwrBc6qdCaCuSqoeOqrHJQAkL5my56 pgJQApzJseOqA+MqsKpwB6Kggv6gieWwlPTQfvAaPDRiq0vTL8Fzrw6qr9b/IoEd2QCJOrAMe6xk IAmJyrCQKrQLS6UKCwi6AKbkSq6lELBGkKg5cAcXK27CeKZRggAcm7UlcAd3oAMCK7IkO3EbcA3q xl3v0LIuCx/tc6RRtKc7QoEWeC3/0A/WEoFACQEB27N6Kwk8u7eKWqUgyqGAsKnV2rQBqwM6cASI awQXYIk3G1QsWlYhprVbSwsswAI60KgCqwMki6vxgD7oEA9hiLZrqxRqKDS2g6sC4w+jt4//8LqW mSR0uwD7UAJ9+7Vf27S4i7vDWqVN0KG/y6F8awSqULyIawp3oLgWGwHW+bh3OURuArlYy7Fci660 YARyIAbay6hGwLnXYDTy/0AO3HWUpFu6MnEjiMO2f8o01yAK6UGHlvmEdAuOdnsAJeC0u5u/+csF ZKC9VBq8F5qSHcq3qqADxmsKCGwKCAAlc/KgFwOAQSm5DMC1XIu4iBupKikG3KsDg/C9CNMOpbWJ A1C+uNcSf2M46othokALZ3eZLrqk4XgxG4u/+ru7Xvu1/avBObzDHJqS2uu/fGvABZzAd8AAnzKB cot2WNsAEcQe1SJHJbC4GCzAcpDBGry5JVssIxAODuUO7+AP78qn+7IlqZs4kcmcNiIKd9AAw5iR ArCZDTABlTmCd5C/N1zDuMuoOty/eqzBckAGqFDFYuDD24sKiFvAOoC8R//ywgywmV9bAnxVMYwV JUFbxWZ5yYR8xZybro3iD+5gWt9Fvmh7vk8kiiOEP89JCxyLkbG5Dw1gi29ZAhiAlQ1nuza8uHaM y328xzmskmRQCTm8vXxMBt1rwZyLJyIoALRAw1/LxMeEUVOKySjZBNNslj9MzBysOBvADqr1Du3V DiPcsikxf/WavsdSkTsiCpxZBQxwfcX1lYDwjoCQAwJbAghwAAhwx19rzIvLBcbMvz/cBEzABFbw w4MszJeQ0H/wB4/wCGZwCY8QCQmduIqrA7SQIkMkAFiLx08bl9pyMSRgyWY50G5ZzdaswWXABabA yTsynPRQDgDmQeI8O3b/VdPlvD9Q9JwCQwvjKq0KIAD10Jnv+I7NWsyI27W5zM/+rANcYAT9K9Ak zQQ/UNBOQAZl8AdmEAlrgAaYAAuXoAma4AVivQpkvQqCQAVUwAIIXMQusgDXy9FfqwpxeQADkAOE rJJRHdVm+QNNsL3d28F5Vw95GmPmFlLw+oLuQ8ZOFDjyN7NpzJmpMJKgyQNiOdRNoKFGzdRcsNn+ bARLTdFHsNllsMsEfQVX4ARuUAZmsNVoANZpkAaa8NqagAmYoAmkUNa4XdZnvQmmUAIN4Mj8rAOV UAn6/Mg6K9Ijndd6nZJT3ddOkNIrnXfmgA6DeIL0YA9J55SJ3TthMorl/xw0IRQsPP2ZoFnZQx0E RZ3Zms3Zm23BRxDao23QGuwGqT0Hq40Gk/DasA3W/L3fm/AIXSDWXnDbqyDgBu4FVOC17n0Em9Dg 7424m427XuuoUL3cyr3czG0FV6DBNpDNBDIA5bBgbdhr8aCYRDrOPeM+23jGTuQPd0ACk13e503U mxvcisveEL7ZelzVqc3Qq83ak9AFQp4GkzAJaIAGQi7k/K0Jl1DbYD3gYr3k/E0F7/3egcACXYDW VKAJSf7el8AFo63HKXnhyq0Eyq2SPzDVYvDcnMshepeACGB/NjWki2nTC8M7NX00Udk06pwKMU7Z 5z3QTaDeml0Ghs7ZOv9gBjbAx4be42Zw312A30c+6UU+6UiO5F2w5JhwCZnO314g5fzdBbS9CVnO AlTQ6QfO5ZGu6GQg0BVO0kpg5nkt63nN3Gl+2mTABUeAJeFrWhggDwOHDvUQxiv4mNsdOGr4N/aK q+P95zMu6N174/E9yL7M2WWA2mXQ439g32jw2pFu6eAO7kUe6mB9CZEA6uiu6kme7gfuBWnQBWtg A4Nc5rE+0Gn+A0xA68t97xtOBjZwBN87AumgWg2QAddQp6IWzhBpxnmue/2CunyULM1ei6AZ6CTd 12J+72luBRyv4U6A2qlN32UwB1ud3+9u6Uke6UYe5Jk+CekeCX/Q2un/nu6dPvNPHuVoYAZz4ASv PtCxLutpTuZMYOsavua6nq7mUFrYrXc5V4bXOIqDIzgPz6DM+eKgSfGw/I5nPubN3fFef9qpbegj v9WvbeSSfuRFXvNg7fI2D9YN3fY0n+kpP/c1/9posAY73/M/D/RCP/RNsPGn3eEssAHfwGAYsAH+ oGccpPB17rbcKEU8ffWTbfGCfvF/7/Vfj+2G/gYk3+1GTuRFHvorz99sD/dgjQmo8AimP/N0L+RH nuT6De/XbgVRbeY/L9X4TuZEv+YdPggUoA6lJQEW4B3ssFXxwADE7n576vghFPk8QPHxPNRRzdck vfGY7/H0Xd/3zQZs/xD6bKDfZQ/bpb/6S24Gf3Du5A/qQR7qrg/ur+0COf8GPA/re4/7s67XG//x ZaADgQAQ5tDNC/GPwsFv5+jZk7fh4EOIESVOpFjR4kWMGTU+9HeHRCoeIXjwABTEZBAlTFSuZPKj 5Q8rMWVaueLGZhkzaNBMmnSDJxueaYSyEapJ0ySjSZUuZWo00p9ISJtOTZqmi9KrRrvo5NpFaBo0 ZsqIWanErNmXLs+mVNmkyQ+YV5yU4cIi3Dx68RxSGFEvHLp05jYOJlzY8GEKGjyCFEnyJEvIcGHO lCnX5pw1k9jonPS189c0n9MYHa2pNNWmaCIpioQG9dSiTLvM5qoTNP+aNXPcWGGyFi3c3pBXwo0p l24gdPTmNRhxcEO7c+fi+UNc3fp1jdcWV2lc8rHwtDOvjCfvZA4dNGzUqwfdPg3R9ktPvzaqOhKm nfSTeqEqlHZtoVxwQScz5nDCih98U0Iyl8CTjKa5bLjGnXnwGeehAb75ax129sLuQxARE6WEHKrg bqSTggAvrcmKI4+8N9ZYA40b4HNPKEoouXG02ObTTxM0MImktaVIUYo/1L7SSpMuJqltQJ1uuCG3 AyVTKSXJ0ILsrbiceCKFb+aZ5x0PN5AnOXgQ8DBENtusaEQSSDiRhxQdJA7Byl6U6w0zZlxvRxx1 BDS2H5eaBBMhXZv/ihRSkKyKP/6K6tFJrm54MqwynGDwLLgWbDC48ORyIgVqxJSgOeeu+asceVB1 89VX4ZSzO5OujOxB8fR84o3zMrNxUGDjK1QpRBHVxEgvGFWW0aSMPLZRI0uT1KpKdZqRRjToeKPK LLNci6UHRTUlnTENemgDf8CBZx111oT13etknZPOWoV7sMUraCpv1zmgoGONX4EVNFgfCw3SWKOW ZZQ/aBVO1lnSSNuqNtyuxW2OJxDsNkFOP2UQwie6geccc9Y0852R74F3Zeu0K6GEeU1KaebhGGwx zyug4JWOf2sM+EZS0iBlYNCCVnLYZ49lsotNMElYYYeXfdgLaXls/5LiirlaQ+crbLb5LJU+hpCL gehBwFW+VA2HXbRZdhuja2h5ec4qvFMwPMrydRGLPd7wV0b2BF4YtBzToGTZgulzVllNmkYKamWn driqo9OwtDYZLV5DW7297tjr4pwo5Zx5qMkgIofUdeced992PSJ/5Ia5sbpRutvmXF/Egl+eAf5Z KEYpUcNwqSGHmipmm108eU2MNd54LyDVhJYGGhjEPxcutzZzzA3UeNPPcafpCXXgoUceiUZQ9Rx4 Onz9fYg0kL2ExlLJQUUFsRQ7b/J29/vfOgQsWdGLnhqUdbjBPY9xyktYAx34rORtYhMKhFz00jAI CUjgAQ9ogGlcMP8xzMlIa1vbjddMiLsrAMEUFDJb29D1l3Q0BH7wG9HLQiCSKtwvf2G712T0RhN9 XYFvUIADHQKYBhyoQYlLZGITlUhByDEFYkp7WtKUQopVKGsVWXQYAUmBwQxuEALX2wzWMjejzNHh CT/83gnvlMIQiIkefInICOSBsntooHUzfJco7jA32jVhhyy62XhwRh487OE8R3RiI5tICgNCcYGo YZzCGpcULmIxkw9TGBg1mMHqUaGMIqzYGdP4hh9+zVOSaYJMgFAGcChEHBPZgF/K0Q4+vi1uf6Rb SfInvtzpSU9Y0ALA2uBIZDJRksy74hWNp5RaaGKLjMriNCO3MC//ZFCb1WvAPQYxyu2ZcnOb29ZM 3Ci2K4jCHfRQhwbaRoFawqMc7MjlyuTHS9rp0Dego4yLhPkiPGABDnU4ZjKTCUlJUlGhymMeNaeo yWlusnh30CYoq3cPWmivlNcSJxQOFJNzfswHTrjLcioSjnOgg571hJUfbTiSKpDAdvvcXxD/Ocwn 4EGnWmDDEjOBhExkwqBIeOIyp9gUZkKQmZqEnDWP5UmLfuMbGA2hOM9IByjsxpwbu1NMgCAJ0snj GrSkwDbQsQ7BvJOlLaPFH2/Ig1SQQJAKqulNr4AHgN6VbzrV6R6IcEygBlWwSCBsIxO60AdaUakK u4VSMsnF6E2R/woVlQA3pRoPWoyQe6bkGde2Kr7J+MAHQNDGOsZxjVeQ9S/oiAc81/qh2OGTBzHN wS9rKhMf3JSvu8UCFviaBzj0VA2CFawSiapMCg5rqct61iqKZEkkOaoB2uRg9aT6Dcxu1KqbowMc 3oAFNoJUbKH1QSnW4Y5wBEIDE1HfO9amjgG89joaEAX16AfXOM1Uf7jq53jwmlu83pWvvu1tbwNa 4DfUwafEbeQqiKpApjgKacw1yiYWiyylUIKiFbXudTFrSu3yDKtv2MNHKQNMK4gWCCFYSAkEQZER KKAd6ChHPDAg3+rUl5dViKtc6XpbgOJBtDoFQ5EF2oYz1KHABP/GQh56uwc6FJTBSxReUZ+XRaQp DmIWllpTNhzGDku1HfG4gwi3S04Sr7E4n+1qin1QifO+4wivUKsF5PEXd9BTrajDMezaOjsTkaC2 NG1zMP2LBzBgAQxaUEMfHN0HIixZ0nkArnCDikwKOjfLhZqN015zhwdQN8yXjccmzsyzN6SaxOAN L4pT7AR2rIMeJaBCRZoTD8Cwwx977vNE6Cs7E8VUpoQutCGvAGAiJxoLUtjBo/vQiVN8t7dOLjCl 96CFRlTZkRA+6qaX0tilNM3TVAE1dfXRgOuKOR7fyFoarqrqVO8hp+Tpp8bWLFodwGMe7TjCi2FM gXfQuB693kj/3BoAs0DL9QXE5p+eEK3sLLTB2Z3wRMUb0WQnU3ra1n4DHdKwbYUBz9sjLxZq7gAB CITx3Om+LjjY7Sc0jhjee/Dti04crnyJNhzukAcn5rxnC6hqHelwH4j22KbYIlzYgw5fsRGZ7N5G YQdJcHQSKg4KrGcC45TmurX30Lc6aBu5FPa2hZUC7qSgPSmDCETjxD2brCypAShXObpZ/o1sfCMQ FKPDHPymhXjX3JBA/Ky+YuIDVaTjtEdggUXsSON07JrgFqnvwRPuY7Ss8mZ5wivUn1CEqifB6p7A OtY9MYeuf131q4cCG3Jk5Wt2mylqf80taA9u29fjHhBAwCDE/212uM9mE3NPeQZXfvds5F1rc2B+ qgFPc98GmN43j8vhYZ0OdOjg5xWxwDfOikteb6RM59rA0Q+T9MsPujdmIU54c/v0AkPhDKGneMVJ X3o1bN3aXv/6G4KLwOcZuaawPaoYBANAOQMwAAQIBESxsE1gmqsYBLqru7trB7wDh0Aggr5jPr8L vOjTKWHqpzYrL3iwh27YhECgIxjzC3ZRwYwwPw8ZgREovxD5NaWLExJYv/1aM9zSE2XDAiLoA6oT wvsrvdLzhE6AgzzYA65jwiVUvVTzOABcmKRqCrNjiis8O9vbQk1QO1oIADFCQFpoQCZ5wC4gPnOz u3SzQGnIu/8CYT4o6Jc5gD4D4ys9EUG4II/RCgd4GAdiCARRCD8LMKt1uAcMCD+I2AsZtLUZ5ItF vI5dQjgcZLpQOaRD+8EiED3Rozgj7ERQ8IRMWD1RFMU3aATioUIBTLstXEUuTDujGIQNEiN9CAAC aICmaZzZCASUKz4NOr41/IY23AZTgAJFOIRD0Bl5W7Ld6rzBKzw9lIZ1EAd1uIMjcCdbo4BwKAd2 iS+NKL9HrKMNkEFU+UbEuCdJxEEdrCtEOjZEe7I20ERO7MQi/MSKo4MnJMXVe4NDMMUc0ZFU5EJW DEi0AzdaiMUNCgBahIA7wAQJ6gJaQLnpUrm7+wYLzIZt2Ib/ZuAZONAZSTOwApO+VvuY8RipdnAH eLiGQKAzx6uHeHCHdGAdRGyO8gvHGdwLm6RJ10LEjKivucHBEpCDteAvfwJBIFA2+YPHefRE06u4 UBzFjiMxEuubfRSNVOzCWrAwgRRIo7C9BjBIhETIWtyESTi5CTS+e6hAC7zIbfiGSICDOVS9jvxI EGxGmRDJY3OCd6AHc6iGQXBBF2wOO8vGeECf5hDHg5BBb6xJcVxMh1hExDTM6ojEhCOR3xBKh2tH mquDJOgEziS9f/iH0gNNT7Q/T6CDa9MCLRjFvlG1Q8iMxHkNCcpCLczKrVzFLoQAAIjFr0TIc9vF itKHezhL/5ZrB3BQy4s0hXgbxSeQtLkcyXqTjJH0gUvQxnOoApV8iMXMznCIh3TQBwvITvCUwQEY z/CcQfNczOqgrx3zybkSSn/yLyMDws3sTFD4TPv8TKVcyh14gyxYzf6LN3jTx8wYlti8wgIVt2JJ UAVlyAKlBQDIzQfYzQcFgLI0y3pgOW0Ah+LcBovEyORUPZ15guUEg3a0Q2OjPn0ZrWYwnwZILfQs T2x0B54rz/IcgPB0xOyMzD+bTKbzFEO7qx+MgvmMx/vEz/ykx05ohDdAzagM0ABVhAGVjUnIigNF UCF5hEuIBS29BC7NUi6NBUywhVj40jG9BFMwUwBIgAR4AP8A+Ep9eFAwrKgHIIB7qAdaoIWW01AO 7dBw+ANVg0K4LLBEM9Hpq8v2O7YVG7pvoDMaFcege4eh2zUatdFGHcccPQxzFLY4KYG5eok1+6d2 xIIoeDbOrM8ivc/8JM1MeAM+QM3VdFJ4UwSeSIpZZRJMED5EuQ8h6dJLeAQszdIx1dIx/YNHKFNe PdYHUFM1bdMA0AdnncVQCyMDqAc7TTcN7dBtmAZrCIdK8E8QjcolKzJCDS97i04bSId1eAdaqFTx tABbiofvZNdGhadLNQyXghmfVL+uAtVQhQNS7QRTPVVUHc37S9L/ZNUAfdU3gFKpOAo0mI1DydUt PVYu9VX/i30EWMjYSkAFjkUFWNjYjs1YWPBVCVDWBGBWAMAHfLAHfHBWDaJTO71TqQIH4uzQadDW cGiGP/06IjgDNmDCuGxOuvwemgCC0bIBXGuHaJDXEei+XDvE7KRJpgVPxPgzHCSBl2nPQxUmvDLK f/UEgRXYI/3EHYCDLAA8AIVV5mNYo3AScRuSLz1Wi4WFP+DYjO1YVABZvN3bvOVYCXAAwF3WAFDZ lbUHewBOfZjWmL0u4gQHbFVLnYW3ItgByv1ZuCwycQUCINBD6htJIFiCSkiHdIgHBIjXSrWA7SyH ezDdqZ1Xw3CZErhaytzBywTSRNOCHeBMigtbsU1VJEwD/zhAW1jllTn4g7XlDPsYkkjg0vuIhIut W76NXunN20qo3kpIAMB1gGUFgHxQWcO1B3doh+Bc3JlNB8c1TuPswDfAgWbrA8q1RycUVMyNTh+4 uaIdLRpoh3SAB3wQhw5gVwsIBRiqB9bNTvKc2sO4103NWv1puJp7OCyoA90FW949Vd+tuB2gAz4o hOFVtT/4YEUIYeWNBDO4WF+92479g41FYbyt3r094UqAhY6tBFXA3sA9We7NBx0GX3eIh+CU2esS 3Q1F34u8BF5RA00cQiQQRWrD3PcTrRTbKs8VAht4Bxk1B3Mo4MW0gO8MunDAPgX43+y0AEpt3cOw 2gWWhP8dfM+7uoIfxF36rGALlselBMVC2OAO9mDjXVvWWA1fJdZH+AO65diNBdkY5lsWjmEZpl68 LQEb1t6TTQAdzgcellEftrtmoMh0aIfHNc5y2AUoQOIk3kQ24M/47a0iAwKQrF9DLdolAAMq1l92 gId90GIZ5OLv7IBqoLF2YIAC7mIubtQuJseC+6PYXWBBaglLBNKAYsI9UIM4luMilUfS9IRTyAQ6 KAQOdlL1fYMPBuQQVoQ//mZyhl68XeTptVt0tt7q/dvsNdlJrmR3ONxabIZMFmLjTD61LIdmwIFR 3syKQwHT7E9qUzTMBYPNFS02iotjWwIhoIEjYId2gAf/cxAHW8ZlGewA74OHd2BdXMZoGmVdezXm BS4F9qs+roXgPZBgTpTmOTbCanZfNTgEwNtmVWu+5vvmObDYcv5muv1gVADqkJVhFh5qja3ej23n 7IVkNd1hGZVRw8UHAtCHEvgGdjDffNbniywHaIDHTSzCU4CC/jzlg0ZohU6luPjch4YBHeBOc5AH f/joYG7aue6Hb3gH1TVduf5our5luu5iwhgBc1zgn2xgNtapAssCKCDVgHVp+zxST0gCys2ERuBg mw5QDuzpDw7kzeZpQD7hRb4EkZVh61VnjxVZpK7hpYbnlX3qeTZcfZhq/eXki0y+NsRWcDCHTZzg TkQC/y0gaI0ra4QuVDxJoVcWghhQgTsYOnVgB4ve670egb94BwwAZuiO1+vmYkesIxjzoz9aYFUI jn0FqERjwiw4g8507Jf2xE5w3x2wBESw7JtuPuItXm/W7M7GWLqdWxQWWUJOav8+bdSGhRJYaqaW ZHyIh5Z87aiO7Xug7T3VhsfNbXPQ3VIN2NJjg9/Ogywo6LLe3GMz1PFQaxqAAjRohniIRvTJ7o82 h3eIh3aobhafcQvATks9zEdsjj+L3ZehTE897IdzsiKIZvU2UqX0BPem7DewbGOs78wuXvyO8ozF WP0W8I8d7YwVbaPOWHe+4e3VBwVvye+FbWeNh9rWhv9gVMtswGJzQEIiHdhPoIMsAG5UPmijpcu0 dmjkNgMXoIVySAd1aId+6IAZ1+h3OAcJyAAaZ/HWVZ8d73FOxZJD4qtEW0Ii0N3GLvIj7YRm2wFK SDVtNkZR5xVj5MDM/uZxDmQT/mzQXmQsd3V0Hu1deOQDB4AyF/MxN9weVvBv0AYJv8ibzYZq2Etx 6IWW5l1OQM05b+IPj07xMm6HLvEjQAJ50MZ0EIe4nvF+QCkbW/TsNmMdg/QSMIKTtkQi660syN3d LfJpHk33toTuggM4KARRr3dRN3Xm++zOZnUTfvXRFnArH+1HKPDVVlZbB/N4yHVdf2oYv21gF/a9 fIb/ZyAGz6xgUABePlj2OrfzhGblH4D2tTYDKuAAf3BrlSJ0Fgc4jlZ0b4/uqZWfR38ZOeAhnFFl CMaCIV93dn/s0eT0HcgENoADPuADeYcDe693DlQEKGd1fs9vf396qIeFLvfygwdzwiVcMHft8D3f YO+GiJf4aMj0sP0Eee/wLJg24e54kHJlIdjzLniFDhgA0Q0MeaDxAdi51W15uW7duJmfl1GFJsAb mzp3LIACgBZ7TXd3R6MEeSf6oi/6o+fjfDdhyqf8Kb/8qB/tLp36wG3TZ9WHq29ZfdB6d7ilbOXQ bqgG1Zd4YihyJBD6Dg+DMDBozNVctUcQkC/xNWCB/1DoAArQX3HwYb7e6w64huRoAJbf+xlH4HCH dCP48cP+QfQG2J1vd5h+NEt4fO2HfKQPZ3F+hBBW9cof/1Z/dY89fwGPBVqH5A1y1tAX/QWXUXKY /3XIhmnYBm1Q/dVvfU0HiDpwtITJEwYLFjAKFQIB4uOhFSs/rgBZskQIDShmXHyx0GFEOnXqzMnz aOEkSpQdvqGDByFDypQjYsocYfMmTpwaaNG6U+LnTzlMfvyIaOXKlaNX8OABk3BMkk6e/lGtavUq 1qqgtnLt1KfPjkZ84JAta/YQHEWH1h5S5Pat20d/HtGta/duXVh69dLd69fvLgeCByd4YFifPnyK 8f8hRhzPHWRyksmVA7dtW7ZqmqsRA5X1c9VTcPhkyZLn9EKGDSEapXiRhpY5aATNPMkuHcl7AzrQ RDki3Ll3DGD2Lm4hJ3Kc13j6BKqKyVCiEZFSV4gQy5lOnTyD7m6V61ZPYPtYMmueLB1FdOiwhato zpy4eOfT13vp0V++flUNFlzYMIAPKNaYPo9B5s5klLVTzmXQaPYMd95llcZopqGWGhgNOeRDaxUJ IUQWb5jhBQcqsVPOSPdQ0AFvNLEI3DkLEGdcTMnZKApzQN1hhBLRTYcUHkAuFIV2U0noHXhbefWV I4acV9Z66qW3lnvwyUdfXffZpR9+sHTpV1+XXFL/AmEPQBCgYQPqQ4ABBUZGzjrrSFZOO5hlk80y EB752SdkWWhQahpuyOFRFV2URQwxcCTTPXGaQ9KKvXVQTTj0xPgRjTXZiBMFOPakoxhKEFUUdUsx dd0e2XkS4Z5ZJSneV5YggsiTdECpnnu5XomlmFt62ZeXYH55SSxkCvZAAWei+QBibBYYTzmSxTkZ nXfeKc0zrX6mBh9aWHgQhquxdoUTHsIGxQ20pdSBOeWsM4488OyTQYspZVDPOfTYM0G9mW6a0zU4 NlfCHTr84OOPQF6HBRHasartVUku2UcdTpq33npwYJyervHtiiVdWoK5V5bBinnJLo8Y64CZyx5m /wDMz7obLbXxtPONteBUEw3EV/VJmkGnJbTQahtG1NBFID5BhBehxPRRO7il0w4+A9D7dDXo0JOP SZke9+9NogisoxFDGZXwUtdlsYNUPbsKXidJfKVGHHHAgcjGeG+Msa7uPaJIlrzmpV+wsFzy1+Fe rpzAfwFKAAEEBhQgc5w0S+ZOPPfgDA442nSjp9tUcettFmGAG+hDhFoBhBNJZ6QCR/161IE8IZmz TuZXd51BN/neo7tKvLHYItgWdDo2wXeIIV1rpeJxHZHbhf4deJ7E3QchjtQdRyOzem8rxmtE6VYk VSoSSSzkR3JyyHb1+kiv+clveLEJ+Me445BL/v8sOOuAU47lIJO5dnBOG9rIDM+mh4IokMZ0BRma anzgkOmU6zVaUMENXjE74QnPAupIBwgxN4DZoaQf3/Dd1Th4kuF95CZfy4kFNCAwn9yhYE0oSlES xhSnYEELbDPS9P7xquuRxw5+qEMcDGGx7+1NEWt4S/kiUb7zSbGK6GMf/OLXvrywzy8nO9wlTGE/ BzCujBKQQAMi1yZ9tKONBKTZgdwRpzgZ8FrZCiInKuTAMARKQ6xBGoiygK6msbCQHRgAO9qxjnKY ox3soBcLT0gPfWzQkCx64aZeMcMa7uiG09Hh8/aABSlI5WE9e5X15JYJOxixDkik1d2YGCWOQbH/ ilSUYiyk+MX7vC9whhOTKU6Wny/G4gH3M2Ma1XiPe7jxf9GK47QoA46cdWMr0wNFHfighz0KoY+D Wh0YlmC6LMCACLGzZCHZ4Y6Q4A4DKVwJCtHJouIdryecVB5RkAJKVKkqiFQZ4pLaYMQjcg9vsaQD Itag0IWS75ZSVJ8iiJXLXd5FTLYIhi98sYxlvKKjr1hGRjcRTDCKqQFlNCMalXmPetSDgM48UDSp dSfOQSMJptQWJ/jQQAeG65usA0IYhkBOc2pQnulcRwjvYQFIdqBSXDMqPcVmzxqaQgzNc97zEEKE JKzKn0kCRSr7sMojItEQdejeevCW0IUqNIpV/1yDFav4CFzuUkuXuGhGN6rXa1zjFdfYDF81OYhg mMIUJj1pAs6YRgMsk6Ut5Vw5HhOPyiWIMjNlhyY0cYogfoCBpSsIH1GXOitIMJymg0EU0jUCoxaS AguKUzz0MYEMZOAa+XqJPHsDMKneUwdJIRV1mHIqhPTTq0P8ShscQda6ubJ73lMr3py40LhSl651 vWsgMqpdvXKXox3lK3gDJgoEIPaMKUXASlnqxniw12aLrKxlwZGOW6RBE5NoQRCRoEfThSt1hAIC GIRw2tQSkrUsHMFr04EOd+jmH994h3ByW5ybBIw5nPStRJQCpOH2sA/SC+JXreeVsRKUua58bv8T 2UpFh1rxumLaxCC0K+MZ+0JsNr6xje/xAJSisQEIcGxL29he91ouQZxLhy/QgAZNkAIJnVCgZx2Y B2+OtiFgCAM5o2DOLxi4kBlwbdTSEdllQlgBTC3kCiUVCt7e0whXyGGpTMXDhnU1dF8Nz/Ug0co4 uJLPZ62DLPnmRPVZERNVNHQs6rqJW9C40dodBKQjzRNaiELHAFJsAxoA5CALmZkLAmCR4cSOWyhZ yWo4BSdsGjockI6nRBMXh6wcVBiMwZyc6LIhMzACdsxxHZiLRyXRrJI0s6ie97wDGd6MNlMhZA9q +LCdQ6ydJKzSDq7s8/YaEQdZMpQOcJWiocH/jYlxjzsWiSYWdgOR3UfHONKQ9oW74z1pWijrAZhu AC2A/I19L/MeiXQmqC2nDU2sodRK3oEncHGKOmurBXDQQ2lKlxoJflOCWJh1rW+AhNXi2pAUkMdt 0sEOc+B6hSyU4SZrmOxlL4WHWXj2TVt1ZxEXkaxI3F5z0Ro+FUcCruQutKHrGohbBGIQt4B00dWt 9KK7OxDBgPQ9eaKse+M73yz9Rr/vsQ92QBaAlCUHOAJR8FJPYhJq8IT1TlFKbYGCDaT5LH8zBGvS AuEJQR0Cam/gBRB0XJ4UGMCKOl7JEYh3qneoalLiLKTraCEJ/zwSq+4M1mnvILk2N/GfEaHz/0aw 9dvfjkS4QU/uXS46o0R3ejCWrvrVH5vSZ6J6CXjiWKwvc+ucu/3tvQ4Nsk+i4Gxgg00nv/ZW5bQ0 e3z1aH2ABTcIYQh4JzCX+y59Q5r8wOI9tg7EkBQNb/g6pzkDV5BkTa3MXDtFZMO1t1e356K1EY3w 9hM5BnRy//yLtxAE/n0RCFtcNBjB2MQmrJ7qHZvYNMAZQUCmJeAdyF49YF09gNw3aAM4sAMFch2o tcMmkJ2SrcEksAESGAlYWQ/DeccCGV/cqcagXAFCNN/zEYEJRN/09V0/sFYoFF6bbd9VNQVCnIYW tAFXSQh4/JPk0ZzlXdvNbRv7zcr7eRstEf8auIne6L2YIHQU/u0f/9kCAArg0h3bIBRgAn5hDU3a vs2eAXVDBQJcOwyCwRlcI7BBGjwZ+aEd2sWcVbAa3GFIhjwEDyGE88GADLjgrcVgx80ga1GADXJS siVenO0QFuTBHmhBEexA8ImfEJafVxDCnqkfEnqP+3Wi+KzHE9VSJPyNuGGCuZ3MLWyUIGTU/hWW KdiC0sUb0gXC4XFSF3rKFzYAJ/GEKOjbN0ADNHSDGUIWOLRDkmHCGqKB76XBDphSCK7K+GXFDryd 6UwZ6gABFoiSU8yalpnAxglix52ZJWlAhRleIioeI+5gHvDBGXzFCL6N5OGZ3FjCcm2PIUT/Qd0g FCcu4SeGohNWkYvVGLwpnS24IizGGP4lpCAMAutJGk8kYPLsIo58QzAAYzB2gwTeXjvsHjImo5L9 3tl9BlegnVRAo1V0lgmGQTfhIRY0xAriXa2dABLwHTjimjiyUAyxGSdpHzoKFw/lQWnEwQ54mDPG Y/nJTRvU4/bQQRQgAp89Vz/KX3UBZF3ZQo0xpLptQkEW1kEmJBXiH1YGginEIqRN2rHtIi34X0UC I0biXjvUQyCMWzIW3Bq0YRpsFpKknXaU5FbYIdyFltDkoQ84RfPRWhScgBfAYE0aFW3J0wiQI44M Qk/QQlXxJFadymnsQcRJwVBCWyUa5UhO/1sfWJsmLuUmotUnMqETspgu7dJVBgIAilRhJZ0veJRt vsJCrp4sniUnqSUwLsM1ZGQBsYModOQGjp1CfWQaIAEdRkxYfcUOqMFovJ3xOeKUDQphwqQMIKZi dgAhLubw0NZNDs9jBkykLaBvKSJSOIFP7qBmRlwbfIVnClH4GWUqUZsflKZTxoE+olj49NwUnQ9d tNglrI9rigJDAuBWmkK7TeEXPCiE4mZYqttu8mYNYZQvQMMyAKNwes41LAO5GdwkGFxduiEQ7Qme 9YF06lS3RFweJMSgDCYWFOYYbKcXBKIh9YOO5pp49mgHNGZ4+ig6lSeCliUtcAG5oOPCZP8jUGaB TsFBO3rYiYJm9SwJPR4hn22bk0CX3oTPas7V+sBPyPTSJXQh0mllQdoCQjpoKITCJ3xCKHzBK+jf 0jWdhfamdkGDNOzpnRgQeC3DJhjnBh7nGvxeHzRnd4BVHegBxGFZ3MEagM3oENToduLArX0ni+io prJQj3aqp3qqPNWgeUqam1nmhmVVs72nFujUGEQpV1GptH1FJjLXtqXVrGyMihGaQ7mPlnRJMBSp uvHfKxadg34CMRwrMXyCnA5k0y2d/1koRvnfnkqDtUgDNIgCX1XDNWxCJJRaciqjQv1eJpxoz+xA xLnaEvhRaWEBDUyqDMhAEeDAxolnkNL/Vj98Kr7m63iySChAZpFC2jmupxM4wZI2YpOWBsTFASH0 QVRAI6xOntwQgh/kp/pt6XN16c7lCnX1aq9WAoNCWupZIf+pG5sSQzSAQjQQQyjMqSxOqLqZwrP2 ZrQGw7Rmw7RS2l9pxjWQmkcqIxqwAQ6QK8SgABykZGgJpsWxq7vCq7yCgL4+LdTSKzpRgL/+KxkM rPMQ7JKehkFEnJNKwVdExXY8LM1dKZbSysXuDfz1jRSFTJjaRSVUQnappf9lpdJNoZtGCCg8w5zO 2Cy2oisGLmHN7LTerCgA54M8QzUIgpKNKNm14e+dAqImahH8ZX9JkBAobY1KQbzOZNR+/26+hmrV dmEgDKwTLCKqNpvXIqwe8EF8MqzDUClJIlcdlFgSzcomqq1auIXHKIIZmIHvZkkvPUIloEIlZBTd +t/IEusrhILJegYo/AJIiQKNnZ5WBq4rBkNBzizNFi4w5uwziIM4PMMzMO4ajuga1AEbZMLkdgcS WC7yyShG0NoWcK68tgDo5m+n+p0GaNKNla7pni57pq46RtyqTiccvG4SRIXsmt9oYtv6OaUhGJTa HsIbHIKV/K4Z/A3gDO/7oMIm0Gnyau/T+QKbku8r2EIuSEIumAL1yhhWXi/2Bi5e0a21/uZfhcIz RAMPky/jLhShskEbCK22iMYdIh+Aff8IOclA/XYu/uovFA8p1fqvjR2BGASw6RaswR5s644FHIyB HQylfDrsUWLPrCKCEgXaLKlFW7zFBv/NfYyi++BHJcCCL9xCFo5wCXPUgy7DLuRCLqBCIOdCMIDU o2Xlgs5wYenxWiKuDvPwOIwD+S4DuIJr+qqvqoWOJ0QB/Mqdlc1oDPhh/a7A/f4oFH/uP+zrCEwx jlmx6VKH1l6HU5zG6naxF/vBwoZtKYVYWF3p9lzsrart+LjH745pr4pp3AaCIFzvFfaf/2UU9W7C HwNy8QayJKiChmoX0QGgIs+w/8GsWmaoIz+DyfJwNCguJXurQqlvM15T5boa0SjEh8D/hijbLxK0 gCnnayqfMlWoMivfmA5gMbMhxBO458GybuuWhRTk8l7K4TOKGFJC8LbVKnpoTBO18Rz8wRxwsDFT FCqYgiAALlfCIkaJTTD8sSSwMDWjQkqndCFrM2zKpiLvwi4sMgk/s0aNMzmbMzqbL7hCbkjamRp0 cmqAiBag1hbUQA2QsgjsQAfs86f2Mz8DqSGNwBf0b0fZ2CVgMR6w58LsgSOC9XtmAaPa8hjAgVm5 akPLIUnKzQ7YgX7OysVcdFvAxx/MxRu/D/tUwiPgn0wXVgBqlC+c9Aq3NCBbc0qzdC5k80DCZiJ3 82DRbY15l2boMDlfdjUYsiawQe9B/y4bzKfM9cFOnWCAKTEMQEEUJPVSrwAS7MAHVEVUwzbUQnUG VMWQagBWe5QocIEb9HYAY4EOet8ejDXCPukXM5cdWAJDr3VbixXF/rJcn8cwrwV8bLRczMUWZREs oEJfh3TgBqCD+kJhs3RLp3RhSwIqCLIkmMIhx3Q3B27RhXNOe1Rltyn5ojPybjZn/x4bINz0eEIc wC+IYNlRj4GWSYFSr8AUtPZr67NVPO2D13Yqo1MoTPFtckEZlIEbmO7z7GGzcW3E2XJZbA8r2YGr yudeWmkbYJsSTXDGlMUhRAmVVPd7yAWvjild2IJfB5MpgPcX/EIgrPBhl7c150LxEv85hoalDL93 djHdfHvUF2xGNbSpZoAUSN0Cf/M3zLkNWBVBo+6R1xb4gSf4gu+A0/aobMM2bXuqVKP5TdJLnFKA nNqmGWS4GzyBG2ixe4L1OJU1i8LB9vhBiUNCLqO43CCXI9wcGqcxQpkFe6QFG1vJdd81yFTC/YmU RQXCK/zCF5gCepc3eRN5qH/6LkADvCXoX3ezMr/bFN6mX4GXlFv5MiiDfgM1aEMeKLSB0XotDHyx lp1AEaz2FJzBDniAeKbygyM7vmJF6BpSnGpAhHaUGdhAGTwBnue5FjtiLTMqixpCoE/sxNoBoX8F uX9F9uSntydRi59HW8ABW2CwdV//t7zjRSVsgnfzuKZ/gSCcd3n3u7/3e0XW7cu+91gOwipmlKt/ F6xvhpUPgzIEQwdm+aFyuScUgaOOE68bOBEQQREEu4IPe7HTFrMze6deRcnvr9TGqZxCqJyaAXy8 QUEX9MKE9XBnwVjbMquqH7gLuh20ASScQaGTh+0i4ZO4u4zDe0ZPOnbT+yWAFHxvejD8u9RP/TVD g1oSpKoXHW62+is8qG2Gl5R/KEj5Xy38nvr2NxHnJSHwAZaVRouWhmESAed2/FJPAcgbe1ZIuMkf u2yjeT/vcz7DOQWofIS6PHzgebaDuNfiPFrr/M6XOCsROiEQwopD8KJHt1m4RVtQ/7d13zWlz8cl VGEwwWJH7UJLpzfVS70gC3IzWL3AiyVgB2As1iaUR7vCa2vOauuVK0MxFEPE/94ZvGNeqsEYUOfq xv3c073dgzz+5j1o6P3I7/3+xinhe70ZQMHhy/xwyzLX0jJZs+hYjEG6l+bOg3vPJ1f6qfsEYz6M v3t1Y7fnL71dmDDsmwIV4OZ4p/eop76/AwSqXM1oBTMYLFAgUwsTJhw0SNCrLxJDVQz1ZeKrV9eq XfNYrdqyZb5uKQvWrBYblWzUdAIF6l9MmTNngurUZswYPlmy6PHJc0wUKUOlFDGKo8YUpWd2tMiQ gWbUmFClVpXZ4WnWDB0sYvT6yv+MGShz3jzBguXNHrV58qzNw7OnTz584IyJcxdvXj97/cThu7dO HbyIDBGGcxgxnEOLF8/588fxY8l/HlW2vMmXQlO2BH0JJgk0KtCjSZc2fTqXtIIHEd65E+ghxIhf LI4gFi1mB1+Yl3kU+RvaMpMnba1k0ybJS6syQXnqYycnH5/TfY4hOtRoERw4ViidwtTpcvHj/2nN yrWiV9qv1qwR+6bs2T3y1e7J8pannrn7+RjKi/evAP8bDBHDEjuMscYim4xByy7xJZiFTInIlNMs vPA00SQJph5aPIwNREEikuiZEUbA7Z9oXsEkkkh4+00kX6CBZrhgitFkpTb6eAn/Jqua60OKnMaY Tjr9hDKqqOy048478KgibyoopzJvK9rS+wqN9t5LK62z2GoLriz4mwuO/vzTK0AB4xBsMEPcNOQw Ogo5RLEE57iTwTwrgcUgWxaKaBdJNMSQUAwH8hBRWh4ShVGNaCPmxJheseWRFlvEBMbfgplxxpNS UsmOPjzpUaqXOiEkyOj0k44P65R8dTsml2rqSSltpbLKrix6BY0s6YAC2DeymO9L/ODab9Wc3hww zQDZbLMwROiA441C6mQMzzwfQ4VbVFS5Q8JAlqmk20LNNS0XgXL5NlFaGBXFo2tCORG3TzZ55JJL LG3xFpCWmVE4aTjVRhppKLHD/w42dhiV1Jo86eQMKeIQUshWpUD41exilfU7Wm39uDwqO7DSovR6 9RVYKOqrL8z85pKrvwEBbBawvAo07GYEE1RQ28lQ2aUZVVS5JBBfmskF6XMvTLe0bpEWTSCC3GU0 Xg0ooPeVfLXW19JN/OUUGoHD1obgYNpoA4eFlavJJkLawKti/bawQ6k27GgD1o296zg8kKXEdeSS u+rihhvWoONXYLWoD8wwiWR1jDPvqqOvNP3iKw5ECHTzZml3tpNBbmGBZc9Kmgn6kk2C2QXpXVxn mjSkkdZFF6VBS1oS2CXZZep3fX9lGUq1xtdSNCLxpZpulFde4G4KJjsbSs5Wm/9HHp2bYgu4Kd6i jTPOqPtsO7Y7Su8mPfYbSsBpG0HwL1wonIjD4Uhci8WNhYvIMlt1c/K9Lm+2EQEUICIaQZjCII4O iliMIhRhmUeMDoIRjCDQSqEKW9hiF6Nz3S42wzpe6EJ2QPMgCFmHO3N1q1u+eIWIAuEn15nCF76o RWWGV6kWoaFfy1Me2aAHvVucjRAMs14fIhaH7E1MSNzznve8c7ZYkS9We3MS+tKnldysLz2hAIH7 XJAGNtyACNM6jBagUL/64W9V/IHDmQg4CTbUgQ2OcARgJjGJALYCj3VsBB4jwcBIxAKQgRRkLByI r1jYIl8Q3EUJeKGKXVQiF5X/2IVBTLHBDQrNFEErxbo4mMlNrQ5ozQiUaVDYrUqs4hS4WMUtMOjI SfpCGZegoSwrhYledQEaO9RGN3iojWxoAxzZkIbdgjhESNjhOnexy8XOQAhCLLGJZ9PYxnDQpClS cTxU+kfgRgACEFRkiy5ggxe/GEbEIWY/WkDWqvSzxswRMIBuZEMdJ+GIScxiFnaMRB3xOQk8/pOP fGyRIId3iVhgAkKXsOQuhFYJSFYChkZzpYRcp4pS8IIX69qMLVjT0VyURnbcEhQqKoGLTpyCE5rA ICQnqQxlEFJrZrjhyXLJy132MhvZAEcwpXeGTjyMiAjjy1DuwkxC9GEHz4Rm/91wAMXyfQc82CQP VZ5yxXl505vs80IayFlOIkRBjPobkxrXiIgWNYKecoyjIyhBiXvSk5+2wASLWrEvu/7RFoDM1y7y FYtNjGShl0SaKjZVQkduJmiZxOgmD2uKkzTDsQehRTPQRRrRVOIUD+MEKS5RiU3mwhYuJSQNIyHT SKwBDZO4hS572UNfkkINlpCt3RCGMKJuYW7e68Nuk7rE750NbU11qhqs2RSp/q2q3NRiVkGwVa6S E4xE+GpYx8of/ygCE3Bt63bbSgq35lOPdT2kLfY5i1bM4o+XmsUmLhiLvfI1FrUAbC4Cy1BVwLAZ nx1s0NbVDF58FpOnE3AzpP9hkGV8plCo+GkncEGKWFQid/QNhjKEty9bplYTq+0GNFrr2mzUQg3A pa1Qh3K3Zu4Wxb1lYhOFO9zituC4yN3m+rAKgm46l6vGIUIdpBuFKCRmP4eZi38QsYlbaEITk+Du kr8L10jMFZCROC+UY/HkWWAir7FQJF9t4YtlVJKhCxVal3OxSdaZWRUDORpjQ0ngghX4IL5Qhbkq seDNYgKSg+0T10obiV7VEcnK43AvweHLX2YjGLMFrh32QrczoBjSSHXmUpna4o0RdylRjbGtuGki T4NgFc/tqnF4HAcfRyEniTmTfxpxC0GQAslIZrJ34XpPfB6yyucdZCSufMH/DMJigxyFBihbt1CD 7LfM9F3XSYSmCgG/Gc4dPdclFtzgB8vOghQm3qVSW8c0UGIZG25toX1JtmZYAhIjNnGkI72DpCr1 e+ALLjVxgGmo7sADm+Y0bTrgaU+HOsejJrVgAoOXNxH5Lo3IcKwZTglNdNfhk0iyrWeR5fP+UZD4 bG9gu7w62Q3WlScZrH2B5mxRui4Y0O4oaypkLmo/rMGRyDN9TaFtPu/T25RIQ7htysOdllsb54ZE urt31CQkgd0oduakVzwFJ46Pmvb2Hr71/Td++9tEnEgDjgWuksB8/esym5zEj7yKVcA61tyFKz5v HYvzzmKQsZhFLfJqSfpy/9TjHw/hSTLa2JMH4w4cTLk0ThftC7Lmoy73BMxJgecQ7kIZM7SrxNOg CdhygrVk+/kvCZaJZh61D51IQic6kfTdLp3SwKV3rDA9dapXHUoYwbqJviDq5+LAOLn3OmACwxfB 7IWtGTa7II4ca1J4d7v3bK/b2Y5BQNpiFreoRX134Wu97/1onKRoZCML7QJjEO/B8EXiJSEHQmFi 8Sdt/MzpG3kbtgcN36YEbDPBieSNu9DSIJs0dkt6/5Pe9CSN6eLN6ZxoSS6t9ZhiB1AA9qDkImbv A2rP9rwox9jgABHGESyQ0WjmLxwhw2JI+mrB+JJP+fKqFSahFujOdZ7vFv9YyXVEib6qD4NgIRmw wQaT4fFY57BOjqMcSxmg7XSK4XRYY85AQw6OsDSO0PzkYBPSrw9IARY+6rN2gSQsZRJS69vUQA0y YQf64P7IDZjyL5eg4f/KMOkI4d3gjQCBSzvmbTu0MNPcjQEbcDweEOs+oAUmMA2igCUo0IlELHxq i9EEkRDZqgXFrwVFUNYiruIuaO5uYRY26JBuQYZe8OSqT5Rq0AZtcBqKDQZFyJEOwvsGTMCO7ULM LwlJIf0aTO8cSRlIoVK6LQ22MBO4cLd+oeduapdqahnK8P/O8N18K94Akd7aAA7vbQc+gA7r8Atm bwRawAui8bnYwMfYAAf/vAgQFw0Q0w1hjikRhs4Ohg4SSCGGvIwkUlAE6akRoS8FRWgX4qsFi+EF LdF1sMEa7hEfO5G+TkfNhGaSDKJgHmsIC+x0jKZ2bIcTVpEUcgEYsG2SauEPIgHJjo8W3a0PkuAU dkiHNrIXfREAz3AA11DEtmPetDAB3U0Zl3E5RuAVbMxEPsBEmksa0+Aa6yAKiAAH0CYbd1K2ehLd IKEnh64nScHsRiKGgiER0XEda0EIT64YasGlWIcfN2ga7PEepwEr9ZEUgwZoALIZDGLAok38KOs0 cmA0UDE0RIX0GgwYjMGhXKkKJY4ia7ELQ2/0cHEjl4fDOtIjQTIkRRJv/1ZPDZAgDpMgJVWyKljS JbEOCWYyx44ifHZy6M4GKH2ymbyHEHpSFmRLKImyHL1MOIIBHemuGEqzKUtTGpRBHqdhKnehKrEB GawhK7ehE0nREpvhB1nDFtzsIL5yU5rhIE0DCUcDE/wPpUihLcPMdXyBFNDA8ujPIi/y//AyL2fk FzzyIyFt6UJyb9jQqeqNMO8tORDTKkbgC0Cg37COExxzq7YjDXRyJ0OsDYTSJy1hO+9zMy3hDGSL FChxJDjlIFJQCE0zCIvBpQiPH+nrNe1xNrWSwERpwEzCN0VRLMUGGnIBLctPCUuDFH5Ks2qBGYBB oVzHFpZhFZ5zFehyt/9Gz/8WL3nyUhuW4WGwk93u07ea6G7G5wDf8CTHkzylYmTQ8wNg0iXXE8fa M1Z2Erjo0zI/7z6flBDyMxM8E2wKxjSlgUCboTRd6nSwUs3ycTZpkxfc7Nm+8gd980BPYlPAhiOa ARDQEi0FgqRe7mFQaheYQRdeaDNM1PIqsi5bdPE8oReS50WX5xmwMzuVDvVST8SMwg529Binzkd/ lCZG5gs6oAOG9CVrD8fckyZzUkmNsT5ly0mh9EnzEyhX4T85xUqLwUoLRktdShm2chquMiungTYH gmAK7yDCxqVoBFabAWxEAnhGKaQcKpIiqRI6NP1OIRNywRhyQUJsQb7/zo4WOaEuWTRQA3VQQeJF q2FG+7JG/1Le7EZjisCJTHJWdiAJKLUqMAJThxQmP0AmRe0avShJJbMy9dN77NNUnUk/AXZUiXJV wwZWAxJWDfRMs0HAavVWsXIbtoHAgo5XDWJGLLRgOCVTRkIVZg5ZQcOhHAoXApXBkJMZpHUFb2EZ jg8JVFQ6SW9bFw8UupVQHyb9fHFcybUAR0xJWA8OXW8O3ZUmLuIDMhUmR2BIQ8256o2r7jUn0XUb 1YA+S/Vft3NUh44cY0hW34xhUZPwUjNscqpLH3YacophzY3AWONfwEZjYQSWlOGRkDVkyYWkHEoT PFSzioEZTvaFumxl/0mh/izy6GA2ZhmGGJ4BcdMvXH8xZ9VwGBftUb8zUuVQaKPiAY1WXjtA6zr1 Gp22qZR0aqm2ajczM4MS3UhhGLT2QL3vzQqvYMS2Gci2bHNqVwumRti2bWPkKFlnbns3ZC/BpJp1 FY7BGKKVg6h1GTarZbnwFAaXcAuXYQoXZ0tPO7dTGHeWECWXuIC2cmnCPEcAc4d0ZLaO6yoQVLVx SetzPz/PX6G0mTJhVE9XVrcWbIGVa80WK2OXbM22djdlOHA3OERCGWLoXzrWdw/4FlQpsxjsFtoS GDoJeTerFuvvFP4vZq0Hem/WDCPNem8UEB81cne03raXKQyze2fCPP/RM3w7QCbLt6tC9Wx8En7X 95mqlhAmuD6xdn7nl1VZ93XNNhselna/1vvIJneNUka+TFkPeG4vYRUYrIJRyhYcGIJv4RckmAtx oYIBdVubY1SgV1w5eFGXSt1CmN5+toQP84SDNF4z9wNWwTGncSXONxv3lVQv04aXDn57Uj7H8QdT c4dX14dZF4gLWf+0gW1hBBrMUUaCYYmZ+C0T2ENLdheAwZKPFzN+YRW20CK3+HllFoNjFlHFWGcD MWNEGI3ZtWG6N3DaOHONdAJVgiZheD5HVXRNFX73tQ2kxxXa6o+9b4ff7AdlNWwMVhqEKWONGIA1 Nji01hYMGJJDdhP/tLhZOcEWGLIhF8IW/kqT6bILPRlvAzWUtxVRqff0xnjFAjGEp4lHv0cB2/WE ZwJeMxVpxXdzY3mc2kAlQtWO+TWPMyE/6xO4tusHzRbalGFGfpVGiPlivW+ZcXdjbSFkobkSKNqh LoETgpfxKtmSpXUzauGKObmTubiLo1eUw/ic0fm31PmUfRYZ8y2eZYJo6fklx9eF/TAw9NkRaMsY mVS2ZhgzoXSP43eXe3m7iqGQDdpCE1qQHfqhj1hTLPotFyJuK1oQcCH06jQTMOgYkgEHtdmKOcFP Q++TQ/klpBel+6CDUw9j1pmdJ3cBY1omvteVixYab1qWQUWfEQa4/6TWlp+pfQVWYGUhoNFtoNsq A5E6YsnWdnt4kDP2oTf2wBoKmquvJCIvBW0hEE6Bs0kvlWohFl6Q5i5oFbp5B2yRrMPZrL2YnDeY lB03mgQxY1xaUoM2puk6fOk1Gl04r42Cp7dRfQEbP2VBYEdVxLbLEQKoGGQXK5GZkHPqsZc6gEUi oaV6F0rzGLI7u4thGDjhFPqAs1NpFYrB11gHgn9BlbiwC1n0k7+4esAYZ197iSwhtjHmlJcklU1Y rmdMheV1SD/hprvubHY6G+N3P52JuKM0wQubM4HLqCnBnpQbK/GRwpPawpUa2oZ1bcOmqlkKu70a xLd7GHCBxEmcE/+Ysrz71hauuGX/lKTde5wVl0YVdYynABLAx77vm0fFc5XjWYvqut8ADp8r8D3b gMBFTBzVt5kSXLYYPCjFcZcRe57cyBZq1VbBFFcj9sKVWpkBWBpClr4+HBnGHBlAPBmOgbtLnBNu wTQxSE9tAZUm2MXDGZTfG75dO6XVsDvD577JJ7/3Wya8KV5fsmi/II4rcJxypA3qAGqBm1QtIaAB lriH2iehPMoh3J68rRGOwcop3NOzPGJD3ZCfh4fAphuCAVkNtBi6msxbvczPvBZSlBSY0jTJu283 4RfkvAstuIutpznGOa3Veq3LtbaQZLZH+N5sW667yZVNpAPuGp//83qtiqC2trEy7dhJnRzdOHPo uEuO6gCt3GgNIuEYPH0TbdDTQ13Uk1r/xIaXHum6h2HVzdzMu9qr0XwYAKnWa91PbOEWOGF5sZq9 L7h6moPONZhxq5c7lYIQHzVJkkRjWo9yAX2bQKBoMRdpAVwPA87rVkIQkVwo7Rigtd2OJ/PSIZwN 0Crl22MNYsHKzx3mrdLTKby536ymvvy6sdveQXzMz7zWlWEY0NwW9l3oTQETUpQusbpF8bbgWfvO Ez7P9Rx7MQbij31d1ViuQcHi29jT3njrRG3Hui6O2OBu7sba+zl+43cyvV0l6KkR1kAR/GwWXj7m z33maR66BaZg/1zHNO2957X777f0F5bhGHJe57MbkY6+FrG1/2CWzt/b6Uk2rdeaiUSstrADO3p2 O2ZlUgHdREAhPWt6c3FM9/L6t8t+SdE+7St9Mh8c5afcjtrjyYyn3Ose5u9eNrMyG1yVYIqhJOa9 zFs9GQ4fzUtT3ouf+N0L6V32xYXIztEaz590iW7c8qmeKKxeUin+KsA39JEWFPLw6+W49OPIyB3B 7FPfp1f/yYluyTLQjgRo3GcfE47B9nGf5rFyu10V6OW9GAAiGTJkyY4JHJhs1q1axRoeOzZMWUOH D48Vs7WJ06pMmXbs6NOnk8hOnkqWBIUSpSdQJlt6GgkTJEhCNP9rnjkDaUobnW3s+CwiJWjQIkSL 4sAx5eYOFP+aOn0KNarUqVSjghrRocOIrSM+fPjkJWyasWnYmDVb56xZO44c+bTTJi6kuZAs2b2L N6/duW1cUXJEKbAjNo0KF14TKRIaTIyPYXsMGZu1yZQrT7s8LVsxi8WUDYu4eeBAi8cQWqzFcOIt icV2VeSMi1MmNRwzyRzpcuVKlrlNwhwpU2ZNQjfPTDke9ydQoUOLFjl6/IzHD1WrW78eNavWrV69 rkojduzZsmrPOurpUy5dunrb020DOPDfwYQNr0GsGFPiSLkiP64MIGaZabZZZ6AZJNpoDBn02kQX tUYRZ7XERgr/bRx9BFNLvKnUW0m/ARdcHzYVxxd6djDHnHPPIZXUDkmAgl2MMkql3XZdfdABJ+CR RV555bXlVnJxtcHXendBQuReeyEZFyVt/KXWJPbtRyV/kQU4zWQCHkPgRJ4teFCCnG025jG72LJZ LsXMsmBDtSyzioUd3SZSb7x1+NKHnYQ4HIlMmoiiFHU0RxR0LTI1Y6KJdgCKjV51AJYXPPZYXlpn 1VEHXG8N2RN7dVkylyVE0vVXI6yciuqpiqyqyH2uVhkJLMlIRpmAtl72UEPKSKQMmAQlc1BBE1m0 q4PH5LJLLGvWcssty3BCCim1fdRHErjhiaeefI5403Ga+hSo/6CErhjdDtQpii522nF14wc6Tkop G5aqVYcfmvYkpHpGlhhXK6gAAzDAAwVMMCoGGwzLI1U+koxl29w6Ta4G+jKRrwQ9BKzEDdlyy7DJ IHsmas6uEq2F1IZ0LbYtkaTnnsFxixOTb9mxnFCYYiqFUSu0+GK6PldXI7tefQGvj/OyAWRb6Zlo x3ujPj2kI/8KLBozVl8tGsEFP6JIrA1naQ3EzXi5zDLK2IImapsJJCyZxPY60SzFJAMMyLag9sov 0VZ44ckfquxhy9vSVFzMTBPFHM6YGoXDztIh+nPkVq3LlVcgSMqjj2hpvtamnOL7J6dSa43M1Vc7 g7ozWGsNMP8qj8h6mZYCju1lr7bEgnYwvyyzdsYOFTMMMb6k5hDdu5xpyyy+PLO3Gib7/Vu2HuYZ 0+CE35RTcm8th+kWgt7M+M5ImCt5+VBRzp134GEuHuc+tsWGvXDFFeTnQwbWiCKwAMOMMcYAUzrT MSN1BGSG1gABDFTkIhkCykbEaOegYsQCd2jrwD+esZC5FWQWw6iFMn7xDLQ9JBYIMhPy3jSMNOxN Wh35CIai15uWAcdlMxkOcbA3pO3ZDFNxiMOgcraiFYivZ+Yr4rpCkT5QfCEs7IuX+5DWFkz55Dzn oV8Vk5a0RqDCGP07iNVQN0ACpo4ZyCDY/4ARsWM0Y40RnMj/Li4Ri13kYhX/iIYvKoEKZjVEFrhY hi8EcQtM2MI1B7EI2tDmi1tMQoUVct6FQJIElMmQZTIMUQ2vh5Mz5PAtO/zezYB4lJ2pYQctKKIp tZKVyuEoUk10382OJq86JG0+QJoi/OiDFkSgwmrACqAYf6m6BAEsGc04HhuL0QyJ7QIWl6iEHEzx iX/8AhVk4IIXOPELTuBiGHA65CAFAgxDBuNuzZqEJgLDt75Ra5LsFIklRSSiG54BVDIDF+JeyUNM saFQjWvRuUxpPqxoBQSf6E6O1tc+V+pTLbfEokNxqZbC1EER/Oul6YBZwKzV7Xi7oB3tOLqLSuQA FcsIRTRs/0EGNHDiFa8QRCViwaxbbGKQuwAWSDnWrFvMwpzycWTfgtNOwb3TJsShp4lq5smbESEO RLDUc4owRBgBNKBYGQEICNqdFoSHLGchwqVeGcv3DQZ+DIXozQxTh0YAwxnGEIgAMTrGrHXUmMgs phxV0cxc2CIU/xAEKrrACUG8IhCVqIRiujDTOCLrEmg7HtpukchJLBKdzrPET4EaVBANFZPGqeeJ bNZDHjL1Zvs8ClRH6YGpGhEEXLkqCHD0ge+00mgLTQtp6XU00pI1lobp7VrbGsDTwRWMZdwoSDma C1WYwhS78MU/QIEJFwRWEIGQBCoigQnEbgITpriEdy+x3P/GklMT5kwDJUqmBstmghA7IARmJ/lO 62Wys9r7bFBE28M4RIEI/E3LimowhVH+U7WSQ+JWXNuVDhBtLJjTXB2aetsI14EOPsStWRphKUz1 1rds5eJbhxtMgIEMZKpIrikGaYsv/GOJgR2EKax7CUygYbuM6S54TaEKVZxpE82qhWTHgk5KpLc2 7H0nDVEW30v2CXt/4mTi8EuEKOy3qWwwrfhKSeCAGhgEoWBtV8AyKR9BGFNRxucrJYpPDE+YDhpO a29dpVbVcXGMwlXdL8koYjnmIrnKxbEplvGLX6xiFYEwRSUkUYkYM2bRtvDuclVRiV2c2Be+IO+P zXveytr/hSM0SbKnlbzk9czMJ37YYQ+ljOopp+UoNRBfarNcvg4Y2Kpe7sq7mniDs9yAv7yOgpl9 WIfQvhIRwEYEIjD8ZmO7ag1xVl0YwSjcLxYQz3ve8yYEgeNdvIIYX7gEFypRilLAGLuL5q6jL9Fn U2yibJqwtGQn0dP0bprTnYbnp0Etz5jlBEkzS1x+exjlVHu1tEVo9SilCusCb/mqXNFq0W4AcTbw mg69hjAdfI0pROBT427uLR3osIaPi3zku4S2GC8q7S8aUMSq0IQgdByML3xCE80MN6IVXe7vojvH J97Etpfx7nezQT5O0rRlbViTeLrXvUpHeuGMOmr74jfV/6jmtVefKkQkYDnhkhvBwrnMFR21EuJr 4HXZiXAftN/n43GgA8fRiubCfPzYI6+7yA+xVrgKUOVXSyAqYoEJHaONE5xoZo5vXm7G6Byvy2Xs z4PeI6I3Sd52med6z4D0zPdpSXRJxKhLLQU/4Fe/VJcyr6uMg1ZPAQmQ4/rPlIhEBHt5iWNnw66X vXZXWT3kH2d23Bth9+AH/w/G0PveTVdGhJ0pxpywhSRKoQojJDoxOde5KQIRCMaughirCPok3hcY ThndEoXTPOHyzXmm2aHUg3rlv0tvev5WGaorOLjryxeKL2wlFF2+Kv9XsVW2B3E3gHsi5yogJ3Jw YIAgt/92Bgh8dKCACShyikAHinAIdHAIkvBsJ4c1wVU6yYcst7MKt/B8qoB41fddeBUIr4BIz7AK jeB9ZvF9ZuEIadAW9pMkn0J+8/R0SkJ+kCAFdBF14OJJ7wd/VSd/jbMCOKB19xdrX4BE/NdltLZE OyIeBFiAvNd7wseFDWh3cAAHhyCGGCiGhxCGWwRMZFQ1HwhArQMLt7AKnCAJqWCC00du+qFzjiYI 3WYLyzAMvmcYQSdWSTM/+rIeh3iIfuAHcxF1pSZ6N/NvpBcFYwB/vEYUBrcDCOeEPyOFnehlICB2 mYMGuJd7XCiBCRiBdPAGb4CKEFiGryiGczAHhzAH/7L/gcE0EGpYXAHzCtJ0CTkAadJ3CfuBh9+l AzfWArhwCbWgCfexYWiVVoNIiDMzJDIDCUtzjekxM4ooekVohFJGiaXHazeAA0SxAk24iV0HhZ3Y ZZ9gVbJ1hTcwige4hcIHhvc4chEIB6uogBZohrBYhrK4irJIi1v0bFazi7sIMLuAEiSYY8JYJXm4 XMvVAp+wCs0Ico0AiBvWZmB1Fn6ARUNIap9nL9z4iN8Tiad2hEjIXzdQcEuIBAOWjumiYOwohaz1 BZowFi7gAmmABvNIj16Yj/ioj3V3CANJi7I4i7SYlEr5BkqplH/AP3tXRqXTOtomTbBQCoaWaJdg BlQi/5E2RgWaMI8M+IzGBndqZmZraZKKWC+KuH6Y4pbBhk8pKYmoNgbhKHBEkGv0N0ozWT5fAIVe d5P8BwLwyJMQV5ZfiIr3CIZzAAUQCIZiGIar+JRzYJmZeZkCmZlOSQZT6Wymk0B79gWgcAtbaWje FZHWZ2OqSYrMFnKNgAh0IJvHBo1riZtsmV+QaJf5RXXhmJfBSXUtaY5M2HqAmS4jsI42yX85ySM/ +ZNa+HGR+XH3CAVm+JhPGYYC6QZPqZmruAd78J2WKZ7eaZ5vYIvRRjCn8AvoxpWqmRiKcAmPYH3f xTUVaIojZ2z7yXG5WZehJS+9GYmp5kOTqJcGGpx5yf+SLvkc9oecU5EBUjEOEzoOTqFgy+mJXrcK XUAW0LlswQcHUAAFUImZ4Omde9Cd5Gmi4fmdbuAG5TmelpmeIRYwp7AKlbBchTWMX6kIZpCHR/Bd XPAIAEmZjmmkqcif+2mXwRaJTCqcCZqgkwiO+gUHqUaJeQkHwhl/EFdwTAgCDyojNWJBTqGcUciO OEkFPakJLhCd9ShyIiqiJJqZMPoGLFqn4WmneDqnLxqjlimLf4AKAbSLuXAKtqAKd6CjXmkGPfoI 9PldQPoIf/AHj0CQ/xiG2HmkmaqpYBgFhpBfiHClYxAHYwCGlOiYpJql4cgHWgCOqQqlUTplEJd6 z8H/CZoIpunCnDc5ApzQBRzaBR4qndMJp1DZp3eKp8d6py6ap8dKp28gqX8wB5IarQITMLCwCqZw B+/plY3Krd+FCfMJqNelCAoTCfeBBoUhJb2VccYmmZsKhnwAB3wAr5uKpfQKr1Fwqq5Kqgq6pSdQ cEWgBl/6oBlAsD8ja2YqmOwoCByaBr9aliJqBnRgBsPKmeTJrMyqrBerp31KotH6rI2KCsBiU7cw CIRVCcxEqdzaqN8VCeD6B7AQC8SICZLVbvLRSJVFeXZRX0zaQ+8qrz8br0Drru/qrqh6j0jokjmD A5xgQbYaoc8FCk/7DwXbFFQLFU8rtVM7tQTLtV0b/zlet3+CiaFLhAZhAZT3YQYdW6LG+gR78ARv i6IY+6LNWgiY6pgYWIGsMq4qy62wAAu5YBCxIAiDUFgnC65zoLLDmBg+CrKo4LcJkzATlBg7dV6k YFl0oi3xBCrr17NBywdZALqhmwU/O6/3WLqaWq/hyJcQFxRM+AEZwCgpEbViSrsdALu1e7sEmxW3 i7u7m7XoYiPNmbBS+AW/SpZnK7Fyqplue6xtq7GrWAj3aAhouZb2obcqW1gHo0DHAFmEW7iNKqmR +ghm8JVVcmiSYF3a67jiG7ORAINCdrnWQhK7sTIuQwiioog9K6+iK7paoAU/679gCANaAAX0imoD CP8Uz7EDtcvADezAD1y7NMko/8AuwsuOq4AGvRqdaEu+FfsGb/udG5uZ0QsH0+tDiugWDqVhGrkq HhuuZADDMCwHM1wJq1CylSB9hRWp4Uu+5EolkiAH6CvE6Ku9lTCpjRoJ70YJHIEyJyG7KyMc1+gH +vu5/Au6/qsF94jFmQoDnLpfEHcCSosEIADBZWzGZTwjDcwVwju2VJDBG0y+aTuecGuxmlnAcHDC 9pIInccWJrmftLiKbhDDYjDDhWzIgCAJtxAIhIu+3xu+3No1xCgHgGDIhkwGchDDZVAGk0q+5fp9 QpZe7vU31GO/czHFhhCvVhy6BIzFIhrAcNDFjrn/pQm8tGdsy7cspomCErW7xvmXsL/cBWvgoXQw oh68im8LtxubxXh8wm6RCHvseY4wxXGACKgMni7qomQgBoRcyYWMvjmQA5KgCYv8Yui7Zzr8yOXb KpcACJTczZYMw5r8rErZe2tgFnFhF0lHJzWEE5w7BqsaunvAv63sygR8x0fbkjcgxmS8Fbjs0GiM HbIr0bHby2Jr0aHwCg47imlLrMeMzMxrmfPqqdy4jfkbB9YcyNjsBpocw2RQWEYgCUaQYzz3aKag yC52vkKcC5Www3NQJTg20zY3xIVFxPJcBjYgqXHcexnmFvNzE5rXz9OcyqGLBViwyv7rynB6x0ib /8BqoH/sAtZVJdYM3NAPvS5Z8RQoUbUTHbtZscva0SiEycZim3+vcLYcjZll4NHI+r/3SGxtOc2G gNIqLcguuskr62gTia13wNiDwNjZGggkW7ImCM46vQvcil2REAvgNQid7dmO/djZ+mg6zAV/QL5r EMfOqE9yqY2jMheJwAiMAAnPvH5TTKpVbMVYbNBQAAMwsNVfTMucUGthTdzFbdxcETTbQbvI3Siz 69bPDdc10ihiehX7N9cWbddxjNd5rdd16t3LzMyRiMp8EL1voNJlgM3y/AhHsAnY597BEAyhzdhA rQqlwAumMLguZgrilgNyUNmVsNNd6V2VEAgloP8KBr7Y8v3ZJRsIm3AEjNEF+mHPCWVb8hI/mWKS QzjNpOq/oivQWUDQWl3AsVooSDBrx43iKa7iYG27u/vWtDvdEGxVxGvR2I0GHdzBslgGT6Ci4F3C PssHdeoGYkAGq4jeTxm+l3AEy4V9oU3fpUACJMALVUDlqcADV84DpSAId9DZd3B44NzOlS0JqtDe 13cHPEDlaZ7mUU4CJeDmNM3Yi9zZgdAFmuAFq4AESJAJnBJL7ZdfoZe/WxAHG/7PAJ3bu63Vppe0 APvVXnbiKw7pkS5QZr3c/Be2NW7RXSCLOb6232268rqxK22Zh5AY9KnYE5ljUD7lqcDqrI7lrQ7/ 66yuClve5Y+NY+IGfTM9CNSlyO3s6zwACFgu7GpeBVGe64+9yIJFeJzgEetFCEzCBj2EFr2ZlwCs Bat8xYguorGqtJxgmP4nhdYN1uwo6ZJO6QycfwiL6WKr6cTa3d4Nnm6r0m2bmV3T3tj3aPVt37qQ A60Ozv8O8GKOvuEmbqpABZvQ5eHGCwvP8LwQbsqFEZoQDLrwzQEfzkJs8eDc6sX+8NcnWCy17Jww T6ICF14Q7YbwqoUOrwB97bod4ooOFEyIobnaiXJNmOUe6eeO7su57pmuvPGOotlMBtj8BofQNY+A Ce596wQf8N48xANP8FGf6w9PY1TwCvst9TOd/2OV0N6ClQu5HtRgT/AvbQRG0NKSAM5Qbuw8h327 LgiDBvekoAlsgJeoKq9A7vJ5v+1fHMaMTvN/H+4GFu44b9w6z8vD68s9/wVU8PPi6QZOMPTp/QeY wOD5TvBCXMlkIMQPD31gX9+VkOql0OCGR2mCYPqmEOBfH/XKFQhf4EfBgL7Sdwu789Kgr9hav/Vc UNqabATfZgSrn26dzQKmLwhpcFYQ6L/y+r/Kn/daEANYDQVTVo60Cvg0D3ZgO+6PTviTrvNl3QEg MLyC+QpfwFKY3gWXmZllgKIt7QaRQAX4HvpDHMNDnMOFWwk6YP+gf2gzjPYAISlQIFW8SklSFf/M 18JAplSpqpQrl6pdpoJdvGirkqRStny98mXq0iVUJSudvPSIy0iWR1y+PGJGphkuOk4+LPXQlKmB VLx4SaNpDRQtcLRk0TKGD5+iWpw+fQolShQiN4pIwYHkSyiuXb1+9ToCBAiuIMSOQJtW7Vq2bdV2 gBtXbly0c+W2/dAh1Kutob78fRX472BBc/68QVxGsZs3ZdyQ+YNpoMNSB+XIESOGDKqTJ0uW/INK cZk/ocmcliPp8mVJlTbtkqRLV6lKZYyosnin2U5TzZpdbPZwV6WSZCSl0lUwVarKkiSZrPRI+qNL ZiKhQRNUkyYvVKgE6tIFE6ZIMrmcf5ie56D/QSy6RIFjdE8Wo06h3IcaleqNE1KKaPULLAEFJIsr tQp0K0EF7WKwg7rgGsFBBdH6gi+/BqswMA2/wKSMxBYjYw5FItkkkE0ocw4zzYwwojPSSvtjtNPI kHFGG08jzjnOcEJlRkmMOMg52nJRbbXLTstpuVJS4YGHUXhYThLpLomkyiqx206TNNTIhBNOdtjB y1VWoWK88lSqSQcdeAuECi2Hsi+q++aUcz//1Niqr74G5NOrAhGcMNC0GnzQLkHVqhDDDDUUTBAu /rABRDIwuWWQhlSxTDMyWvTsxT/mMKxHxU5zzI1Rb9wsEpZ4c0i2FI2EFdbTnMshoVKaxHW5/+Uq obLKNbCbZJI0SCFFDS93yGSHPpLoo9lTOPFiu02OGIkLG1ZicxAq0KAjPihieGNOOrW4TwUiXLgK B04UxbDPPkcoyyy2QjmULUMhxFdCCesKFIQNB2OU0S5iLOM0LjQR5NJMyeisEjJMJc0w0kp1w9SK HUN1RlRW6eKWV5a5Y6ecCuIlEBYCkSSHWI1ssTkjuDBloUHuUK5JQHLoNZJf0RCWEjW4TLYPMJtV VuhMfs5kle6o2OQSxa69ZCeTqehiDTq0CFdcravCAat12W33L3cLjHcss+udsEF8I4QwwkPN3ksw wAIOTBAzyri2C0EsdUg1zSqxqbQXCx6Nsf83KkY8YzIyY3yTWwJZppmRDzqpMtwGMYUX2UqRDTlX KyuFU+o2UWiZZRJWxYgccjDiElBFVGSNRiahxGdLMiGEkGZ3F1oNS37/mZSlp6VJMS6OKHEQQaig 41sbtL6vKi+K+A9s6/ckMBS4tT9bXnjRXotBtukqdN+2xoKX+7j5mjvg5TFBOGGHjDjt5Urod+PT GElVrDFJT2NcAAWIilsshBepuMRGnPOjkdwkPQ8c2QNN4RFBNE0ywajGKwThi2Ws4hFkyEElCOYh UCmCDmtgAxt85jvc5a4PhDhaG25nCTWQ4k1o6MK0rKWYS5RIECxAgxlsMEQzzEkFLkACDqr/dz0m gsVsT4Si9g4EvkGprQMfYJvbruiWs32FLIyamyAEoUExlrEhtSnDSu73MMUIDnGFe8ziBDhHAT4C ciWoTAIXiJtg8OYS6WnYA3XCKlMcoQvsMd1CNPgI1UHEDU54o4feACo40AERKaREG2T4O00Cr3aa YEMjiNAI7KjqEpG61iZYsLwg2kAm5kKiErXCRLA5kSxQxGX3qBi+e5GvbRPKJdxeIQq5kXFvZeQb /WB2CfrRqGDOLNyN6DjNAFbCI76YmUUUWIld2MI3wVFFLkAnSJw8xBa2UMVIrnNIDnJwE5HIAXMq IQYn1BNx90QMqOiwz0bUIYV1cEQb7ECJ/xTegA11WMOvinhCTJjHlUegwvJksgYipMELsqSl9QgU zFymBX27tGL5PoBFBXF0LHEbI1+MKcaG6OASLrkEF0RzKjbGcUbUxCnj5ECbTYyxGsvwBc1U8Yg/ VEIV30QqOCnSmUecxBRArcROMPGrDfriFo84jjzl6AR61tOepXoCYsQKhfhUEhH9RERC4xCHKKzB DM27j0xcIkQzdIEKR1jDDVyQBqvMMqMa7QouuWfSs63Fewsi1FxGkBdgEhaljEKmS0wU0/MY4Zk0 QlVOA9iEJkyTDKA7ySY8Ag1abMIMRH3EUZP6kOhcwhaX+IN0QrOTSnzhF15Awxr0FowE6v+KNmTg ambqeZqKQfKeFXvDE/Yg1qyRtayVFNfr5DrX8LjABTcgAhGowL6/sqsFffkTYTl6oMMeinz8ygtJ z2cW8YLgu2SE7EAGcQQdnIcLo6GpjTS7X81g6oCVOcIYv8AJjhG1M7tIT0z/EDVMsCSmRuiNKn5B jFVgBzu3UM7I5hnA4cbxuMW1pxueEFb/kTifUJgDiqU7E5dg5wgqQLEO7hAI7nZ3Ky24kPYC2170 fXSKu3TLLw0rFh67NzCiSKkGldc0yp4Hvxnjr2bJ8JA7lKAZJdiQl5DghUiEBjREhRF1GkxZFkXt qcR4hSa6oAnsZK4UNDPFHzQF3OGexqv/dzbuhy0m4hFLcpKvm8NMWFxErpaiBCEbRHe/+4XvLvoL Rcbl+eplPn2Zr148fgVPAqG8lLIUpk2OVH71G2VqwuwOtLhDyA4tiDGhgaif6dGNYK0xo+7GF2he hQ01oSr1XEJxM7qznikGMfw+bYg2AHSgA11ZMXA2ByWAdglMIYjrtaDR17Z2C8by6FtCmi3lNW++ LC0oHn9BFbU6SCkCsTdOf+clTd5hsRWXGQACcI5ynFHUUs2ekJlCJZe10WXLIJrPGDUhwdhFKQRB DBNFSxMN5s0RAK44PUey2IqZA7IzPkRQ2eANMYjBEMsgB0AEobNymHK0pU1tsDma0dl+/7l7rT1Y HhPZx+BzkLgN1Vj29hwEn/jEz33BixyUwhSlWB1uNj0QE8GkWucJ9ZN/Lc05oypqm070XpZHks+c CuCciQhuPPLThwgiGg1hNZNFcglNfHDqD7vnxS+ucbqHesR9LlizOXuFzJRBByovQSBcrihrvzzb h7c2pJ9I5G8LyorjFvKEgP6JEQT9DqkAhLoFgamU5YRV72aJfc8zQlG/XXGEPELWvyAIktDIy8WR RAI9rxBoSEMa0AgGbl5BDF+s8hY7GckR1u32X8ed2BeHlA0ghd+7jxgLXmUcZ+VgBSs44QiGVrkp BjN4xP8F8drWtszD314gjy+kvARyKP9KgHnNC8IURkiNylJzEjXVV/T3J32NTC9rizhEJIWMqOU5 goYxqglSiJ0IBmioPWjQBmlQhmAwusDYhBOJGpbYBKDyNcXBr4uRu6f5FEBLrrvDghHEAjfYLEAA BDGwgit4AiNIBcBTBU74vu37PsQzm8QTL5srLLR5vHErv8Uytyp4ElXYmzMqEs6Svk15mfuzrz94 FLnbPxuBsNyDiB5iKQp8uqhaCKDyhWJoBgW8PWhQhoUgJFaBCFUIBF8IBocJuA5cjNEojUATNFBB DOcjwRLkqiu4giYwub0DAprIgVEAPB2QwcPzvpczvO8bi/FTvJsLN/HxwR8cgSAchVH/SAVTOJkT 4YIikQMkREKUqx8WuS831D/Tq4RgECqIiCpO2xtCMrOK4I1msIU+4g1BSrVA6CPQmSCREBWC4Z+H 4Z8yAJWZAMFJuo832AMSxAM9dIIRvAIr4CzGKYM12MRRAASVKwUdeIUaTMQazLZG9DFwCxRIjERJ DIWjq8RRkARNIzMyWA3p80R6Q5XSi8LTiBpbcAhyUoVZbIZd2AWlSo9S4IWBBJ1SmAj1GISLUEPJ yQkEe4hY+4MbATj8GqFAowMiqIM6aJ5kxAM8eD7DcUY91EMswJsj4AIxGIUguMZoMwIdYLRu9EZF vEFvazzH27lyRKxCYYs7WBJAGAVh/0gFHQgEl9ABmurET8yMaKzHKDy4fLwcbMLFYGiGYziGZEiG XcAI4EiqZnBAfKyI4LCc9BAnitiFWJu3ORPGEyICNkgoOkiu57OnSYKDNxjBjrTLkSwDmbABJwCE RXiBlSyBH9E+mIzJGlQ8xjsLnCMUHjQ/8/ulQeAcn1yERUgFI4CpHSIVAIrG6ENCejNKMTgSdwTF lWGY/hMn5wgGLlwIhJMIXciFWeyjb1It4egmf7SIYIhKhAuniTgJTrwMASIuxngdx6gn4WKMSlqr uaxLj1TGEbSBmCgDvvRLJXi2EsgB5xA8wizMb2xESXTMHqw0nYOLvLALknoFVdCFVP8YhclcBECQ hDSiCSejOgHirD7sLMjYHxtZGVhBiAjTCYVYTVNIOIE0CIMUp4FEUIOQiNm0CASzzXzMBaPKhd8M oJtiHOJinIqZAzrwJzuwgzqAgz1wgitoRhF9Aqd4Ao98g2N7gitYzxeYgSYwAhK4zspgn+0sTHAU x0kDzx4tT0MJBZ5cjvWcTHV0PfuqETq6mMfQu82s0MURzVhBiKPyvEEwHaDKvWbQHF1ZDtlITy6V jVxohoX8DVvIhW66CIfwR9hYDeCUo76bg4RKA0s4A0toAzaYSxEdURJ9pCdwgieYCi2IgSeAAiFy AjAQg8mEUSUQg9W5Tkk4AkfDUW//PEzv9NFLfbwREAX0XA4nIVL3JJxjQ4NIsVABMpVJOpykZAJP ZFVWTQ2KaIaJsAigMp1bSMBm0AUU1NVdRUHP4QUx5SDcw00DDAZb2IWJkAjViEd6C7SEagRHsNM7 dcvDGVE8q6e7g4IiiAJxGVQswIMgWIQgmIEZ+IEmkIMarQwZ9L5Jlcki887ywdR4Hc8R0ACeTM/0 lMzJBATLIpVjG8Vn8ixoGpUmbQImMNggQFiTc81c0JwwnUVbxcdgyAXM69XlAIRUMIaM9VUxxQjf SI9uwhTLGQ7GgaRPOaGESqg5SNWu8qpHCrE/jQFygQL/yC78wAIhSNRRuIIeKNdz/0XXUmCBRWPX w3NXtKA8S/1Oeb1UxroGe90cimVPUCUcvZS3nJoRgMuMoyzYIJADcfJSXZAEZKWIXPjaMJWIgbzX rzXI2HCV1iDAiRAtWCAN/3GMaVyDuo3Oeho2ECNUuIKCi4yCOsABHIgCGMgCIWiC9ZSDIeDZJlid glQ3DGFXwgK6sZi8QBkptsCitlHazlUbTcUjzqmMVLjOfB2FHFAMooJDqXvTCnXTzJIDVHiIifA8 /yrbBSoS39zP1XCOpoqqY/W8nXiEOYIkiZmDvTWu/vnbfcqu7GKDIsCBM2iDMXiCvgxXMPABhF0d jijIoJVcw4Siyv25yRsp8h2p8/9F3/RF3/EhT89130wVhdAtSLA9CCJVR16JTyiUEZyyNxuJKosA SFvAxYY4VnESSAM1YM7RhQKdiG7Cx514iNRUQ52IWFu4keSlw9HYUDpQ2Q0lgn2KghugqITKih1Q AzYwgr4chSYIgyG4gpvZ3oJUhW2kwcT7BBTA4RzG4ZFCAfX14R9OX1CQi/YVYisq4vft3BG4Bvmd 3+aQzFHgBZ5ggV3LT4EdtTnD4gtFhdvUjVQLBuX5mNyrhCD5HOe4XYOUxYUgwwiWyqPCiEB4rRu5 GGXzn3DZp7xCWeZlAxxQAyRIgk7AhU2QBJ9sgicYgyFwgnMlgXQryDt4NMMDAR3/BmL1BYUgDmJQ wORM1uRN5uRO3mQk9twRoIASqALIBR2DUA2ftEQ09AVBeLi7uVp6fLv/5Y07+OJWnmAiAdu2XSC1 bcjUBImjGxlWuQg4hq0Y4UBhlEMzeB1XeqsPPqEbGFw1ABNO2DyVIQMoqIEtmIOU0YVFhtzZEIVt 07YbBmJPRud0Vmd1/odONuJogAtM7sFo+GRNhucGCQVaqIICnd8Fbo5UBoTZMAXlWYWHIyoNzJhn KokW0Qn2cGiaSWB+hlyOeKDVIkg2CYRbuAVmMoKSIJwnVLaJmgm3KtS1/Bk18IIjODfStQEiKAI2 iATV2RxGVmASGISTstxLXued/87kdv4Hn25nTP7pnwaFod7koUZqpJ6Ldu4ATIZneC7iTG7qqRZi nj5iu9AAUmaOU94cguQFWnHUokND5fGChsq7qsMsMUijgVNFI1ggXjGzMhRmzlkgR12gBd1NXSSk SniUorINy3LC+/pAZn6d5V2DSMAElQ4SIzADIlCDVXA/ziEBcDbjXX7BROu2T0Bfqw5qoTbqpAbt 0Bbt0Q5tuejpztZkoEZtq5ZqeVasrA4BHpgNBZ6Nhk3Qf14d5MANVjlmX6w6sAM7FmkRt46q/z0n 3vhnt/6RlJk/4gA7+usM0Qvs0SMYgoGCrDGMP3AOTNnevCSChBqJyphp8d7lL/8tgXHGac0eKc4m 7fZ27/eG7/gebauOZ9OGCw1ogNhGDoGcjQX+2gRF5ZTRVSYh8F8dDlRIiUeAte0epFqsjAQuSAd6 oJsIO0Digvvh65FoKuBDo7rdjFROR2uUA8LJSy5w6y/db9Dxby9NBV44b5w2i/Pdafmm8Rq38Rs3 avqe6qkOhfgNAWqQ7VNGW9kAcILknNXR1RAfhYwdb4nA6912yjHmXtAxYO7FjZww5cqonJtwSOHY CHwNcYRVysuIJy7t0rJd8c5xccxmPBlnZ9XG8TiX8zkv6qTe6bkQYgrIb2oA8q2uDNtuWBbXla+1 2CS3Rl4d8LLVHC7ogiMYZET/11XnyBFUIDn3zAmv7ZyvBehdXY2LNfNPH3QiF3QSKAFaeLQ2b2r2 rvM5Z/VWp/NVV2f71gB95nMgn20CXeCG9RxQB1MUh/RdFQhJwASmyYFfR8HYxV2fvQxduAxEp9iK 5fVoD3VCTwVSFwVuS4v15mzPdvVu9/Ybr3OeNhQF2HNh6PMu5erOkfYzV3dQd82Zvld3L280d/d1 t/cuHXQEJXVaeAV6yfa84GmiXvVvJ/iCr/GBX+1YHwF/oAVagLYfFwZheJIU5++yvfeLx3gzT9uM Z3czrwJSPzVi2orFGs9UZ22EN/iUV/mDR22B9+TO7gAKUIASgPiIl3goIXIC/w10NBd0juf4TAd6 nkfxVPh4aLsDYjKQ7zz50175pnf60OZ29x74ohZqe65zB9EAUcjvmrf5SoQSz/nzBBX6sSf7sqd3 XWkSoq8Co+d3f29f0176o4bzp6f7uo9vlE/41P4HuKAAf9B6UuZ6m4/4dMxYY5h2sxf6T8eVxeeB Klj7Q6MFUdAADaCXkof7uOfkubf7zef8b2f6oYYQCsh6WmgAwP/xWhf81E99ajD3Wnd9HgiB2H98 yI/8a9AACqh8kzd5zF9nge/83wf+4Cdq8qGA4p/840f+4i/+8In6HNfk3T95pP5838d74bf+68d+ cIf1lyfqvG/+7Af/8Bf/zlOX+/E3//NH//RX//Vn//Z3//eH//iX//mn//q3//vH//zX//3nf4D4 J3AgwYIGDyJMqHAhw4YOH0KMKHEixYoWL2LMqHEjx44eP4IMKXIkSYEBAQA7 --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651 Content-Type: application/octet-stream; charset=iso-8859-1; file=xy (317).jpg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=xy (317).jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAARgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABAMDAwMDBAMDBAYEAwQGBwUEBAUHCAYGBwYGCAoICQkJCQgKCgwMDAwMCgwMDQ0MDBERERER FBQUFBQUFBQUFAEEBQUIBwgPCgoPFA4ODhQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQU/8AAEQgAtAB6AwERAAIRAQMRAf/EAKIAAAEFAQEBAAAAAAAAAAAA AAUCAwQGBwEACAEAAwEBAQEAAAAAAAAAAAAAAAECAwQFBhAAAgEDAwIFAgMEBwcCBwAAAQIDEQQF ACESMQZBUSITB2EUcYGRocEyCPCxQlKCIxXR8WJywjMk4ZKiY3NEVCUWEQACAgEDAwIFAwQDAAAA AAAAARECAyExBEFREiITYXGhFAXwkTKB0fFCseEj/9oADAMBAAIRAxEAPwD6zeNiRTp116pkeCmo GgY4FoOupA8B400wEOKV8K6BDVOmmB7mkYMkjBI1FXZjxAA6kk9NS4Wo0Ph0CgjcUqGHkdAjlQ3X 8jpiG6UOmMSR5aAElab/AK6SGdYCla6AGWANdICLKtK020wGPV5jr+3y0gLN6Su+rJGCQG0hnOW/ 00gFhhSnloCRuTQAzXfroABXWQE1/e4u8WzurO3hM8+IY87m6tio2KchQFgVPpIYawc2bq4g6KxV KymQxHMgRIQntpTjCnEgFBsONeoHTWtdFBjbVyOBjVvMbEHw1RB4OSa9aaYHjTy0AJqTQ9DoGJZi On6aQDLNUddACHINfH8dADWkMOkgnVkjbdTTSA6v4V0AcJodxoAQ5rTw8vw0AQru7a3lhjERk95h Gj14r7jGiqSQQCfrTUttF1qmD8nhre5lnuuMhuoo0NYH9uRzE5ZVDDfxI600NDVoCsuXsmskuPs4 pxalQHWP3BGTsOaqQUIHUt01NnAVqArTu/DdwSvkLGMLatcNZ2+Vt4ytpNMjcCqOpIccvRyI4ltg dCcB4sNxXMcqGQGnGoangV2OrM3oB8Tm58tbTST2ctrLZ5BrSVXFFoQwj4mnqDKC3XYjSTncqygM 8qECvXVEjTtXSGNMabHpoAQWoK9dAz2/loAOE/rtqiRsmp+mgDoIrtuRtvpAeJ9P16aAGz+GgAJd 5S1kVg3oljIMAaRY1ccwG3LAbqDTrrOzNa1klw3MEk8ixTR3ClAwkidZEIqVNCviCKH66pNMhqNx UF6uVhylhlra1vecgiuEmto6tFxBTkRvICN6vXSVVuU7HBbRx2n2NnHHawInCCOKNVjiA/h4xgBa L5U1ZkNuGjRnnlM0kjpUgBVG4GyjoK/XQhyctQIkmjSoWSX3XQH0lqbNTpUCo0JBI/y236+GgQhn 323GgYhjUaBjYNTv+ugR3kPP66BhpyQdMRzkNIBDHb+vQB7kCOu1NMCHlbgQY+5k5cCsbAOfAtsD +p1NtEOurA8EUcQiALFbErsu7EKtGUqetV8fwPnqVoi92NvPZ28l0cEFupo2a6nsoQqsEdkEtCop UFuaqTuTttpVa6DtV9QittdS3Ud3j+LXPHgYJCYxNH1pUjZx1Wv4apkLsx8XqCQw3MclrcDb27he NT9G3U/rpyRAm7IELcgT6l4gbksCCP6tVIhqNlDyVZldWVBGw2K0NWB+hp+uhDH6kj8dMGIYeOkw EMTT+vQA2DQmu/8At0DOcz5eNdTDAPSb9OuqENbjroGcO5oemgRwddICHloTcY+5hVeZeM+g+NN6 fnTU3XpZdHFkCBPK1JFDtbCPmt+ig+0tf4ZVJ6jr/Q6a1Uj2cDUmMeKe4yWIRUvpozzI9EFwVX0s 9OQBH94g0+g1lZuuxovVo+hHw973Jl44hcmCzylm3tXVpKrFCr7RvI1QU/5kLKK0odjp47NrUWSq T02DsUhyFyMVlHjjmaL3XeNjOeHIoAhKiqEitevlrQyO3Ty4ud7G6jd40iBhlETMjoDufdJpyA2p 10CZDuLq5SGqDleSqWt0cEhjGrGlfDpSuqEiXZ3UV9ZwXkBrDOiuoOxFeoI8CDsdNCY6WHRvDSYx tzXYft0wGGr08NADe/nogZZaAb+OkIbcDqDUDz0DGd+vloEJXroYjsh2FRoGV6KG1srlrP35IrpU Le6w5xSxSEge6DtUEFSPHWK0cG+6mAqlnyt0Mc1rDU0KpKYI2U7GgdeFD9NUKRF1aJb2qLzO3GN3 hZZOcakE1ZKjhxJr+zVLuRIB7v8A9Ws5MZ3F28IWvbKf7e/tpSV+5sLkooWJlqRLE4Dxg7NUgkVr ogSjZkW+x3ybYwY2wN3js7dyyO95dyqYYbSJ2JFOBJd1/srx38SNQlafgaN08fiGpRk8LCk1vDLm 7dVVbu0DJHcjiDWW3DUQtU1aJiOXga9ddjJQxWMu7HJXHsYe4UXTyATY+4V7eUNIRU8HAZG8SOPE +elI2ifdQzWs7QTKVlUkEHb89OSIGW5U8zpgNmh+p89A0J4/7dIZZeI/PQIbdqKRTfQBGLVOgBIH l+WgB1440iV7mVYw38CL65D+Q6aAGJY7D7We692RJIEJRkVXkbYkrx2PUUAod9Z2rJorQU7D5bvG /mhtsj2U9tipuTSXU72kkkSIC3KSNWIHTejmnlqat9S3HcseUxNpkLb7DHuLdbqFIXeEKrKvMuyr xoA5B4V8BrRoyVoZHxrR5y/+9iIfE41ylrIvqjnuVBVnU9GWOtFYbFq06aYnog4/9DpkCG8yNMCP OLjnDNbTGGWFuaEDc0FKA9R510mhojq+RlMs+VuBc3cr15LyAWMbKtWJJoOp20qqCmxRXw1ZJ0oo 389IaEUX+g0gDgbfTAZlNTpAMEAGo/TQBAmuHmupLMKDaiJvfIdkk5NSnEr0AB3Nep0tZGog5eG5 tHtMdjSkc9wnOaYqCsECAHii7er1KoHTxPTepER7qDKpCRYTRvfP7lZ7hKqDQGMlFIB9QKvSmxqN xuhyiDBnLW6VbDP289hkV4+7ZymQ25l84ZQFSVan0kHl9BogNUQrvI4nHyCbB4//AFPPoSlvZWco e6Huf9xmq/GNCBV+RBI0noNSyydr5jHZnHM+MtTZW1lI1l9sE9qNGgVaiMUA4iu1OnTTJYWYDpoE NlTv+mmIbZTT6D8tAiOwPhoKG3Jr9a6YhFfM76QHaD6aQwu5II8tMYgsPHQA2Wrt56BEVAqO8YHJ pOR5nb+Jq0B+ldINxq8kNiySylaeTGjMg/j4jxKgcqeQ0NwhpSTEKsqsrBlbdWU1BHmCOumI6W9t STUqu5AFa036aBFB7azXLve/x9mtvJ3DdLJJcWaXJt4FtLZQizTqPU8m9KKg4g/npPQ0exW+9O8+ 4+x+647bHgHHxRtdWeJVybTLlwXuEjd/VFdbMyIfS3HbetZu41KrVM1nAZzG9zYSw7hw863GMyUK XFtKvirjofJlNVYeBGmZPQIKTWtN9VAhMm4Nep0ARHYL06+GgBhjoAQCSaeA0Ad0AG5QAOu/66RR FbRIHgoPTemgllO7gzuEbL2GNtO4ILbOLOoWGBhctG0gKf8AkwoTSJhUNzK02ZTUazd6zCZtWjiW hWSzeB7gDwTx3UYxbGaDK2jwGFZVDRFoTLIjnZm9JjYFT46xeajcSX7bqpMsyndfcuDs7jJfGWat 8hgRIq5K3vLR5pLGlS80ELSxKwcAmgk4bHYHqN2S9LkPS9yFJ3F8xXbhn7gvkRtgLKzxVqp+oLR3 ZpTp6jrBWzP/AAN+2v8AIlb75KxGYTJxzT52SPeL7+eKKikjkpa3tbdxWm/Fqauqy9Re5RbGr5LC WfzR8dzpeYsY7u+zQTXOL93kVmiowlt5VCniSBRgAyN+R10eT6majofL0uQ+T+0obbtzszK5GyvL 64upILSCUW8U1xEeU7xrNbTQl5BSV4+SkNyoKawvW/8Aq9DVePUCn5Y/nG7dnb3YLzIWyn0rdY+1 uQR9WgjQn9mp/wDRdWL0fAsOK/nN+R8E0cXyD2RFLENppbaO5x0wHiQs6vGfyYaSz5FuV7VHt+v1 8zcvjn+Y/wCL/kt0ssdftjM2wBGLyQEMpJ8I2qVen/Cda15VZi3p/wCCLYHutTVfQ45qaqwqpBqC POuuzc5znpB6dPDTA9Vf6DQAVc+epKBGYytph7b7q5qzOeEUKfxu3Wgr+06xyZVjUsqtXZwj5f8A kzL/ADl8k5S97Y7YvIe3u2EcwyXFrIwkaMbH3JgAQT/dSp/DXm0eXkWl6V+n/Z3WePDVR/Lv/bsD +z/5esF2vE8ubyk13eXRBuPYJgWQipozkmRhU+La7q8SuknHbkWexqmNxuCxVv8Aa42FY4gACgJa vhvU763rix12Rg7XtuQLi8e6jNlDE9qeUizJ7TRx+2GMaq0jD22DghqLv+esqXvazTSSOi2Otapy 2yF3F3ri+w7C1kzsphhYexZ20KGWeUQqFNKkAeG7HXQc3jJUpv5hcEy0hwd3IPBpJYkNPOi8tEop UYT7b+frf71bjF428tL6Dky3CyJMienrJxFQn96o6altRqWsb7ltkv8AN5LM4yC4s7dLqd1kuoY5 KzS3koJSe3hV2EcTsTyBA/dpDaNPte14DaPNdi5EkX+SSoFJLitCUChqRg+nkfqdbVrJdsKqlL1/ X1KpfWtjdIlpe2AlFwnLhNSReAJDMyuoNCfSu2+56DdWSmBZMSxpa6mYdyfEPa9lfw94dr2kWL7g sXEipGqi3mHIclZGqFNK+taU1xcjHV0chiyW8oNR+Me8sP3PDf22CyUWUs8fM1vLNAxZI546ckDE UIoagjby1hw7v+LLzVW5oI6/Xy16ZzHqaACjDf6eekWYX/Mn3L3Z2bhsb3V2vjkyqWEn/wCysXSR ybZq8nX2zVeJ41ahoPDXmctTZTsb4tnBnfYX8xvxl3JaxW1/ejt3KNUvbZH/AC4ubGp4zge2RXoW 4n6a3w5lVKrMsmNtyjUXzmHmtUurS4iyULtRGsnS42IJr/lk7ba7VZM5/FnUlx81qt+jx/ZuPRMS FXrQ7mnSmnoLVHhbYzKYy9sEeK5tfZkM1vHIvMrO6qxFCTsTy28tZrHVNvuaedmo7EW3wdrlMHZW Wftor8pCiyrcosnJlUDl6gdz56omYZHj+MOwlPNe3rPl5GPb9K00Qg82T7vt/D4/GTY3EYWOS6vR 9taY+ygT3Z5ZfSqgAAHzJbYDc7anRIalsqWG7ZxPbmdF1b3kUEUKe3kGM0aRr7CNGebenerCh020 uoep6QKzPyJ8T2DmC8z1tdXK/wD22Pkmv5q+QW19w11jbkUXU2rjyPoVvMfMWYhtXi7G+P8AN3qG iplMtBLjrLpsQZQZHFPDbXLk51Vsb04trbmGZ7MfK3yfnbPtbuXOR4rG300VvJZY+OQRxrOwHJ4Y gZpQoPq9whf+Iawtk815PUtU8G0fa/xB8cdu/HeA/wBB7e5G3tGIuZpSDcT3UiqXmlpsCQFCr0A1 0cRNzZnPlfQ0NF86g/XXomAv2z5/79Aye311JRW+78b/AKljo+FzJaywTI4eIKxKlgGQ8gdmGx1j lwrIoZVb+Op8Q/I/wln73PXN72tdWFhOXdriyeIwLIWNeVVDxtX6oNeLdvG/G6O2tlaLJlLzHwPn MPgsbl7CS7m7hkdlytlZRLKkda0eJoGjbjsNt+ulTM246dDSyq9TV/j74IzGetMW+e74zFpgyS+S wKTOlwKH0rF91zRDXqWQ6tciycdBOtN41NtsfhjsbtySe4xHcHedvNPGIpmjyGKDui7hS7WVaD8d WuRZbN/Qh1q90vqOvjcLYKIDku7ZgmwkOQwwc/ifs9JZ7d39Adadl9TkFtjLmQxo/dMiHxbM41Dt /wDRsq/t1o8z72+hKrXsvr/cPY/tftlpRcXOKyl3cqGVJLvuS/JAYUIK2iQih8RXWTyP4/uWnVbJ fsVvJ9n42G/lOKweIxlo67CHF293cl/EvdZA3DNU704jWTt8EX7jL/8AF9tm7Ga5mbKStbRxiNLQ NDawrvWvs2sMSbefXV47tmNnO4M+WY7xls2vCJoL+R4nRywqnBq+JJr03P5a6a/j3kl2cGNuX4ba mY20VnhZLFbGzhtlvL+2tZzAAjETnhyLUqxFB/Frav43X1W0MrctvZGxdmkm4ziMa/8AkQv/AO+E D92vS8VVJLY562blss7KdtI0O1PmNIIJUhqaDQUC8upOPn8SoDU/BgdNEPYxjuSJfvrwlQStXTbo eNeurtjrdRZSYqzrsKubCCG8kMShVB5IATQBhUUqfrrGvGx1cqqLeWzWrLZ2PYQSW9/yB5xzqVZT Q+qNTT8NPJgpdaoVMlq7FomsWk4jmvl6l3/ZritwF0Z0rkPqin467XK2wvBAIVLzRFCQW5QytEeg 8eNdJcCHqw+502CEUZjI9sBSepH8X6/7NdmPjUpruzC2WzGuwmI7XtVLcnjmvIiTufRdSr1P4a0v hpbdE1vZBme2gnq7g8gDShprnfDxvoae9Yt/YNnbSdp4jJeyi3l5axy3UoFGeSnqJ8t9a1w0xv0o Tu7LVlT+aIR9nh36kXRUeW6NrerZlZGP5OA0xzdTHlMa6+VTdxr/ANWtDJmtdoq8GVzsUqlWP2j0 8/TItf2aysbYy1V5CgrtrM3OcT5aQwjLEoFDcQCn/wAxdUIFZVFNjcmOaFyInIXmu9FJ0IRjeXkF 3PJMQOcsak+A9S+GtTmH5iGEcjdZIon/AFjXTAtHYZ/zcmnQUhb9Qw/doew0XHiC4867akZRMRAI be6iXol9eqPzuZD+/VMlBAJ5nby0hkTsZB/ot1EOsOTyUdPwu5D+/QxIsYjUE18tIot/YFB2fioy N4o3j3Ndkldf3ai+46bFX+ZYA+GxsnTheLt+Ip+/VUYrmH90Ky4OV0JPtT2Ug3ofReQk60RkzRPj +8toszmY765KO1taugoZCQskyn9KjWVjfGXxb7FVIF2ajzjYag2O/fYv/wDK8P7jdNEAVae/QVFd AwFnu4rLFYm/yV44S1sraa4nPjwjQsafXbU2sqqWOqbcFbjkS9gtryL+GaCKRfIhq03H4a3TOVrU I+3ytbNz1NvGD/h9P7tMksXZXoyF8m3FoYjQeYZh+/TY1uXNh0pqRlJsgqXGUjY7pkLnb/mYP/1a bJRNHE7V/oNAyP2TEFt81GdguZvSD/z8JP8Aq0mBYmTj41NdtBRZOwpB/wDy9srGhjmukH+G5k1N twrsBPlyNW7etHDE0vIdvxYCuioWMF77ili7OzFxF1t4org9f4YbiJ2/Yp1TtCkhKWVL4o70yHef f+azSgx4ayn/ANLxBUU9yHlWXkR/ECw5DyprwcnJs89Ev1J62PCljbPoNZTWg/Ou+vYZyDvJvp01 IFKvb+UAmp66JKKrlbx7q2uLZwHEqMnGQckJPgwPUaw5FPPG690aY7eNkzI+4+8O4fjTM4bKY2Bp uxra1Szy2FX1PagSM5dS3qIq5o9SCtPLbx+FzWreNnqdfJ48ryR9D4HIW3cfamF7kxcn3GLycMr2 coWgKRTuh/MHY+WvpK38tjxrVgO9t32PxWZVMjdw2jXqfbWwndY/cnZgyxryIqzANxHU+GqtdLdi VW9i/NyViCNAyi2U3vZjuOErQ2+SKH6h7aCWv/xaJFATEdeg30SBG7KaGWTuNYZVlEWXkD+2wcKx trckGhNCD1GiQgsTgA1AroGNdmdxYrB9mZLK9zZKDG4zH5XKxzXt5IsUaJHdOyippU0IooqTrG+R VUs1rVvRFdvO4Mp8o2NxmrC1mw3x7ZR+5g7i8i432Zugylbr2noYbNADxrR5a12GvDzflPFzXU9F cNNRbcx/vDDfIfclne9vWV1jrDCZGF7a7uo1la59mTZqF6Kpp5V1zW/NWttUqvBpXdh7427AxPYW HtcbZN7pgUg3BUK0jsSWNB0FTro4XHs7+7frsLPlUeK2NFjXlQnXuHCP8vp/v1MlQUnIWrgHamqY kVHIxPGWY1pvqWMCS5rGxW7WWds0v8awKujgF1RuoUn+rXicv8csj86OLHbizuuj2F9uYH4un9u0 7YzU2JRK0w4v57RKuxZuMbSKBUk/9vXj5Hy8e7Z1L2rdEavhu2MaLC6wl5Yw3/b+SQR39ncBp4p1 U1VnZiWLKfUkgfmp3UjXEs2TyluX8zSKxoG7XtTu3tuFV7O7nS9x3hh+7PeukiXwWG/gX3wB0pKk n469Xj/kctNJlfE5MnHpb4fIBW0PyTHlM5dvg8LFJfzwzrIcvI1vWO2jgPAfarI1fbruo16D/Maa V1+ZguEp1enyH7ntXubuCKOLuLuGO0tTX7jG4VmtElB/svcnlOV8xGY664L/AJTNdNKKnRXi46fH 5h2z+NsG1pBa2rpjftVCW82Ka4tZkWtdntwnLf8Av11zY82Wuqs1/U0sq23Unpe081jF4J3Zmp7f epmgsmceVJZYRT8SDrd/kc63t9DP7fH2KA2N+He2ciMj8h5S1zuUjupshbjO3wuvZklbkxhx8JW3 DV6sYi311hflZMq11NqUVP4i+8f5m+375Y7Ht6ye/jldII5HC20C1IAalKlQPpqK47ZHD0La8VJT 7PvPNZ2YNdBIIa1WCEUT8yak/nr6Dj8PFic7v4nn5MjsaFiJ5J0Unr4A69RHKyz2xZqL46oRO4fQ dNIYNvsWzIaLqxFFzuLlAb09NSxoyPuexmVHFDtWo1mzRGN9xW0sAkmK1aIF15DbkNx11lbU2qVH Hd09+xwm77Xy2Rt7ZQS0NlczKYTXpwVug/DXj2x40/Ukd6t5V0C9l/MJ834giNe8cgQv9i44TUp5 iVGOm+LhtsjBO1f5B6D+aX5qkiMcnc677cmtrdW/URjWFuHjT0TOitqsI2/8z/zHcVV+6EhA/tLb Wqf1prC/GqtkzSER7v8AmF+VrtzDd98XyQFdmtZljH4UiUHQuOo2FC7FSy3f3d2Yf7W6zeTyksho sfvTzF6+FC37ta1w130QRARsvir5OzkEOUn7fmxWL5ei9ya/ahvqPdo7f4V0O+Ouicj+ZdMb2NLi o1Mt017eIwVCoIjVjt6Qd2Oliv61Blkco33trta5W3jeRKOQpcEdD46+gqeW2aTisM0SLtSmtkZs sdtYlR/CfLfViJn2jf3fDTAmzY8sCONK6Yiv5LBJNWq1+lNKBlBznYYueRVdyTSg1LQ5Mt7i+J5b hXBiLBgfDzFNQ6lKxhzfE/dPat7LdYuGS4iDkgQ+iZVB6cTQN+RrrzM+FvY9DHmXUsGMy+OlnhtO 6sVa3ErHiY8jbCKTbrvIor+R15F8VqzCa+R2VsnszRF+MPibKW8U03a8MMkq8uVvLLGv5BJANcrz ZFtZl+K7Iix/DnxZE7uuIBUdVaec0/V9T9xkf+xUJdCwYv42+J4EDDt3HswNB77F9/8AGx1LzX62 Y9Q9hZ+2sNkoIsDYWsbLJQx4u29ySi0r/wBlCR+ehY8ltkyLWS3ZpXdlhle7rGMWeFu44AVrkMoP tox0J4xVaRvzC67qcLJZ6uDltmrUAYT4xt7S7jvbt2vLtTVWK8Ioz/wIOn4mp17WDiVxnBkzOxpF l2+I1HooOvTXoqsHPMhi3xSrSo1YgjBYoAKCo0wJH2S/3dAE94Iz4flpiIM+Pjc04ih66AB8+IUg 0Xr18dIYPbBQMSGQEfhoEC7rs3HSsWaJRXzUaTSHINl+O8JPQT28ciV3V0DL+hB1m8aZSs0LHxd2 O0Sh8JYkr4i3RSD/AIaawfHq90arLZdRhPivsOMtxwFi3M1cGAHkfrWtdH22PsP379wzjOx+0sco NrgcbA1agpZwVr4GpSuq+3p2I963cO2mOggcPHEqAGtEVUFPwUAav20tiXZhe8nNzGIitUAAp4aF RIG2yBFaAMCIxTwoNaQQTVt3Y/w0HlqhDyW1Oo0xkhIgNMByq6kNB0e3x+nj+uqAV/k+NNACJPZ4 7U5eOkBBk+3r9NADD/bfl+3QIiSfaV9NdIobPs02rx/ZqBnF+2r41+uqQiQn239qv56BEpPtduvL wrpAh3/xtUA4vs7ceuhCHB/w0/8AXT0Ee9dfrXw0xnd6Dy8KdNMNTu+kB//Z --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651 Content-Type: application/octet-stream; charset=iso-8859-1; file=xy (409).jpg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=xy (409).jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAARgAA/+IMWElDQ19QUk9GSUxFAAEB AAAMSExpbm8CEAAAbW50clJHQiBYWVogB84AAgAJAAYAMQAAYWNzcE1TRlQAAAAASUVDIHNSR0IA AAAAAAAAAAAAAAEAAPbWAAEAAAAA0y1IUCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAARY3BydAAAAVAAAAAzZGVzYwAAAYQAAABsd3RwdAAAAfAAAAAUYmtw dAAAAgQAAAAUclhZWgAAAhgAAAAUZ1hZWgAAAiwAAAAUYlhZWgAAAkAAAAAUZG1uZAAAAlQAAABw ZG1kZAAAAsQAAACIdnVlZAAAA0wAAACGdmlldwAAA9QAAAAkbHVtaQAAA/gAAAAUbWVhcwAABAwA AAAkdGVjaAAABDAAAAAMclRSQwAABDwAAAgMZ1RSQwAABDwAAAgMYlRSQwAABDwAAAgMdGV4dAAA AABDb3B5cmlnaHQgKGMpIDE5OTggSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkAAGRlc2MAAAAAAAAA EnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAADzUQABAAAA ARbMWFlaIAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAb6IAADj1AAADkFhZWiAAAAAAAABimQAA t4UAABjaWFlaIAAAAAAAACSgAAAPhAAAts9kZXNjAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMu Y2gAAAAAAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0 IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0 IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAA LFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAACxS ZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB2aWV3AAAAAAATpP4AFF8uABDPFAAD7cwABBMLAANcngAAAAFYWVogAAAAAABM CVYAUAAAAFcf521lYXMAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAKPAAAAAnNpZyAAAAAAQ1JU IGN1cnYAAAAAAAAEAAAAAAUACgAPABQAGQAeACMAKAAtADIANwA7AEAARQBKAE8AVABZAF4AYwBo AG0AcgB3AHwAgQCGAIsAkACVAJoAnwCkAKkArgCyALcAvADBAMYAywDQANUA2wDgAOUA6wDwAPYA +wEBAQcBDQETARkBHwElASsBMgE4AT4BRQFMAVIBWQFgAWcBbgF1AXwBgwGLAZIBmgGhAakBsQG5 AcEByQHRAdkB4QHpAfIB+gIDAgwCFAIdAiYCLwI4AkECSwJUAl0CZwJxAnoChAKOApgCogKsArYC wQLLAtUC4ALrAvUDAAMLAxYDIQMtAzgDQwNPA1oDZgNyA34DigOWA6IDrgO6A8cD0wPgA+wD+QQG BBMEIAQtBDsESARVBGMEcQR+BIwEmgSoBLYExATTBOEE8AT+BQ0FHAUrBToFSQVYBWcFdwWGBZYF pgW1BcUF1QXlBfYGBgYWBicGNwZIBlkGagZ7BowGnQavBsAG0QbjBvUHBwcZBysHPQdPB2EHdAeG B5kHrAe/B9IH5Qf4CAsIHwgyCEYIWghuCIIIlgiqCL4I0gjnCPsJEAklCToJTwlkCXkJjwmkCboJ zwnlCfsKEQonCj0KVApqCoEKmAquCsUK3ArzCwsLIgs5C1ELaQuAC5gLsAvIC+EL+QwSDCoMQwxc DHUMjgynDMAM2QzzDQ0NJg1ADVoNdA2ODakNww3eDfgOEw4uDkkOZA5/DpsOtg7SDu4PCQ8lD0EP Xg96D5YPsw/PD+wQCRAmEEMQYRB+EJsQuRDXEPURExExEU8RbRGMEaoRyRHoEgcSJhJFEmQShBKj EsMS4xMDEyMTQxNjE4MTpBPFE+UUBhQnFEkUahSLFK0UzhTwFRIVNBVWFXgVmxW9FeAWAxYmFkkW bBaPFrIW1hb6Fx0XQRdlF4kXrhfSF/cYGxhAGGUYihivGNUY+hkgGUUZaxmRGbcZ3RoEGioaURp3 Gp4axRrsGxQbOxtjG4obshvaHAIcKhxSHHscoxzMHPUdHh1HHXAdmR3DHeweFh5AHmoelB6+Hukf Ex8+H2kflB+/H+ogFSBBIGwgmCDEIPAhHCFIIXUhoSHOIfsiJyJVIoIiryLdIwojOCNmI5QjwiPw JB8kTSR8JKsk2iUJJTglaCWXJccl9yYnJlcmhya3JugnGCdJJ3onqyfcKA0oPyhxKKIo1CkGKTgp aymdKdAqAio1KmgqmyrPKwIrNitpK50r0SwFLDksbiyiLNctDC1BLXYtqy3hLhYuTC6CLrcu7i8k L1ovkS/HL/4wNTBsMKQw2zESMUoxgjG6MfIyKjJjMpsy1DMNM0YzfzO4M/E0KzRlNJ402DUTNU01 hzXCNf02NzZyNq426TckN2A3nDfXOBQ4UDiMOMg5BTlCOX85vDn5OjY6dDqyOu87LTtrO6o76Dwn PGU8pDzjPSI9YT2hPeA+ID5gPqA+4D8hP2E/oj/iQCNAZECmQOdBKUFqQaxB7kIwQnJCtUL3QzpD fUPARANER0SKRM5FEkVVRZpF3kYiRmdGq0bwRzVHe0fASAVIS0iRSNdJHUljSalJ8Eo3Sn1KxEsM S1NLmkviTCpMcky6TQJNSk2TTdxOJU5uTrdPAE9JT5NP3VAnUHFQu1EGUVBRm1HmUjFSfFLHUxNT X1OqU/ZUQlSPVNtVKFV1VcJWD1ZcVqlW91dEV5JX4FgvWH1Yy1kaWWlZuFoHWlZaplr1W0VblVvl XDVchlzWXSddeF3JXhpebF69Xw9fYV+zYAVgV2CqYPxhT2GiYfViSWKcYvBjQ2OXY+tkQGSUZOll PWWSZedmPWaSZuhnPWeTZ+loP2iWaOxpQ2maafFqSGqfavdrT2una/9sV2yvbQhtYG25bhJua27E bx5veG/RcCtwhnDgcTpxlXHwcktypnMBc11zuHQUdHB0zHUodYV14XY+dpt2+HdWd7N4EXhueMx5 KnmJeed6RnqlewR7Y3vCfCF8gXzhfUF9oX4BfmJ+wn8jf4R/5YBHgKiBCoFrgc2CMIKSgvSDV4O6 hB2EgITjhUeFq4YOhnKG14c7h5+IBIhpiM6JM4mZif6KZIrKizCLlov8jGOMyo0xjZiN/45mjs6P No+ekAaQbpDWkT+RqJIRknqS45NNk7aUIJSKlPSVX5XJljSWn5cKl3WX4JhMmLiZJJmQmfyaaJrV m0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2n bqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQl tJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB 48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+4 0DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hze ot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c 7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9 uv5L/tz/bf///+4ADkFkb2JlAGTAAAAAAf/bAIQABAMDAwMDBAMDBAYEAwQGBwUEBAUHCAYGBwYG CAoICQkJCQgKCgwMDAwMCgwMDQ0MDBERERERFBQUFBQUFBQUFAEEBQUIBwgPCgoPFA4ODhQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU/8AAEQgAeABaAwER AAIRAQMRAf/EALAAAAEEAwEAAAAAAAAAAAAAAAYDBAcIAQIFAAEAAgMBAAAAAAAAAAAAAAAAAQMA AgQFEAABAwIFAQIIBgwKCwAAAAABAgMEEQUAIRIGBzFBE1FhcYEiMtMVUhS0lRYXkbFCIzRVZXU2 N6cIY1QlNUUmVidHSKHB8YIzs5SkRre4EQACAQIDCAAFAwUBAAAAAAAAAQIRAyFRcTFBkRIyUhPT YYHRIgTwocGx8UJyQwX/2gAMAwEAAhEDEQA/AJN464+2BO2HtWZM2rZ5Mt+z292Q+9borjjjq4ra lLWpTZKlKJqSeuMVu3HlWC2DLt2am8Xte8LBxlxqc/odY/EPdkT2WGeKOSF+Wfc+IojjDjPt2bYv myJ7LB8cMkDzT7nxHSeL+MTkdl2Kv5rh+yxbxQyRXzXO58RZPFvF5GeyrD5fdcP2WD4oZLgTzXO5 8TKuLeLk+kdl2DSOp91w/ZYXONuEatKmhaNy5J0TfE4dz4t2Aq9swlbNsbUVI1rUzbYia5+rUNiv jwm3YUpczWi+oyV+UVRNhMzxZxYUADZG3z4zaoVf+VjWrUMlwEea53PiLjiniw/+D7f+aYXssHxQ yXAnmudz4io4o4qpnsbb/wA0wvZYnih2rgTzT7nxFU8S8VVz2Nt75pheywfDDtXAnmn3PiVV+iW1 PxFbv15+5PwRj+av4l6n4P8AwPqeLHO5I5f50+R0+eWf/OvzJx4yBHHOzyPxJbPkjeNNvpWhgvdc tWGaDlnhokVQT29cEg5SqgxYFDcLrQYlQUPNsrkXVtsqT8TiNh91NfTLyiQhKh8EAFXlxkmlcmlu jj89xoi3CLe94HpcbvlqWo0cCiQe3PGtIzikZSkDSo54sAfocqnFio5QsafLiwRdC8QhT6vi/wAw Vccv2HW9ZMfGCD9WuzjTL3HbPkjWH2+haGS91y1YV0IOeLiRVJ7D1HXFgCiSagHBIOWQCr7eCQet xvi8qav7lzuVNr8Ke6BP2FFWEWo0ctf4QyexaCElwCgNK9T5MaKiTVK29BJIBHbi1QCyX0mmn7eJ UA4ZXU/bxYg8SKmoxCFP6/8A0Fjl+w63rJr4vQfqz2aa5e4rYf8As2saLfQtDJd63qwtSivXDBRk N/YGIBm1NJz8mIA8JKGAVrUEJHVSiAB5ScsRuhDqGbDYabbdCkuO+kt3TlVdEpT460yxmc+Sf+xo jHmjoRvvLfcSzTXISHKyUEtkAV9IZY0VxM7Q127uGfc1EuqJB6AdMMSFtkgQm1qAr63b24sQ7DLe nqc8WRB6lJwSFPqeP/MFTHL9h1vWTfxgK8ZbM/MVr+RtY0W+laGS71vVhY30xcUeWdAqqgT1qcum CAZrnx01PeJKU9SCKYlSARvnfdi2siO5vO3okbAu6/d8i7KT8ahsyXQfvE5mmpCFpFUOJqDn0IxR tjYQ3p4ojPi/dsyxcb72ms3Fy4RrW5OTttS33HWkBYKY5b7xR9EakaD4Mabf46uKkcH9Rzmo3Vzd ONSK7byTZkxYFhudzlbg3G8+VzLofTQlxw1KNeSQlPZnit2CjOkF9scK5/H6fAq/vyqydthXqVIW G4sRRSKAOKyBHTERiaJ0tfehlBeolRFVeXFqAOmmQynIqTWmLEHDchBORr5MQBULV/8AQVeuOX7D r+sm3jFVeMtmJr/QVr+RtY0W+haGS71y1Z27rOlQLLcrrEhPXA21lUhyHFop9SEAklIVQGgHhr4M Wk3SqxFpVdCk28ebuQbxGvl2lMyolhnzGPdSgXDHYbYSUhnUn0UrX6ygr1vNhdE2lXE3Rtx5KjOz 8h7iutmtTEq5vFkqX37wWUlSia6VU8HYMO5FUzzSpWhLu4rrbN0cNblsC2xJWiEX0hwkrS/HIcbd TmPSQRl4q4Khzyilg6irUuV47KAK7dry7+7w5EmJaTdpbECyHumQyoR1ykoa7xNEhS0thKe8H3NO 3DYUjgq4llFzmsP08ATtUGA0uDBtsdLUSMgNMKKaLcAzW84e1bqqq8SdKezArVhlzRXK2WI2tuGL tu4bJgvOUTuJ+VFW36OkBlkLQrMagQqgqDTPPsxWuItWnJOmLO2OYId23nurZ1vWp5FnLDUCTGQp xLsjTSQzqRq1KSvoB2V8GKqrYZWkoJi8jdd2t0mMiYHEF1IUkEGigcWQiUaBzYt0qlUbINe0nDSh XL4yrwf479758cv2HX9RPfGWXGWzPHYrX8jaw+30LQy3uuWrBXmBi1NWuNfN0bjftO0LWVu3K0ME ti4uqybaK2lIdOVRoSrx5YEnR55INrZTfmVFVzBt6DeL3FtVlkDZF1R3TNunSjKdSmlCVlYOpJPp JSolSfhHFvBJpN9RoV3leGw6Wy9hXG8Wx2ZtAt3mxrcKpdvbIFwiLUMlIQad4kAZgZ0xeVdu8YnB rlCuxWPc9mvLdmuDDiosqjUggEgsOnSoEdh0k9cVi1VPIyXGopoLN2cdyLVYLjtfa0R2ZbxcoqoK WzqX8XckyHUuLrTNKCgnyYbGTa5ntG2bkFPn7dgBykR9sz5Eq7kRIcSiVJWQVBCBSlEk55UAxIPA z3HzvA40ozt73+Puvdcs2TZVuZCLWlD3dqDKsyNaei1dXCnP7kYk8Fmxlp02Hfse8b82t1jg+JGj R7Ysa7s8sB8KcqFqS0uqiHE1BcWK+ChwIypVvaWcE6V/sTnapu4dy2aI1PjIZUlKFdwkag24BRQQ ogHTXEhCuJluOjaJDsFm7ruyolLtPSBw+hlriV77nx/46d3jl+w7PqLCcYICuMNmE9fcVr+RtY0W +laGW71y1Z07xtmybiiiBfIDNxiJdbkpjyEhxHesmqFEHrQ9nTF06Mqm0mlvB+42XYRdVBk2+1uu K9FcdbLCzTwFNDgq48ypjaPHGwdtXCfc9u2tNtcubSGLhEYcWmG8ltWtKu5qUpWkn0VooRh3kbwe KKt1C282Rq32J+5Q1R+901jOSRXu1gmneFKVFXTKgxg/L+y25RVWi1t1a5jj/Rp6+WuQnvWokmWp mT8Zhs01FSaAAaq6CCSK9uOXa/Lu3pqKSUKV241eS3GhwUU9Stm5tpS7FPuMZ0Fa5SXGlodCVqkF Q1JB6p0agnV/rx2YSjgtopPH4A3t/gW770ktyN6X1amkkaYUQaGkDwJ1Vp5kjGiNNxWd3InfaH7u e0toyoF42m9Ii3tiQ2ZDz7ynWpENRAfjutGqVBSc0HIpVnXBkmyRvYUaJyRaLawR3TCG6dAAMMMw 5TFjJOpKKHwjEBQqPRPi/X9TzY5fsOv6id+LhTjLZZr/AEFa/kbWH2+haGW71y1Z17tFss2JIjX9 KZFmWkonNhwtqQDmFJUhQUlaclJNeuBJreSEmnVFLOYIe/8AjncLE21yGr7te6OL+j+54dHFykpA UWpPdmiZDYNHKgV64ZbhFqqdTRco8UhbbHKPJsZ+Ob/dWLfBqPvKwgOLBFB6ajln4AcWpHdVsQob 9xZTi7fLG4oVx29fH27m67WQ2qi9DPcJKk6y2QSK9gVU4U4K4nCSrUrJKOKO5s2bvCFOdhymY8Fx hlwwYr6yGFIVRSGkgk9QSU1xyPx//LtWpRpKXNFUT/hjrn5EpJ7KABv+ft9+eb1eJCrFb42hp5cp lw92snSpTndpUEI1Gmo5dM8dZWZW21TYZ+ZTGTW5dv2NLb8C7xLgy56SXojqHkKB7aoJw2MxUoMK LNy3ZyUoekoQn4SlJSBXLtOG1RSjD6173tE9wNNSkrdrQpTmQcXTKhUy+lwVByOCQqVl+37HL9h1 /UTjxkv+7HZo7fcVsA/6NrDIP7FoZrq+96sBv3htibfv1hZ3TeVrgKsLLguL8FxSXHo5UkI+NoZr 6KVGiFK9LPwYjk6p4PcMhN05SrV63xG27ZITOzLWpmz3B5w26VJUDrWzpQ663EJOZUdKXHPW82ND ipSxBio1Zx7Vt67Xa4Jn3wOPTXFawh4lWivaa9uGKdFRYA+L2lmeN7rC2nIhbffQBJvESXJU4Tp7 piKEgqIoa6iqnmxIpJ1W4RKMphBvrlFuXaZUm0xgy2XyG3ZRCVd0Kd2oJST6yaKHlxyZPnZsl+LK G3cDH0m3Xu+0ostkiMXa5vJWh2FJyE5paRWOFmgQogHQVEpUfRNDQ46tqbpRvQRGFt4VoyvN144g 3oy52y1PxJ0Z1aLtaH0rbehyQSCw4kkFJBSetcF3FSlMS3K06MbbNahWuamz3q2XCXuWUsIYT3Lk wpUF6kJiobKqLNAe8oVeDT1xnkqvmr9q/WP8DqUjSKxe1/Qs/tmfMsTsb4xAWw88gOLDw0uA9urr mOhxoUjnTjQm/bt8VOZQs01H7kHpi4ordr8v6+9WOZ7Dr+onfjCg4y2YfyFa/kbWGQ6FoZ7vW9Wd bc217XvHbdw21emi5bLgEJkNJWtvUG1hYqUFJIy6VxZorCfK6g7f+KtrXq/bTmqskX3dYEPthIAS GW0tpEdtCK0KdVTQJ8dcGjc67qDYXYq3JNYvZ/IjceKrJIlmY0hDBJHoIHXF0qCHJsg2JcmLvyzv W82Yhdp2VambVDeA7xtUh6UhtVBmDrXroO3DE3y4bdxshGlKkWR7+9c9qtMukiREcVGlJzBC46tF SOgqNJpjO7VJVzLeWsZR3p/1Jw4hiOOvsy2VaXEaFIWMiCKEGvmxrisDlSeI+vW0Ye7P3mL4bclT MdVlgTt0NBJbbXMV6Ci0pBFFLbpRwZpUScZJxlKSinsdf2+p1I3KWW2ttEb2jYm+dp8gqiQVtO2u SgJtd2kNOH49HWFd8y+40AliWhIpQUDnrJqNQw9xqmmY1KmKJIuPHt4vl496XB/QlOTEbLShsdE5 ADLyYuo41M7YZ2HbqbYkNlHpDtxcWVn7oft90Y5nsOv6idOLKfVrsz8xWz5G1hlvpWhnu9b1YYil OnmwxCWbkEjxYsgArvfbt03RYZFltd7kbfkSFISu4xEpW93OYW2kKpQrBpqBqMSlS8JKLq1UgjjS 07AsT/JUSyMPzds2Fm2RbpdZK1qcl3P40SpTlSAlKFIOkBIpme3CeadE1ngb6Kq5sG3joV3t70+T epEyztszIN5K3psIL093ISpYIGlJ0aj6g6EEVxunGKiku1cd/wC4LsU7nPsrWv6/ctrxBsPcsYNy nVNotoCdIKiVkdelMqdMUjXec2441wJ6i2W3xprlyRHb95yGW4z8sD74tlkqUhBPwUlSjTx4ukij k2qbjolDJCUqQk6FBaKitFJ6EeMVyOLFTYq65Z4gDGvPPLEAVBr/AO/645fsOv6icuLiBxnswfkK 2fI2sMt9K0M93rerC9NSSa5+PphomgumpGfXBAY0hRFOzMU8WCQQk2GzTbPcbK/EZEC6gCalDaE9 4QrXU0GZr2nB3UBV1Bza3EfHW05EmVZLDHZkyiO+dUNZISoqAoqoyJyxYLk3vDxpLTKdDKEoR8FI CQPsYtUWZK/9nbg1KmpczwakPKWNPhH+nBqAx3gPQjAJQqNqH7fa+bHL9h1/WThxaf7tdm9v8h2z LyRGsOt9K0M13rerDDUAa1phoo3D5TTx4JBZpY06j2+HBBQVCh/u06YNCpulemmLIAp3oCSftYLB Q1L4Ir24JVmC90I6DrgkPKeFcj5vHgkNO8AJFPPiAKma0/t61ebHM9h1vWSXx3yDsCDx7tONN3bZ Y0yPaLexIivXGK28263FbSpK0KcBSUkUIPbg25x5Vihdy3JyeD2hL9Z/GtD/AFysfzlE9rhjuRzQ vxTyfAwOTuNgr9MbHQflOJ7XE8kc0DxTyfAcp5S40p+mdi89zh+1xbyRzRPFPJ8BUcqcaZD6Z2L5 0h+1xbywzRR2Z5PgeTynxnlXedi+c4ftcW8sM1xB4p9r4GfrT4zp+mliz6/ynD9rieaGa4h8M+18 Dy+VuMiNI3lYvL7zh+1wfLDNcSrtXO18DQcp8af2zsXznD9rieaGa4k8M+18D31qcZ/2zsXznD9r g+aGa4g8E+18Db60+M6j+udi+c4ftcBXoZriDw3O18Csn0q2x+OYH65/fP4Uz/Nn8b9b/gfwvqeP GDnWf+dTp8ksv+dPmf/Z --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651 Content-Type: application/octet-stream; charset=iso-8859-1; file=xy (46).jpg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=xy (46).jpg /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAYEBAUEBAYFBQUGBgYHCQ4JCQgICRINDQoOFRIWFhUS FBQXGiEcFxgfGRQUHScdHyIjJSUlFhwpLCgkKyEkJST/2wBDAQYGBgkICREJCREkGBQYJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCT/wAARCACWAMgDAREA AhEBAxEB/8QAGwAAAQUBAQAAAAAAAAAAAAAABQECAwQGAAf/xAA8EAACAQMDAwMCBAMHAwQDAAAB AgMABBEFEiEGMUETUWEicTKBkaEUQrEHFSNSk8HRRYKSFiRicnPh8f/EABoBAAMBAQEBAAAAAAAA AAAAAAABAgMEBQb/xAAtEQACAgEEAQQBAwUAAwAAAAAAAQIRAwQSITFBBRMiUXEVMmEjQlKRsaHB 0f/aAAwDAQACEQMRAD8A8YRwG4rzqPv0y3HRRsuSQZzRQ0iRcg0iiRQQcnimBYRsjvTSAmQ54qgE kcJnJ+1IBhbcM0mMdkMmPan4Aj3A5X396kdCA8EGgKODjtQFEfqmNiMZBoAUysew4qaCiJpGPNFB Q36mPNFBQrDHJoooibvmlVEsYTtOTQSyNnyTg0EjVH1bjQIkPxQB3inQmhGBxSolg6BjnnNamMWE YDgAkUHVEl3ADIoZQrTuPwAH5NSgHrJIWw7A/tVAWEGTxzQMnQcU0BL6Ybv5ooZWkjaIkjtSaBob Gx7GgaQrDkUJDFKEYIoaAQp9WaTQCSR7x2zSoTQyNMfSaBi7eaAGuuKAGFSwNAETD8qVCohkYvwB RRJFncQB4oSJ7H4wKKCjg2KKJHqRTAVhSYqoFW5yRirOeAQiyePFB0R6JwvHFI0HquR25pjH449q AJUOMUAWo2WmikWByOKYxGXeMYzQBXeHacjtSATYTgDkn2oqxNpcstC1SLCTO4YgHCAHH71ShweL m9YUZNYo3/JWnuLOAHeLogY/Cq+fzq1jRzP12a/sQe0Ppu31zR5dThuZUSKQxmN0G4kAHI5x5FLY kJ+uz/wX/kt3nRNlYaha2lxq4jkul3RH0SQWxkLwe5zin7a8j/XZ/wCAa0X+yBdakES60kEm4oFk hPLgZ25z5wcfas5xUeR/rk/8F/szHWnRV/0dfm2ucSxNwsyjAJ9iPBpbVW5Hp6L1COoVNVL6MwPp Yj3qD0CKVDggnn29qAK7DYMfzGggjCFTQIWQkLQDIRJzQRdE8coxg0DJvpPY0iWB7bParObG/ATg XIzQdceideDQWTIpxQAuzn5oAdjHFAEkZ+3/ADTGmWY3plE4IwTQAhTf9IGaEJySVsH3t9/Dyi3t wzSsdpZe+T4X/mrqj5f1D1F5n7WPiP8A0K6aIEjZbq2M16kgUI04RFTswOPPtkjOMDJpU5dOkeU5 beKJLrSobqZ50t4yn1FYmnIUDIIB4zj/ADZ5XzitU303yZbm+aNposlrJ0dfSDTrKwRLkrbR2zsU Zyqkk5YsDnGPBGDUba5bHu3Po2MfS2mdSapDeawibbaBJ5JACJM8YVfZiR+WKU5W1HyWk4JyCVvY WsVzI/8ACNEn41XJkMYHIzzz8nsa0UFHtDcm/IK6zt11WJH1EepCVCMxJA/DjcfOe37UlFRTQ8eS UJKUO0eLa7okmiXX1Zkicn0ZMdx8/IrCeOnaPr9HrFnjz+7yBnAXJ81B3WVGBJyeTQQNJIoBjWY4 OaBEG4DPFBk+yWMDgg0FItRjI4qWgYHg4INanLAKW/IGKR1xLiITQWWFi+ntnNMDtnPtRQCiPz/W gaFEeDnFA6Hg7TTGWEO4DGSaCZNJW+i36RhXLLkMvL57VpFJLg+d9Q1M8r2pVEz13a6i3UOmx2Vu zwNMg3r3HPY+dtOSqLbPF5ckkHerkuuplstN0qwkmurItLOiKFyjgbSMn6hlSPg1GD+ne58C1EXe 1HpfTnVVv03/AGd2vT1xp0Zv2iljuS5A9MOzcZHJbB/Kn7KlNzb4KhBqHPCB/TFvpsFollb26xWT yetK0o3buwHjJHFXOSsUYcWjdabLLcpLeXCuEmkAygBA+Bn4AH61jgm5Slk8dGuaFKMA56a3MRs0 uhb3aqSGEJYpHy3jz37cc+O9dV+PLOaX34Akt3JrvSD3U6yPeWGbc5UFZgF3Ak474Azk1jinvi0/ BrPGoTSXTPOYIoNellh1FZGtppFDOrAtFnsVzxkGueU3dx/0d8JezTi+jE9RaBcaDfPbTESJ+KKZ R9Mq54Yf8dwaItSVo+i0+dZY35M/KrKabR0WVnY454pARPK/kiglkBk570GLHJcbCPNAb64LsF4p GDxSaZammUrZN/HvVmOONha0gPkYppWdSjQRSMcACtdhVlhRkYxjFDgFibKVDOEYPekwQ4R+36Uq HZxh3dhz4xQkxOSStnKQilldSo/EwNaRijxs+oeXn+1CiT11BU/cGqo8TPnc3S6DHTkD3Ety+Nxh hJVh3yf6HGajI30iMNbuTURxTWdhJC1pFKUkItJVUep9fkN7fHvRHInCisyTyJiQ9PWNtJG+oXTT EfihUcO3tn2pt/RGRvI/4NOuoaZfWc67EDW1tI+wcZ4wMY9s1jceXYlCUWrCuizSJbWqnHowwqE2 sOXx3OfkdqjSR2w/JvqJXL8Dum7l7jqO6eIzROscoaR05UoCM4GCFwDg89+1dUW9ys5Mji1wDumL lItP6h9VQ8JlBHqfhDGMgAsDnyfisdNL5SR06lNqFFL/ANHyf3ULmyNldoSHHoM27thkbwfceQR8 1tHDKUW2c888YT2tGZ123L6W2nX0Ts0M2Y5O+zI5IPnOB+lYxhU78M7tLncJJpnn+oaS0MhUgH2I 7Ee9KUa4PpcOaOSO5Aea0YHt+1Q0blSWFh4NAUU3jYE00YyTIJCwP2pnNNuxouGTsadIzeVo0GnW YWP1ZcKvuTirhj3fg7oVFcheOBWQMjBh7iuqONIbky1FEAOcVdImx5iFJxGmM2YOKwcS1IUAj70t g9w9VNGwNw5M7xx5FGwmcviwBfaUxFysFxFl+ArMRzmqSpnzctFkceH2TaZDPbxLDcTQHacbgxb6 fbtVyM4+nZOm0jc9PWRto5bhXZzKiYIGAeePzrKS8lvSrC1udnqegQ6clnbQ6pcO8zDEMaLlYc8Z Yf5j4rbEocbjxdVOc5Nw4X/QJrOkWcGqKlpcpKrsFIztwx/lz759qyy44xl8S8WacofJcg+6vryH T9WhmsLazWCMLyxMjgnuD5H/ADWGZVBnThkm0m+TUdPNJPZwuGRlVkH1EDvg558ZzTxL4pDzvlsi 1exg+tzc+i9uGEMkI9M7mOSp9xycZ+KNTF7bT6FpZ7ZVJWmZHUEnttLwUwstzl5tpG9QO37GsdI+ GzuzSjGXC6RFpfUt/ZW+dLvJ0tjISYHOce5IP5fqK606lwcsnDMvmjUP1Ub+EI9oi87lWQBkkPkE EcZrSUt62nNHF7btME3undFdTxMYy2hXyZEiRuGj3f8A43Ix/wBrflWDjwehp9Tn07qrTMVqvQuo QuwtPQ1JByDZyB3x77PxUbD2MHqeKXEuPyZSeyUEqwKsOCGGCPvUvGz0Y5IvlMH3GnA8rzUU0U6f QNuLFgfwmlZz5IFKS2YHGKq0cs8bNA9vNcENOe3ZB2Wu3Ydf5CmlKYwUPb2q0U+ggBhqZJL6e7xQ MX0c8YNS4jE9PxwKW0KFEYxmiqCjgqgjmgTXAHuYgLiUH/Of61BwwdxRb0axtry69Gbcu5G2YOMt jgUMbVnoPQiS2OmXn8aCI4iAsZ/EDz2qHwm2eX6lKTUMa7Dlk99tTVLaORJBLn1Sg2rjscnjA8Vn j73eTllii3tl0hdRs7DWY4EvROEx6kNzbv2PPJA7/l29q0tvsxUpY38SPWtPkbRtXuleCXFlEssp QszsH/GrDhQRjOe5qZq4sNKrzpfZqOnIraPpRSwhEjTALKQGcAIDz7Z7f/ynjraLP+9pA64EkcK2 zSo5lYvK0anBAzjA9uAM/tWOpltgzTTR+f4K3Uerr090rbw3dsLiPUZjI8QJAVCdwKPjCOMA85+2 DVaWG3Ci1F5s7a8GatRb6s9vPpsLNNCSUf0eTnw2Mg+x55oeNtNRZpKMYS+aN107Y2E8LavDbRSX Cv6U1lOp2w8/WAwOQccj4o0uV1tf7kceox078MC9Z9MabpnU00NvtmhWP1R9OQFIzg474B4YVplt PjyXjyNwTZ5FrGv6WLt20+3lAGMOHK8jyPIqNsvLPf0+J+2ozBWo9SS6i6POxdkXYGc7mIyTye57 +atOjqxwjC6KB1NPI/Oiy99ET6jG3HNRJJi91ED30B7oD84qHFE+6GZJ4sHBrvtG5FFeCJgVai0M vLrcQA3Lk0WgpDZdeLDagC/NLchxKzaxMTn1TRuKG/3q/lzS3CHf3q5GMn9aTkAw6g/fJpbhNhS5 i3Ss2O/NTZ5mJ8UE+mtEbVrqRfXFv6ShvUxnBJ44/Wk39GWr1HspM9A0u3KwvZajLGsiYnimTlJO CMEdx3zSlddHNPdq6yY1yuGG7Z7y86fXToUtYrNeJZNxB47HnspPPbzWG2nycuaMsfM1z4BGnaxH pN0bC7CHTt20yH+RgcBwfHP9a3dcUcabklHyG5rONJb2zIV7W8ie3fuDHIR9LDx3wD45zQ1uRWOb hJP6DH9nsS3+jyafNu9UorlCdudgIyCPy4qNO7VPseq/ff8AJam0iCSCQsxLyfQuTkxr5x8k4qcu B5GknwLHnUEDOrLfp+D+GvdVjF7Jbx4gtQfp4AGSOxxgDcePvXQ6ilFInB7kr2uk/wDZmB1nrWqM bbTrCzsrbB4CbjtHfnsPyHFZ2/s6ZYsMP3cssdL9SW69RRwDUxObmNorx40JxtGUfJ4Zl5X5Fc+V OMo5F3/6G8MnjaapeDN2vUaR9RSaiiGOJ5GV0PlT3yPn2re3drwavTP2VF+TzfrfShpHU1/axgCL 1PUjx22tyP61U+7PS0E3PAr8cGcZTipOzkiZSKTJaYwrUkNEbJQS4F8zs1a7jssbvY+TRZSFG4+T RyOh4XjjNFDqhQDmjkpDwtUA8ClVgSBCadEs21roN1fxQNb+mxlRNoLgEnAps8OGdKbx83bNT0/p VxZwyWwKbYZCWliIBkPsR3Pwe1ClSSO1Zccpe3JfhmhktEbJ9LLkfUVOcVcXxycWr/pTcIujpdlv YOwm2R4xgNg4rLUOMo7asrS6WTbyZXRjNXiN7J6guFCnvG5Iwf8AelFVwycuDFp4+5jTPQ+m5559 KsVuyrvNHs3997IMKfuU4/7apKmeHlkptyj4CehrcLfNFDE2yMkIw4K7uSAfbOazUHCdxBZU4VII 31yIbs2YeEXMwDmJlYbE/wAynscnPFaW7oTh8NwD1+1gu7Jo5xIkDDZIsMe5nU4wN3jnB+9Vf2Ri m07iuTMdWaFq9vYJYpJZWliiACMTZklA8N/x781lHJGV7T0cdYpKeSNtmF0q3nE7TwzLby27B1dm 2kMDxj9KD0c+eMYK1aZY1dZPq1WNFNvIwcrEfwMeGyPAzUbluozwyuG0zvXN/Dqmrx3MLFlNvGpz 34yP6Yq/Cs69DieODT+zMMufFI7iJk57UUKhhQUUS0NMdKhOJZEeRV0bJDljp0WkKEp0Oh4TjtTo Yoj+KKAeE57U9oDwmfFOgJETtTJbPSOmrgCxscjgx+mcfPFZvhnzccix6yW7r/6aBLj0DGm1o2Xs 0Y4NTJ8WjqyaWeKVrkMPJcSWQmMaKzjBIPce/wAVsoSlHcVJuWVOcbaAF7ISxDZyvbNKMEgzZ5ZJ fLivAMdRPlnACqdo+aiS+jDPkcMUnLyqNtpd0t2UsUOwxbHiB/l2nJx+Wab6PnsU1u5NhpETi5zG dhzlhjle/I+9HbKqg5NYxXkX1hTKEI9QKN24eM/eqUVYnJ1RkroX1ss8ewwTpGyMhIba2Rjt3z3r PLKoNm2nheVJdGd1tv7zsv8AHjEN9EdxTxIuOSv/ABXnYntkexqI74GFu9NKNMyjG8h/tXa5HEpO UUn4BulzIYLyCUn0nE4Yn+UEjB/IhqwzxfuxaPTxr4xr6Rjr/ZJcyNGPozhc+3auuj08aqJSZKVG tETJihoKGlfikFCbaVE0ThK0NDtv6UykP280xihTmnVAP2kDtRQCgZPNMCRUoAkRNx7UGcmbvpmN n0632jJQ5wPHNZy5Pk9e0tRNMOwavax3jxXYADSfi9UZA8fSaSi0b6b1RYsag3dBi79JLRZUladX UlUA/KrbqPDOqXrGGL3pW/wCbpYdhkdmCov1AePzoTaRjP1XDkbnOLv+AbKkkiiQIojAyMnhR71K i75PL1Os9530kbfpWBZrr+KLA+nHzjnkiqkjhx1utG1twyEOHcsMhccc+x/ShG92F8JPBsYyB35J PPbn/iqIA2uarp+ipGb44SZtqXBzw2M4YDPjz8VlmxLJHlnRp83tyszWpav05qjqV1KKHHnYxz+1 ed7GRHrLWYa5ZjdSltp7tltbqKXjYADjcfGBXVtdJtHCssLqLMNrdwttbyWEabXJAkJGCAMnn5JO arFG5PIz3dNFum/BnJVFbneiuyj2oLI2TPikAxk7nmk0AwIfGakks7K2SNBRHgc4+KraNChcUxjw MAfNMBxTigDgo7ZqegHgqvenZLZLHKv+WobswnkXk9v6K6Wjt+lY5Wljiu3ga7ZJCBkdwo/IZrLJ Ljk+Z1uFZJvJ9kphhut0dzbGRY2wQ4P0n/7D/Y1nHIn5ODJglDtCyW62ri2hjKIsZfnkjJ7D4rRt Mw2lPKoDHDCqM55x3albZpCLk9sSrdaSl2wT+IdHHcKeAf8AeqjS5OjPopQjus2HS+nf3Xpwt1bc SCxJPJY/f9KvluzjjSQegI3D6OBwFzgg+eftmqKL1vO2UO1jvIUnGee/jtQFgnq3TRqOlvFvAlHM RJ9jkfbyPjNDXxHD93PRm9N6Z02CVJ9UjkSJkbcqsxYMoB7fINcHuTnH4nbPHjxTaZPd9OaIUur7 TlJNu0exJGOWVl5x8g1cW0/kxUpcRR4x1PpZ0rVri0kDYVtyluSVPINdEWmrR7+lnugk/Bn5EPfB xTO6LRXZRnAqvBrZGRnxSoYwr70UAm0e1TQiQpn2x4FbUMUKR9qY7OIxQOx4HJ4oCzsZoCxChPak xNj0hZu9SRIO9N6BJrGsWdjGu4zSAEfHc/tWcnSODWS2wbPf7HUbR7gWN3HDCLX6CGACsSvC598Y +K5sltNro8iOWN7WXNQvv4TQ0m09QJJlWNZFXsM4Jx74Bx84qMeJOSOTLqZRTSfBjC080jIs1tKM MBJKSrk+Mgf0Fdso0uTz02+Slk2+EAbK95G/n+2ecUouuzs0WX57Ughp34gSVhcPn1nOAOal8Lcj 1ss4uFSDNnqkL7ElIjZBnP8Amx59uSQK28HzcJXwGYJg/wBAdSqgLls8kDJwf1oL3BaLaqcN9ZXj B4JGCP2p0JyB+r33oQyoAjFiAsjE7sd9oB71VeCN5W1ZI9RZZwm2W4ZFwp7cAEVzUox2o6N8pPcy t1Lbo2qzQws0IMmPpOM7QAP6VnjSdJlvJKPR5z/afp/rJa6gdpmUelNj9j+uf1rSEdvC6PS9P1Fz cZeTzWVXHA7VZ70OSo0R5q0dERhjP3oKE9PvkUAcYSTxUtAdtHsa1AUp29u2aBihAO9MY70+3vSC jhGAOO9AUSJFmkwoniABAqGZvo9R/sZ0n19Su9UYfTax+lGf/m3f9v61ll6pHh+oZbkoBXrJRa6s mmwv6si/+4mb3dz2/JQtRDlWeVljUVL+TU6TBFe9IWSzv6QEIwxwNpBNR1M5pNUZyeeWKfbbmIxk lRJGzfV/5c1vaZmr8AiSCVpZmLFpCCo+5+aHVUXhyKLtg/VIb651WK1gLlmVSF8Kf5u32pYX8aZe admvlspYVXILFQMEc1ujjaLlnPLEihTGCCchjjOftVE8h6ynmMDRPdWyl+zIhZl48cjmqRLsiWxh ZmYyFywxJdTHP0jyB7481M5bVYY4OUkhNHvLGbX4cuFggXOQhPP8obA/OuKSf2d9rpeDM9d61NDd m+hUrEs3qKxBGRnj/erh+1ocI+5kVFTVrWHWdOuUcnLx/wCG2OGPcEftRufCRcH7c032jyWaHaxD DkEg/FatUfWYpbopopvGozxVI6ERGMZzmmikxRHnIoYmKAq8kE0gsgEZBwQc+assURtnGMigBwjO MfPeiykhdh4JHegY708HIU+1AEirjAOalsGOOAPY0jKa4PSOn+qH6X6eg02zjWK5kBmluWG45YcB R9vJpPFZ8fq9RCWScr5TqgPJqs815Ldy3MjzSNkuW+phVSxOjmlrce1Rplu11+9ZoYZb25/hozgR 7sgDPYCsfakOOpwcWgvbaxEIVjafOxmI34xzVPHXBjPJCXKXANn1yON8wNMmMjJA5Bqo4x4c+KCq asZDr92jMIb+eNGbcRuxzRHDTNcuswNOkzR2PVlstrElzPcSzbf8RxzuIGAQf0rRQo855U0Tw9SW DE/4soBP8w7U9pHuoJ2nU2mwhS04IHJATJppD9xCXXWGnFTgTP5xIoIP355pTjcaLxZoxlb6A8nV lqIrkwvNbSzsG/wgAPY55rCGnkl2bz1kG+E6BfUnUtvqUFzAjTyJKD6SyY2xncCD344H70o4ZLtl x1cN+5JkVt1LFbaZaRKAZohskU8Bl8YPvQsbVmvvwnJ+DH9SPAdVkltd4in/AMQK/dSe4/WnTXZ9 F6Zl9zHX0B2DNztJH9KpM9Wxm3OeDVJjFCE+DSAkWI+f3HBpMQ0IAMZz9hWhoOVQp7ec/egZIqge eO3vQFnEqMjaT9h3oKODgY+jP3qWwO3t2CA+KQMjlSRkIAA4x2oIatAmXTtSdiw1W7X2USHCj270 /l9nj5/TMeSW6uySy07Ut2ZdVvGx4EhouX2ZQ9Gw3bQaS3n2YW5uAcd/UOaLZ1fpenr9qB15aaqC TDq18vx6nFHLOafpGFv4qgc1trzNg6xdn/vNHyOd+jwHx2WsHg6vd/8AnRb+yl6NjfZY/g9YUcax e/8AnRuf2J+jY/oZ6OuL/wBXvP8AUNPe/sz/AEfH9DkTWQOdWvP9Q0tz+xr0jH9Dtusj/qt5/qGj eyl6RBeCNoNWbhtTu/8AUNJyf2P9Kh9ETafqcnJ1K6/1DS3NeSl6XAculXxX6r64PuTIxpOy4+mw TuglaxyRrtld5D7scmn+T1MWNQVJFjnbgE0vJtQ1VXB9zVDH5+rGO9AEgjyeM/epskYI+T7Aee9a WaWO2gHtn70wEEa8Hv70DJBEM9v/AN0AOWJQMYH6dqlopMUgZ7VQ7EPftSsTRH6YPGfyFSLaTQxD IGDx+9A1EsiMAcAZ70BQx1QnkH70EuJA8KnntzQRQgiUe1Jg0h2wfFSLaMMQOOBzQG070TnGKBbB whHYjmgNtCekM470DoT0QSB+VAUd6QPxQFIb6QPcUBQhjOODwadDFWH5579qoCRYh9xQJj9i9gMV BFDBGG78Y9q0RocYhxz5qikKqbSD70EtjicDNBUTjksBmpbGcFycfNFjEx3+BnmkOzgoIHHnFAWS Rjj25xQNExwAD3HtQAjHAIPvigGyJlw2T7eKTZIm0Hn5xSsBSgPbvSEKI9xwe9AqFMQUUBQ3Z575 oARE5xnmgKO9MA/agKOAB496CTtnj5I/SgBNn0k+1OwHLDuIBxzTTAXZjv2piHKgPaoJZ//Z --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651 Content-Type: application/octet-stream; charset=iso-8859-1; file=xy (903).jpg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=xy (903).jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAARgAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAFcQAAB1IAAAqzAAAQGP/bAIQABAMDAwMDBAMDBAYEAwQGBwUEBAUHCAYGBwYGCAoI CQkJCQgKCgwMDAwMCgwMDQ0MDBERERERFBQUFBQUFBQUFAEEBQUIBwgPCgoPFA4ODhQUFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU/8IAEQgAeAB4AwERAAIR AQMRAf/EAMoAAAEFAQEAAAAAAAAAAAAAAAEAAgMFBgQHAQEBAAMBAQEAAAAAAAAAAAAAAQIDBAUG BxAAAQMEAAYDAAMBAAAAAAAAAQACAxESBAUQICExExQwUAZgMhUjEQACAQIEAgcHBAMAAAAAAAAB AgARAyExEgRBIhBRYTJCExQgcYFSIzMFMFCRwaGSQxIAAgIDAAAAAAAAAAAAAAAAIBEwIQBgARMB AAICAQMEAgIDAQEAAAAAAQARITFBEFFhIHGBkTChscFAUPDR4f/aAAwDAQACEQMRAAAB903coCIM roFMsFEMIQhAFQDBUwKZlAEMGCIQ2jApCCqhtNsVGHQYIgKqUIFIRBNkMylyxly1hCGREuGTMiBU CxMkvPq3VnD6tH5/q9fbw5nl7N/9H8bdyGSfXk20LyZWm0dfFq6bHPCfHJ3P1UvlejW4dWIvZoPs Pzn1TXi6JsMuRtGWGW4vRrOT0bzp57PZrpNO6k8b2qvk7eHLc3r5ez6j4P1jZo6MUa80uN09jNe+ 517Z2WH8j2s/N0evdoJkzVlDjnrvc+T1fs+F2RzS5Lk7cPh2aXPS7m7KPg9Gt6NHH6Hnab573X+j yt4ezY/Q/MVHN0S+n5G8xnAtVjnVkGUhG54x5zmxzxfN2ehb+fzzC+55apmOOrRyXUQ0LI7IKjVk ZXHOfKaCXAHrMkshR8SY5BAMyjaCqK9euySZMY9UqgWIlwooUoIZRSG0kQhAsBJjUAfCUwKA2hYh AoASbCkSmBY7HJuUAKbYKUKmgr//2gAIAQEAAQUC+0MsYL8mBgjkZKxVVeFeSqMrQjI8qwleWNZM sWQ3yTY5k20/rw7KfGi1WwGyw+QtKd1UuVDGWZ+S53/cGHCijRgN+QysznRxSukYx/5rc4jRxNb3 SLL2Lg/1JHP9cENdGyPL3QxBJucmUP2UsqkyDVmEc2X9LgxYuFHIJI0XJz1/oPy5Y5A2OF0kzHTx wx/6TsxSzPfJAJZU/Fx4MaGCL1ceoVkezxoIhBEE4rZbKKGLW7yPGhxJMOkGdFDEMqTJbBewujdd rIWhk7PYdjy4+M8QQZC2Wvyo8f8APbr3o08VAxYIxNrsWQ+nG1eqvSTsUNXrtWrGRnbOGOx22g9r 9I2MKwrbaozP1GdNnYxYvGvEjEF4140YA5bdpx8DRa8YmvliqNVje1+gDVarRxoqK1WKxWLKwYsy GOBsMdgTIIo/joqfTf/aAAgBAgABBQL7W4IH5ap7gU1xXmQkNedz6K4nhaiE7uHJqPJTg59Uzqmh dk99E6Qo1TQm/wBuW5HuO7zRSuJXdSC1DsCiopruR7kxOKe5PBJMJKbHRTdXRxLxm4xgrwCvGioq KipxDBwHf4zxH8B//9oACAEDAAEFAvtKKwoinzRsIJYHL1RV8DactODYy5eMBFoV6Dk3tTo4dDyA 8GMondE4oC5RxXJsIQYAqKR1G8thCCPZjblEwBAAKN1RUku7lTQ28jGqTqmhMb0jIAbOAnSkqPo1 89E6SrRIWo5BIPGqqqqqrxMrqI/IOJ/gP//aAAgBAgIGPwLUKlqBGw4K6KO5nqX/2gAIAQMCBj8C 0W47ludB3GD4LOseVlxrUv/aAAgBAQEGPwL90pXGFncACB7Z1KeP6XXOXCcxrGFt11rmIFKYHx9U rYJ/ox6W/qeFo15MhiV7Ym606C2a+1y4++aa63+VcoE8sJXI5zU97l6gIWs2+ZsS7Srcx/xAO72i C25rbxqZd1fbpWkX8eWozfbPWer2A+rLhMTPKQcrYa4txeGdcpzNXsXCUUACd0s44ZTUtEEGo1pl NTGZgW7mE2m62qBPR3FqV+WK4yYA/wA+xfRQV29rlD/MYR/2XKUdsJU/6y4ujToelZukY6iaTy68 ohv3MzhbXrMdWxuNAO6RwlzY7g0W4KYZxLK91AFHw6XRDquEUw4S5Z3in099iPMXEqeBpHf1C3D/ ABC1ttWdJ5t0UJ4S4aU1tWMfmzjO5pKeEYKOqeTubgDjIGfVQGG5+Jal4eA/1PSbvl/IWcGDYFu3 oIOU5LYE1PZUn3Q6EAr2SgGHTXgJeuW2Po7dfdOYSxZTM6NXwx6MDBvdr9L8haxW4PF2Ga9xZNm8 nK4PE9Y9vGbhlwOjCWlA5mGpz2mVpjNzu2H2OUfEU/Uaxd7jZxbS5KKDoJRApOZH7l//2gAIAQED AT8h9B0uLLl/guXLlxety4equt9Fl9bly/we8uS/YZ/iDxW29/UDLpCXULdF9FdFmG4lQ27ExQPd llHN7pQ25xU14YkDY0pp7woOOwYPJEllFBiu8tRWz7sd7gIzhfdJ56s3iZug7zzO5wI6w3g+TK2d YpvB3MjHQ7LG3PiDV3lxGGKGCCo3wvaB5Vr6IEJ520Mx7wikNJQFdsdzAp2UZzA/2+FWVd4PA+4O S9rHBZadIQzYe2f5lU+tRtg+Jn+Sc5o3Gz4QU2TfyTOudfAuDElUFTI7gL+pZu7EViGNLaHMvuVs 5/MccJAFujU5wcuc1HReyl/PPfBb7QliMB95dBt7Yiw1kcMG8S33LO6FdABmADW7Fubgj1Mqb5BA iOKbtnmmcuCqOvdmd0rXtOYw8qlDbdxTvmL5+JV7+2X/ALLwHret1AC54dP2R4Wyl2e7mXHjjA7O /eBDzNFJ4ZUOC1b+5l9N+6aJ9qhVYHYQvuF3UEtnMvgljqUPLARYFKuwf8amCVVSrOSfRsFf83Lk cq8B+iXRis7OJ7R8YVQlvloZ5xMfj99mhroQLMd32XTO7pBWpXRSIZSUiYMKnVMM1G67LRFtkZeO yUvvK9dSpXUqV+CpXpel+uupqPRj6Vn/2gAIAQIDAT8h/wBpcQgJZ+VHeCQ+SDrWZz8r030Dy6QK 8yhqZIq7YK0zYmXocpglSotgxBjWst13j/ED29EWBLzE6sAlwgB0NtlJLTAKczzMsxZ5h6AqpgwC QRxuVyUHiAZ8El5cGLNwQGx1cwJrorK9FRlvCJ6Z9dzSPTTpcvrfS5cuX0W5cv8A2X//2gAIAQMD AT8h/wBoNguiOqfx1LgPJuXqYoTvMTgI79Sp4zpodEtpZgj98E2N9KKX0UlTcvXLMyEkQZlL2h95 mmhFtDNw9FincaiuOg0XEZXHRmJImKJLHF6Hu2YJQjuWpf5Zvdlr5ipJdr5QaE3yUSBXVbuXqpeX 6LgzYJcWOt/h2l9F+U6V/sv/2gAMAwEAAhEDEQAAED2Zr2TbazPEjC3bZ7KNva+3h/E8ZKG/aWU5 T5H/APkILqf9SdENtKAoykWceBm6IL5c+DCU/rBR+J4Pxrphsg52vLcatQKpGOlGwYxm6mCd2I69 M8bf/9oACAEBAwE/EKnz05gDcU0Rp9QHMosIH03LmEBK1kh44lm9RDzMFcwEtxL1nfoLmyN4FHkl 1XM/Rg954oouX+4MIIpLI4PPMN1LdSo1H9SwLVHmVDJml/ulDoDcB4pb8QE5X/cNjKUuBojW6bnu hfcYdntqLTk6CBaoOWOEdtvPvKzJdrB4CUy7ulR9Euu0rwgtobFimwVLLhQLjkGVzgG18SmBfNKc JEaQ1LRUKYBkVnMduxSl9YoWO9QqMvmmibA26gxKMt2/UBq9hnxAen5rJ7RACMIonnBXzKUN4OIJ WKO/mCwMtwu1FEcsYKAdvaC5gAsFmarZH/8AAF8qKOLmV8j1eQXFXIo1qLWGzfMy0QB38QV5lxyy rabu5Z2gM8FHtF63Uznso17y5iW+13b3JX87K5Tucyj6Avn5ytwBUxtpQqi8xTxGw3+wywpNteN7 0RMUEQaq63xPA4mcgQGw1XMLGWic94ywQ3IB/MSi8HeU74IIVcBauAOYH9m5b4nYQgHbUB0kpECo FMM1UorAovDUJXlgFS4aI5K2vsU8/EsPEPFWFm7hOt7mBRiKeymXETxEC12PFwuukhKipxYkYtPT umFveiBrMdKoM24hVQCrMUoX9QelmkGgoPcrMA+UaEiiCxTiLHeAwVeKMTGNgTQFC++JcVZY+wfx BFrfKrAUEFkvhcOByw6lAqbNvynLGhktZsLDsxmM7yn2oYT9lP7u96HBzLMJEbIcEGHCBAQsnaQp JhzDJNHlssq81K0PKii41WgJF++JTF4gAD2nAUGu0dZe8FKBXcBbNms/SRheUWAyhvbNGCvBZL8J UNAAfET2jgRjtP6ANHNmCM8kRBOUQtQcH3nhzGnJZCGv1Daz4i8w52NRhEbYuuP3AmhkM817DRBp QbsO0vka7QQ/QMUqiotdnENye15gChQcSrKkUK3mMVVR4D4mSqicJKLY90G8PEvgbw4Gi3lg9XDs YfCQtJi0GfmAS4nE0x3MEYrfYglgI8YjUpqPQ510YlxEuZu/qBfjvBfU0KxHtCJbE4IEl1Ns6gFR 3P4irAXUo/8Ak8IVVRC4CMcS6xcGfMoviZHfRfMGqGYa5n//2gAIAQIDAT8Q9D0qBKlfgqVKlQOt So+q+tdAldGVKlfhSQm1qAksZUqVKlS+gSpUMypkULJW6e99pkVi3dIaDS4oDz1OgYKzHwHuoczf RvDMUtt/UbBhLgWF5iLmIJToOjAlobgBLBMkyQ+ZlDiNKEEaOFxejDxBcjKMEvRm4oDKGJKilP5N QQKWBEQS6IZ5lxtOXP8AM8onmeB/cuQS9phh1x9/eLcYy0OVgGHa4Y0dpQ7cJvZCVeqBBncJlQWn qzB2gcGmauYWuxxNlkYAU6gFCoEbDLLKxLG4CA6bhC5ggu0uFQKbIcXBly4S5cwjXCCsdpdQFnm5 fUWX0XD0IpLV9Dwl+k6XLly5cuX+C5fpOleu+qw6EPSE/9oACAEDAwE/EPQf4F/kqHpPx1KgTTEd pFYuGkj6L9IMrtgDUdVlcomtrjvAqX9nzGmnmJdGwfMFI7egF6EEzRQ8wbSV4hOyKhhHBBqGD9za irFQjhuOqtr/AD6Dem+YqoIBhlZirtMbM93csiuIzYCrvMPklxSrgVRBUi0R4O806hKnAs+0emzl EITcQoyx3wamgwp/UN6VPAe3+pSPBFlZGMnujt1IolQZzFXbNp8RJu3vLFUjPAMsptsjOVCiBbcz Pebtd5dgpI9lCKCG+ZY8dBRuP5LFxZogV5YVVcXL9IAtqZxCdRYcXUwNXfqJU0XMleiYJdxlSutS pUqahY3BXTu/CEr/ADj8X//Z --cf3f5fd0-2949-4ce1-b5a4-f21e6a2bb651-- From owner-linux-xfs@oss.sgi.com Thu Jul 18 04:50:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IBobRw025231 for ; Thu, 18 Jul 2002 04:50:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IBobUM025229 for linux-xfs-outgoing; Thu, 18 Jul 2002 04:50:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03.onolab.com (smtp.ono.com [62.42.230.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IBoWRw025195 for ; Thu, 18 Jul 2002 04:50:32 -0700 Received: from ono.com ([62.42.230.26]) by mta03.onolab.com (Netscape Messaging Server 4.15) with ESMTP id GZG0YX01.QUB for ; Thu, 18 Jul 2002 13:52:09 +0200 From: To: linux-xfs@oss.sgi.com Message-ID: <4b5284eb63.4eb634b528@ono.com> Date: Thu, 18 Jul 2002 13:50:38 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: Plug-in FSIM for EVMS X-Accept-Language: es X-Priority: 1 (Highest) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.3 required=5.0 tests=X_PRIORITY_HIGH,NO_REAL_NAME version=2.20 X-Spam-Level: ** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I like know if XFS will developer a plug-in for EVMS (FSIM). EVMS has plugins for JFS, EXT3, REISERFS, etc... but not XFS. Thank you. From owner-linux-xfs@oss.sgi.com Thu Jul 18 05:05:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IC5ARw026926 for ; Thu, 18 Jul 2002 05:05:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IC5ATT026925 for linux-xfs-outgoing; Thu, 18 Jul 2002 05:05:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta03.algx.net (chimta03.algx.net [216.99.233.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IC50Rw026880 for ; Thu, 18 Jul 2002 05:05:00 -0700 Received: from wiley.ceo.com (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx03.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GZG007I50BLNO@chimmx03.algx.net> for linux-xfs@oss.sgi.com; Thu, 18 Jul 2002 06:38:09 -0500 (CDT) Date: Thu, 18 Jul 2002 07:38:11 -0400 From: Danny Cox Subject: Re: Software RAID, a bit OT In-reply-to: To: Ben Gollmer Cc: XFS Mailing List Message-id: <1026992292.1150.8.camel@wiley> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7BIT References: X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ben, On Wed, 2002-07-17 at 14:20, Ben Gollmer wrote: > Hope you don't mind me asking this on-list, but I've gotten some very > helpful storage-related info from here in the past. I'm putting together a > server for a small group of developers; we have no real budget, so we're > trying to keep things cheap. Here's our hardware specs so far: > > 2x P3 700 MHz > 512 MB RAM > 2 Promise PCI ATA-133 controllers > 3 Seagate 80 GB HDDs > > This server is going to handle file sharing, e-mail, CVS, and a bug-tracking > database for us. Our project has some rather large files so we need a good > amount of storage space. I was planning to software RAID 5 the HDDs together > for a total of 160 GBs. I have been enjoying XFS on my workstation but I > know it has had problems with software RAID 5 in the past. Are these > problems fixed now? Since you say you're on a budget, I'd say look for a different (cheaper) IDE controller. In the hardware benchmarks (take all benchmarks with a large grain of salt, of course) I've seen, ATA-133 buys you little at the present time, even IF the drive supports it. The drives just aren't that fast yet. So, look for another controller, and go for the extra disk. The problem with XFS and RAID5 has to do with XFS writing in multiple block sizes, and how Linux RAID5 implements that. Steve has been working on it, and has made it better, but there's still more to do. It's better, but by how much, I can't say. Given that, pop for the extra disk, and implement a RAID 0+1. It should be a bit faster than RAID5, I think. The best way is to try it yourself, of course. Only you know what mix of software you'll be running. As others have noted, the 3ware controllers have been getting lots of praise on this list. Good luck, and let us know what you determine! -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Thu Jul 18 05:15:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ICFrRw028222 for ; Thu, 18 Jul 2002 05:15:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ICFrFZ028221 for linux-xfs-outgoing; Thu, 18 Jul 2002 05:15:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fruit.eu.org (qmailr@50dyn122.com21.casema.net [213.17.31.122]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ICF7Rw028191 for ; Thu, 18 Jul 2002 05:15:08 -0700 Received: (qmail 24231 invoked by uid 500); 18 Jul 2002 12:15:39 -0000 Date: Thu, 18 Jul 2002 14:15:38 +0200 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: mapcheck (more spiffy) Message-ID: <20020718121538.GR5929@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2+K7TauFN1Oc3ugB" Content-Disposition: inline User-Agent: Mutt/1.4i X-oi: oi X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --2+K7TauFN1Oc3ugB Content-Type: multipart/mixed; boundary="bE2XbrxqIoa/xW9+" Content-Disposition: inline --bE2XbrxqIoa/xW9+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline oi! I changed mapcheck.c a bit so it's a little less awkward to use. (attached) It now takes options, as follows: Usage: mapcheck [-afhnqvV] [file [...]] [dir [...]] -a, --all Fix all XFS filesystems -f, --force Force application -h, --help Display this message -n, --no-act Scan but don't change any files -q, --quiet Don't output anything except errors -v, --verbose Write verbose info to stdout -V, --version Write version to stdout HTH, HAND! -- Wessel Dankers --bE2XbrxqIoa/xW9+ Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="mapcheck.c" Content-Transfer-Encoding: quoted-printable /* This fixes up a filesystem which has bad data in the last block * of the file out beyond eof. This confuses some applications. * * Copyright Stephen Lord 2002, All Rights Reserved. */ #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif #include #include #include #include #include #include #include #include #include #include #include #include #include #define SCANDEPTH 42 int numfs =3D 32; char *fs =3D NULL; int verbose =3D 0, readonly =3D 0, quiet =3D 0, force =3D 0; int filecount =3D 0, fixedcount =3D 0, problemcount =3D 0; char *fixedmsg; static struct option options[] =3D { {"help", 0, 0, 'h'}, {"version", 0, 0, 'V'}, {"verbose", 0, 0, 'v'}, {"quiet", 0, 0, 'q'}, {"force", 0, 0, 'f'}, {"no-act", 0, 0, 'n'}, {"all", 0, 0, 'a'}, {0, 0, 0, 0} }; void *xalloc(void *m, size_t n) { m =3D realloc(m, n); if(!m) { perror("malloc()"); exit(2); } return m; } char *xstrdup(const char *s) { char *m; if(!s) s =3D ""; m =3D strdup(s); if(!m) { perror("malloc()"); exit(2); } return m; } static int checker( const char *file, const struct stat64 *st, int flag, struct FTW *_) { int fd, blk; char *ptr, *ptr2, *ptr3; off64_t off, len; if(flag !=3D FTW_F) return 0; blk =3D st->st_blksize; len =3D st->st_size % blk; off =3D st->st_size - len; filecount++; if(!len) return 0; fd =3D open(file, O_RDWR|O_LARGEFILE); if(fd < 0) { if(verbose) perror(file); return problemcount++, 0; } ptr =3D mmap64(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, off); close(fd); if(ptr =3D=3D MAP_FAILED) { if(verbose) perror(file); return problemcount++, 0; } ptr2 =3D ptr + len; ptr3 =3D ptr + blk; for(; ptr2 < ptr3; ptr2++) { if(*ptr2 !=3D 0) { if(verbose) printf("%s\n", file); if(!readonly) memset(ptr + len, 0, blk - len); fixedcount++; break; } } munmap(ptr, len); return 0; } =20 void catcher(int sig) { printf("\rInterrupted: %d files scanned %d files %s %d errors\n", filecount, fixedcount, fixedmsg, problemcount); exit(128+sig); } void printer(int sig) { printf("\r%d files scanned %d files %s %d errors\033[K\r", filecount, fixedcount, fixedmsg, problemcount); if(!readonly) sync(); alarm(1); } char *isbadfs(struct fstab *fs) { struct stat64 st; if(lstat64(fs->fs_file, &st)) return strerror(errno); if(!strcasecmp(fs->fs_type, "sw")) return "swap partition"; if(strcasecmp(fs->fs_vfstype, "xfs")) return "not an XFS filesystem"; if(!strcasecmp(fs->fs_type, "ro")) return "readonly filesystem"; if(!strcasecmp(fs->fs_type, "xx")) return "to be ignored"; return NULL; } char *isbadfile(char *f) { struct fstab *fs =3D NULL; char *s, *reason =3D NULL; if(!f || !*f) f =3D "."; s =3D xalloc(NULL, PATH_MAX); if(realpath(f, s)) { f =3D xalloc(s, strlen(s)+1); for(;;) { fs =3D getfsfile(f); if(fs) break; s =3D strrchr(f, '/'); if(!s) break; s[s =3D=3D f && s[1]] =3D '\0'; } } else { reason =3D strerror(errno); } free(f); if(reason) return reason; if(!fs) return "can't find the filesystem"; if(force) return NULL; return isbadfs(fs); } int main(int argc, char **argv) { int i, all =3D 0, stop =3D 0; FILE *fh; struct fstab *fs; char *reason; optind =3D 0; while((i =3D getopt_long(argc, argv, "afhnqvV", options, NULL)) !=3D EOF) { switch(i) { case 'a': all =3D 1; break; case 'n': readonly =3D 1; break; case 'q': quiet =3D 1; break; case 'v': verbose =3D 1; break; case 'V': printf("$Id:$\n"); stop =3D 1; break; default: i =3D i !=3D 'h'; fh =3D i ? stderr : stdout; stop =3D i + 1; if(!i) fprintf(fh, "mapcheck: a program to fix a very specific XFS problem.\n= "); fprintf(fh, "Usage: %s [-afhnqvV] [file [...]] [dir [...]]\n", argv[0]); fprintf(fh, " -a, --all Fix all XFS filesystems\n"); fprintf(fh, " -f, --force Force application\n"); fprintf(fh, " -h, --help Display this message\n"); fprintf(fh, " -n, --no-act Scan but don't change any files\n"); fprintf(fh, " -q, --quiet Don't output anything except errors= \n"); fprintf(fh, " -v, --verbose Write verbose info to stdout\n"); fprintf(fh, " -V, --version Write version to stdout\n"); } } if(stop) return stop - 1; setbuf(stdout, NULL); signal(SIGINT, catcher); fixedmsg =3D readonly ? "found" : "fixed"; if(!quiet) { signal(SIGALRM, printer); alarm(1); } if(all) { if(!setfsent()) return perror("reading fstab"), 2; while((fs =3D getfsent())) { if((reason =3D isbadfs(fs))) { if(verbose) fprintf(stderr, "Skipping %s %s: %s\n", fs->fs_spec, fs->fs_file, reason); } else { if(!quiet) fprintf(stderr, "Scanning %s\n", fs->fs_file); nftw64(fs->fs_file, checker, SCANDEPTH, FTW_MOUNT|FTW_PHYS); } } endfsent(); } else if(argc =3D=3D optind) { if((reason =3D isbadfile("."))) return fprintf(stderr, "Can't scan .: %s\n", reason), 1; if(!quiet) fprintf(stderr, "Scanning current directory\n"); nftw64(".", checker, SCANDEPTH, FTW_MOUNT|FTW_PHYS); } for(i =3D optind; i < argc; i++) { if((reason =3D isbadfile(argv[i]))) return fprintf(stderr, "Can't scan %s: %s\n", argv[i], reason), 1; nftw64(argv[i], checker, SCANDEPTH, FTW_MOUNT|FTW_PHYS); } if(!quiet) { alarm(0); printer(0); putchar('\n'); } return 0; } --bE2XbrxqIoa/xW9+-- --2+K7TauFN1Oc3ugB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9NrFqwSIMlSIEfyYRAhLOAJ9EKiO7avPkpMRvXwo7Dq+s0/nypwCdE3YF /fazfj2ydXBhpPEWPSRzsQ8= =oGt7 -----END PGP SIGNATURE----- --2+K7TauFN1Oc3ugB-- From owner-linux-xfs@oss.sgi.com Thu Jul 18 05:28:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ICSXRw028471 for ; Thu, 18 Jul 2002 05:28:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ICSXue028470 for linux-xfs-outgoing; Thu, 18 Jul 2002 05:28:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ICSMRw028441 for ; Thu, 18 Jul 2002 05:28:23 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6ICSsBT059648; Thu, 18 Jul 2002 14:28:54 +0200 (CEST) Message-Id: <4.3.2.7.2.20020718141404.03cdd1c0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Jul 2002 14:27:43 +0200 To: Danny Cox , Ben Gollmer From: Seth Mos Subject: Re: Software RAID, a bit OT Cc: XFS Mailing List In-Reply-To: <1026992292.1150.8.camel@wiley> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6ICSORw028442 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 07:38 18-7-2002 -0400, Danny Cox wrote: > Since you say you're on a budget, I'd say look for a different >(cheaper) IDE controller. In the hardware benchmarks (take all >benchmarks with a large grain of salt, of course) I've seen, ATA-133 >buys you little at the present time, even IF the drive supports it. The >drives just aren't that fast yet. I have had no real problems with the promise ata controllers. The fastrak raid controllers are a different story however. Other choices of ide controllers are the Highpoint or CMD controllers. > So, look for another controller, and go for the extra disk. I have a software raid 5 which has disks on a promise ata66 controller and no problems so far. I know they didn't and don't have really good driver support but the standard controllers seem to work right now. > The problem with XFS and RAID5 has to do with XFS writing in multiple >block sizes, and how Linux RAID5 implements that. Steve has been >working on it, and has made it better, but there's still more to do. >It's better, but by how much, I can't say. It's better and you can notice the difference. It's still nu up to par with "normal" disk access though. The recent changes that went in for smaller blocksize support and the alignment support for EVMS means that it is getting "close to completion"*. * Completion is a non existant term in a software development project and should be handled as such. > Given that, pop for the extra disk, and implement a RAID 0+1. It >should be a bit faster than RAID5, I think. Much faster then raid 5 but that is more by design then the other issues. Raid 5 has parity overhead and raid 10 has not. Read speeds of a raid 5 and a raid 10 should be rather close. The big difference is the write speed you can obtain. > As others have noted, the 3ware controllers have been getting lots of >praise on this list. 4 80GB disks of about €120,- = €480,- 1 3ware 7450 OEM = €600,- Getting a 3ware controller would mean more then doubling the price of your raid setup. You could get the 7410 if you are doing raid 10 which is €430,- but that would mean you can buy 4 more disks for the price of a single controller. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jul 18 05:32:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ICWoRw030526 for ; Thu, 18 Jul 2002 05:32:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ICWotu030525 for linux-xfs-outgoing; Thu, 18 Jul 2002 05:32:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ICWiRw030497 for ; Thu, 18 Jul 2002 05:32:45 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6ICXHGH082795; Thu, 18 Jul 2002 14:33:18 +0200 (CEST) Message-Id: <4.3.2.7.2.20020718143024.03c9de30@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Jul 2002 14:32:07 +0200 To: , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Plug-in FSIM for EVMS In-Reply-To: <4b5284eb63.4eb634b528@ono.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:50 18-7-2002 +0200, jm_garcia@ono.com wrote: >Hello, > >I like know if XFS will developer a plug-in for EVMS (FSIM). EVMS has >plugins for JFS, EXT3, REISERFS, etc... but not XFS. I believe there is work being done on that front. I remember that one of the EVMS developers has been working on getting the support working. I do not remember the current state of affairs. Maybe one of the others can comment on this. There have been posts on the mailinglist about EVMS so you could check the archives. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jul 18 05:40:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ICe0Rw030786 for ; Thu, 18 Jul 2002 05:40:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ICe0TS030785 for linux-xfs-outgoing; Thu, 18 Jul 2002 05:40:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ICdqRw030752 for ; Thu, 18 Jul 2002 05:39:52 -0700 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id IAA30779 for ; Thu, 18 Jul 2002 08:40:21 -0400 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id IAA08825 for ; Thu, 18 Jul 2002 08:39:51 -0400 Subject: Re: Shrink a Filesystem XFS From: Derek Glidden To: "linux-xfs@oss.sgi.com" In-Reply-To: <2c4702f960.2f9602c470@ono.com> References: <2c4702f960.2f9602c470@ono.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Jul 2002 08:39:51 -0400 Message-Id: <1026995991.24283.3.camel@two.nks.net> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-17 at 19:53, jm_garcia@ono.com wrote: > When will XFS support shrink a filesystems? Not natively. Your best bet is to build the system using LVM or EVMS or something that supports creating new logical partitions from physical devices, making a new partition smaller than your old one, copying all the data to the new partition, then recovering the space left over by the old partition. This is an old question (I think I might have been the first to bring it up a couple of years ago) and like Seth said, the early consensus was that the SGI folks would make better use of their time on core XFS functionality rather than an xfs_shrink utility that may be used by half a dozen people once or twice. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Thu Jul 18 06:23:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IDNXRw031448 for ; Thu, 18 Jul 2002 06:23:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IDNXd9031447 for linux-xfs-outgoing; Thu, 18 Jul 2002 06:23:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sundancer.oche.de (sundancer.oche.de [194.94.252.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IDNORw031419 for ; Thu, 18 Jul 2002 06:23:27 -0700 Received: by sundancer.oche.de (Postfix, from userid 10) id 9BEE655C31; Thu, 18 Jul 2002 15:23:54 +0200 (CEST) Received: (from martin@localhost) by foehn.quickstep.oche.de (8.9.3/8.6.12) id OAA29950; Thu, 18 Jul 2002 14:38:06 +0200 (CEST) Date: Thu, 18 Jul 2002 14:38:06 +0200 (CEST) Message-Id: <200207181238.OAA29950@foehn.quickstep.oche.de> From: Martin Spott To: linux-xfs@oss.sgi.com Subject: Re: re: Software RAID, a bit OT X-Newsgroups: list.linux-xfs In-Reply-To: Organization: home User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (SunOS/5.8 (sun4m)) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I am NOT a storage GURU, but I can vouch for the 3Ware 7850 > RAID controller. I have eight 120 gig Maxtors in a RAID5 configuration > mounted as one enormous 860 gig XFS partition. I'd second that: The 7850 is the fastest RAID controller I've ever seen in or attached to a PeeCee - even RAID5 is tremendously fast. Note that you need linux-2.4.18(-xfs-1.1) for arrays > 1 TByte (e.g. 8x Maxtor 160 GByte on RAID5), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Jul 18 07:11:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IEBlRw032382 for ; Thu, 18 Jul 2002 07:11:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IEBlUr032381 for linux-xfs-outgoing; Thu, 18 Jul 2002 07:11:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IEBfRw032353 for ; Thu, 18 Jul 2002 07:11:41 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA58582; Thu, 18 Jul 2002 09:12:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA59463; Thu, 18 Jul 2002 09:12:09 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6IE7GY05472; Thu, 18 Jul 2002 09:07:16 -0500 Subject: Re: Plug-in FSIM for EVMS From: Steve Lord To: jm_garcia@ono.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <4b5284eb63.4eb634b528@ono.com> References: <4b5284eb63.4eb634b528@ono.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Jul 2002 09:07:16 -0500 Message-Id: <1027001236.5457.2.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-07-18 at 06:50, jm_garcia@ono.com wrote: > Hello, > > I like know if XFS will developer a plug-in for EVMS (FSIM). EVMS has > plugins for JFS, EXT3, REISERFS, etc... but not XFS. > > Thank you. The EVMS developers were going to be doing this, I talked to them a few weeks ago in Ottawa, but have heard nothing since. You should ask on the EVMS mailing list. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jul 18 07:28:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IESLRw001104 for ; Thu, 18 Jul 2002 07:28:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IESLir001103 for linux-xfs-outgoing; Thu, 18 Jul 2002 07:28:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IES2Rw001075 for ; Thu, 18 Jul 2002 07:28:03 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id BE233C287; Thu, 18 Jul 2002 16:00:07 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id QAA27160; Thu, 18 Jul 2002 16:00:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 2C87157306; Thu, 18 Jul 2002 15:59:32 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 7E8F325835; Thu, 18 Jul 2002 15:59:31 +0200 (CEST) Message-ID: <3D36C9C3.BDFACE39@ch.sauter-bc.com> Date: Thu, 18 Jul 2002 15:59:31 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Ben Gollmer Cc: XFS Subject: Re: Software RAID, a bit OT References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ben Gollmer schrieb: > > Hi storage gurus! > > Hope you don't mind me asking this on-list, but I've gotten some very > helpful storage-related info from here in the past. I'm putting together a > server for a small group of developers; we have no real budget, so we're > trying to keep things cheap. Here's our hardware specs so far: > > 2x P3 700 MHz > 512 MB RAM > 2 Promise PCI ATA-133 controllers > 3 Seagate 80 GB HDDs I'm using Promise Ultra100TX2 controllers without any problem. I have software RAID5 on them with XFS, external log is on a separate software RAID1 on the same disks. I strongly recommend not using internal log with XFS on RAID5 although it should have much improved now. Simon > > This server is going to handle file sharing, e-mail, CVS, and a bug-tracking > database for us. Our project has some rather large files so we need a good > amount of storage space. I was planning to software RAID 5 the HDDs together > for a total of 160 GBs. I have been enjoying XFS on my workstation but I > know it has had problems with software RAID 5 in the past. Are these > problems fixed now? > > We also considered trying to grab another 80 GB drive from somewhere and do > a RAID 0+1 (still giving us 160 GBs storage) but I don't know if Linux > software RAID handles this well. > > Most of us run the -aa kernel tree on our workstations but I have no problem > running SGI CVS kernels on the server if they are reasonably stable. Any > input would be much appreciated :) > > Ben From owner-linux-xfs@oss.sgi.com Thu Jul 18 07:31:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IEViRw001293 for ; Thu, 18 Jul 2002 07:31:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IEVih3001292 for linux-xfs-outgoing; Thu, 18 Jul 2002 07:31:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IEVcRw001260 for ; Thu, 18 Jul 2002 07:31:39 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA61657; Thu, 18 Jul 2002 09:32:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA14638; Thu, 18 Jul 2002 09:32:07 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6IEREp05541; Thu, 18 Jul 2002 09:27:14 -0500 Subject: Re: Software RAID, a bit OT From: Steve Lord To: Simon Matter Cc: Ben Gollmer , XFS In-Reply-To: <3D36C9C3.BDFACE39@ch.sauter-bc.com> References: <3D36C9C3.BDFACE39@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Jul 2002 09:27:14 -0500 Message-Id: <1027002434.5457.26.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-07-18 at 08:59, Simon Matter wrote: > > I'm using Promise Ultra100TX2 controllers without any problem. I have > software RAID5 on them with XFS, external log is on a separate software > RAID1 on the same disks. I strongly recommend not using internal log > with XFS on RAID5 although it should have much improved now. > > Simon > It has improved, a lot, using the version 2 log with striping, however this is brand new code, and it needs soak time before we are completely sure about it. Please try it out, report problems, but probably do not move non-reproducible production data onto it yet. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jul 18 10:30:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IHUlRw004110 for ; Thu, 18 Jul 2002 10:30:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IHUlWe004109 for linux-xfs-outgoing; Thu, 18 Jul 2002 10:30:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IHUfRw004081 for ; Thu, 18 Jul 2002 10:30:41 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA47790 for ; Thu, 18 Jul 2002 12:31:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA82759 for ; Thu, 18 Jul 2002 12:31:11 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6IHQHl29960; Thu, 18 Jul 2002 12:26:17 -0500 Message-Id: <200207181726.g6IHQHl29960@jen.americas.sgi.com> Date: Thu, 18 Jul 2002 12:26:17 -0500 Subject: TAKE - do not pass sys_cred into mount/umount or sync To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More cleanup Date: Thu Jul 18 10:30:41 PDT 2002 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:123240a linux/fs/xfs/xfs_fsops.c - 1.82 linux/fs/xfs/linux/xfs_lrw.c - 1.160 linux/fs/xfs/linux/xfs_super.c - 1.192 From owner-linux-xfs@oss.sgi.com Thu Jul 18 10:36:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IHalRw004295 for ; Thu, 18 Jul 2002 10:36:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IHalOv004294 for linux-xfs-outgoing; Thu, 18 Jul 2002 10:36:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IHadRw004264 for ; Thu, 18 Jul 2002 10:36:39 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA66319 for ; Thu, 18 Jul 2002 12:37:09 -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 MAA14248 for ; Thu, 18 Jul 2002 12:37:09 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6IHZjg24404; Thu, 18 Jul 2002 12:35:45 -0500 Message-Id: <200207181735.g6IHZjg24404@stout.americas.sgi.com> Date: Thu, 18 Jul 2002 12:35:45 -0500 Subject: TAKE - update Designated initializer format X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Lately on LKML.... > these patches replace the (deprecated) > "foo: " designated initializers with the ISO-C ".foo =" initializers. > GCC has understood both since forever, but the kernel took a wrong > bet, and we're better off setting a good example for 2.6 before we > start getting about 10,000 warnings. It's the wave of the future... update Designated initializer format Date: Thu Jul 18 10:35:16 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123241a linux/fs/xfs/xfs_extfree_item.c - 1.49 linux/fs/xfs/xfs_buf_item.c - 1.124 linux/fs/xfs/xfs_vnodeops.c - 1.541 linux/fs/xfs/xfs_dir.c - 1.139 linux/fs/xfs/xfs_inode_item.c - 1.101 linux/fs/xfs/xfs_iocore.c - 1.35 linux/fs/xfs/xfs_dquot_item.c - 1.29 linux/fs/xfs/xfs_vfsops.c - 1.360 linux/fs/xfs/xfs_dir2.c - 1.36 linux/fs/xfs/linux/xfs_file.c - 1.74 linux/fs/xfs/linux/xfs_super.c - 1.193 linux/fs/xfs/linux/xfs_xattr.c - 1.18 From owner-linux-xfs@oss.sgi.com Thu Jul 18 11:26:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IIQqRw005529 for ; Thu, 18 Jul 2002 11:26:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IIQqQl005528 for linux-xfs-outgoing; Thu, 18 Jul 2002 11:26:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IIQlRw005490 for ; Thu, 18 Jul 2002 11:26:47 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA25271 for ; Thu, 18 Jul 2002 13:27:17 -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 NAA85849 for ; Thu, 18 Jul 2002 13:27:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6IIPrs24867; Thu, 18 Jul 2002 13:25:53 -0500 Message-Id: <200207181825.g6IIPrs24867@stout.americas.sgi.com> Date: Thu, 18 Jul 2002 13:25:53 -0500 Subject: TAKE - another log v2 mkfs tweak X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Automatically set v2 log if log sunit is specified Date: Thu Jul 18 11:25:04 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-testing The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:123258a cmd/xfsprogs/doc/CHANGES - 1.74 cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.11 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.32 From owner-linux-xfs@oss.sgi.com Thu Jul 18 11:32:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IIW1Rw005733 for ; Thu, 18 Jul 2002 11:32:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IIW1s3005732 for linux-xfs-outgoing; Thu, 18 Jul 2002 11:32:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IIUgRw005693 for ; Thu, 18 Jul 2002 11:30:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA64719 for ; Thu, 18 Jul 2002 13:31:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA26756 for ; Thu, 18 Jul 2002 13:31:12 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6IIQIY07957; Thu, 18 Jul 2002 13:26:18 -0500 Message-Id: <200207181826.g6IIQIY07957@jen.americas.sgi.com> Date: Thu, 18 Jul 2002 13:26:18 -0500 Subject: TAKE - merge up to 2.5.26 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mostly working, O_DIRECT does not read holes (not my fault), and loop devices on xfs are not recommended (possibly my fault). Steve Date: Thu Jul 18 11:27:43 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:123259a linux/include/linux/sunrpc/timer.h - 1.1 linux/drivers/acpi/tables/tbrsdt.c - 1.1 linux/drivers/acpi/toshiba_acpi.c - 1.1 linux/drivers/acpi/tables/tbgetall.c - 1.1 linux/include/linux/uinput.h - 1.1 linux/Documentation/input/amijoy.txt - 1.1 linux/Documentation/input/atarikbd.txt - 1.1 linux/Documentation/input/cd32.txt - 1.1 linux/drivers/acpi/include/amlresrc.h - 1.1 linux/Documentation/input/iforce-protocol.txt - 1.1 linux/drivers/input/joystick/iforce/Config.help - 1.1 linux/Documentation/input/interactive.fig - 1.1 linux/drivers/input/joystick/iforce/Config.in - 1.1 linux/drivers/input/joystick/joydump.c - 1.1 linux/Documentation/input/shape.fig - 1.1 linux/Documentation/input/xpad.txt - 1.1 linux/drivers/input/keyboard/newtonkbd.c - 1.1 linux/drivers/input/serio/i8042-io.h - 1.1 linux/drivers/input/serio/i8042-ppcio.h - 1.1 linux/drivers/input/serio/q40kbd.c - 1.1 linux/fs/direct-io.c - 1.1 linux/drivers/input/touchscreen/h3600_ts_input.c - 1.1 linux/drivers/input/uinput.c - 1.1 linux/include/asm-arm/suspend.h - 1.1 linux/drivers/usb/input/pid.c - 1.1 linux/drivers/usb/input/pid.h - 1.1 linux/drivers/usb/input/powermate.c - 1.1 linux/include/asm-arm/arch-sa1100/neponset.h - 1.1 linux/drivers/usb/input/xpad.c - 1.1 linux/arch/arm/mm/copypage-xscale.S - 1.1 linux/drivers/usb/input/hid-lgff.c - 1.1 linux/arch/arm/mm/abort-xscale.S - 1.1 linux/drivers/usb/input/hid-lg3dff.c - 1.1 linux/arch/arm/mm/abort-ev5tej.S - 1.1 linux/net/sunrpc/timer.c - 1.1 linux/drivers/usb/input/hid-ff.c - 1.1 linux/drivers/usb/input/fixp-arith.h - 1.1 linux/fs/smbfs/smbiod.c - 1.1 linux/fs/smbfs/request.h - 1.1 linux/fs/smbfs/request.c - 1.1 linux/net/unix/af_unix.c - 1.46 linux/net/sunrpc/xprt.c - 1.28 linux/net/sunrpc/xdr.c - 1.9 linux/net/sunrpc/sched.c - 1.30 linux/net/sunrpc/clnt.c - 1.18 linux/net/sunrpc/Makefile - 1.6 linux/net/netsyms.c - 1.48 linux/net/netlink/af_netlink.c - 1.19 linux/net/ipv4/tcp.c - 1.42 linux/net/core/dst.c - 1.9 linux/mm/slab.c - 1.36 linux/mm/mprotect.c - 1.29 linux/mm/mmap.c - 1.55 linux/mm/filemap.c - 1.126 linux/lib/vsprintf.c - 1.18 linux/kernel/softirq.c - 1.24 linux/kernel/sched.c - 1.75 linux/kernel/printk.c - 1.21 linux/kernel/panic.c - 1.17 linux/ipc/sem.c - 1.20 linux/ipc/msg.c - 1.13 linux/include/scsi/sg.h - 1.15 linux/include/net/tcp.h - 1.32 linux/include/linux/vt_kern.h - 1.7 linux/include/linux/sysrq.h - 1.7 linux/include/linux/sunrpc/xprt.h - 1.12 linux/include/linux/sunrpc/sched.h - 1.11 linux/include/linux/sunrpc/clnt.h - 1.9 linux/include/linux/smb_fs_sb.h - 1.8 linux/include/linux/sched.h - 1.76 linux/include/linux/notifier.h - 1.4 linux/include/linux/netlink.h - 1.9 linux/include/linux/fs.h - 1.183 linux/include/linux/console_struct.h - 1.5 linux/include/linux/blkdev.h - 1.62 linux/include/asm-sparc64/param.h - 1.4 linux/include/asm-sparc64/cache.h - 1.5 linux/include/asm-sparc/param.h - 1.4 linux/include/asm-sparc/cache.h - 1.4 linux/include/asm-ppc/machdep.h - 1.22 linux/include/asm-ppc/keyboard.h - 1.12 linux/include/asm-arm/system.h - 1.20 linux/include/asm-arm/procinfo.h - 1.10 linux/include/asm-arm/proc-armv/system.h - 1.14 linux/include/asm-arm/proc-armv/ptrace.h - 1.7 linux/include/asm-arm/proc-armv/pgtable.h - 1.17 linux/include/asm-arm/param.h - 1.7 linux/include/asm-arm/mmu_context.h - 1.12 linux/include/asm-arm/irq.h - 1.5 linux/include/asm-arm/arch-rpc/param.h - 1.4 linux/include/asm-arm/arch-nexuspci/param.h - 1.4 linux/include/asm-arm/arch-ebsa285/param.h - 1.4 linux/include/asm-arm/arch-ebsa110/param.h - 1.4 linux/include/asm-alpha/siginfo.h - 1.9 linux/fs/smbfs/sock.c - 1.14 linux/fs/smbfs/proc.c - 1.21 linux/fs/smbfs/ioctl.c - 1.10 linux/fs/smbfs/inode.c - 1.38 linux/fs/smbfs/file.c - 1.30 linux/fs/smbfs/Makefile - 1.9 linux/fs/pipe.c - 1.32 linux/fs/ntfs/super.c - 1.19 linux/fs/ntfs/inode.h - 1.9 linux/fs/ntfs/inode.c - 1.21 linux/fs/ntfs/dir.c - 1.16 linux/fs/ntfs/Makefile - 1.22 linux/fs/nfs/nfs3xdr.c - 1.11 linux/fs/nfs/nfs2xdr.c - 1.14 linux/fs/nfs/inode.c - 1.48 linux/fs/lockd/xdr.c - 1.14 linux/fs/ext2/inode.c - 1.50 linux/fs/dcache.c - 1.40 linux/fs/buffer.c - 1.127 linux/fs/block_dev.c - 1.51 linux/fs/affs/namei.c - 1.21 linux/fs/Makefile - 1.61 linux/fs/Config.in - 1.92 linux/drivers/video/Config.in - 1.37 linux/drivers/scsi/sg.c - 1.33 linux/drivers/scsi/seagate.c - 1.19 linux/drivers/scsi/pluto.c - 1.13 linux/drivers/scsi/ncr53c8xx.c - 1.26 linux/drivers/scsi/ide-scsi.c - 1.40 linux/drivers/sbus/char/Config.in - 1.8 linux/drivers/net/sunhme.c - 1.37 linux/drivers/net/ppp_deflate.c - 1.10 linux/drivers/net/eepro100.c - 1.46 linux/drivers/net/bsd_comp.c - 1.10 linux/drivers/net/3c509.c - 1.32 linux/drivers/fc4/fc.c - 1.11 linux/drivers/fc4/Config.in - 1.5 linux/drivers/char/tty_io.c - 1.47 linux/drivers/char/sysrq.c - 1.26 linux/drivers/char/serial.c - 1.60 linux/drivers/char/qpmouse.c - 1.14 linux/drivers/char/pc_keyb.c - 1.30 linux/drivers/char/pc110pad.h - 1.3 linux/drivers/char/pc110pad.c - 1.16 linux/drivers/char/msbusmouse.c - 1.10 linux/drivers/char/keyboard.c - 1.25 linux/drivers/char/ftape/Config.in - 1.6 linux/drivers/char/console.c - 1.29 linux/drivers/char/atixlmouse.c - 1.9 linux/drivers/char/amigamouse.c - 1.11 linux/drivers/char/adbmouse.c - 1.16 linux/drivers/char/Makefile - 1.65 linux/drivers/char/Config.in - 1.62 linux/drivers/cdrom/sonycd535.c - 1.24 linux/drivers/cdrom/aztcd.c - 1.22 linux/drivers/block/loop.c - 1.60 linux/drivers/block/ll_rw_blk.c - 1.108 linux/drivers/block/Config.in - 1.38 linux/drivers/acorn/scsi/Config.in - 1.5 linux/arch/sparc64/kernel/time.c - 1.21 linux/arch/sparc64/kernel/binfmt_elf32.c - 1.8 linux/arch/sparc64/defconfig - 1.70 linux/arch/ppc/kernel/setup.c - 1.46 linux/arch/ppc/config.in - 1.54 linux/arch/mips/config.in - 1.31 linux/arch/m68k/config.in - 1.30 linux/arch/i386/mm/ioremap.c - 1.16 linux/arch/i386/mm/init.c - 1.38 linux/arch/i386/kernel/smp.c - 1.48 linux/arch/i386/kernel/io_apic.c - 1.40 linux/arch/i386/kernel/apm.c - 1.49 linux/arch/i386/config.in - 1.84 linux/arch/i386/boot/compressed/misc.c - 1.15 linux/arch/arm/mm/fault-common.c - 1.23 linux/arch/arm/mm/fault-armv.c - 1.27 linux/arch/arm/mm/Makefile - 1.19 linux/arch/arm/lib/backtrace.S - 1.9 linux/arch/arm/kernel/traps.c - 1.29 linux/arch/arm/kernel/signal.c - 1.25 linux/arch/arm/kernel/ptrace.c - 1.19 linux/arch/arm/kernel/process.c - 1.29 linux/arch/arm/kernel/irq.c - 1.19 linux/arch/arm/kernel/entry-armv.S - 1.32 linux/arch/arm/config.in - 1.43 linux/arch/arm/Makefile - 1.31 linux/arch/alpha/kernel/signal.c - 1.16 linux/arch/alpha/config.in - 1.48 linux/Makefile - 1.208 linux/MAINTAINERS - 1.111 linux/Documentation/video4linux/bttv/README - 1.15 linux/Documentation/filesystems/ntfs.txt - 1.18 linux/Documentation/devices.txt - 1.12 linux/CREDITS - 1.83 linux/include/linux/ide.h - 1.55 linux/fs/hpfs/dir.c - 1.15 linux/arch/ppc/xmon/start.c - 1.19 linux/arch/arm/nwfpe/fpa11.c - 1.9 linux/drivers/sgi/Config.in - 1.5 linux/arch/mips/dec/wbflush.c - 1.6 linux/drivers/char/raw.c - 1.26 linux/drivers/char/logibusmouse.c - 1.8 linux/fs/partitions/msdos.c - 1.23 linux/fs/partitions/check.c - 1.45 linux/fs/partitions/Config.in - 1.18 linux/arch/i386/kernel/semaphore.c - 1.19 linux/arch/arm/vmlinux-armo.lds.in - 1.19 linux/arch/sh/config.in - 1.25 linux/drivers/scsi/ips.c - 1.27 linux/include/asm-m68k/mac_via.h - 1.2 linux/arch/ppc/kernel/m8xx_setup.c - 1.24 linux/drivers/net/wan/syncppp.c - 1.14 linux/include/asm-arm/arch-sa1100/serial.h - 1.5 linux/include/asm-arm/arch-sa1100/param.h - 1.3 linux/include/asm-arm/arch-arc/param.h - 1.2 linux/include/asm-sh/pgtable-2level.h - 1.8 linux/include/asm-arm/arch-cl7500/param.h - 1.3 linux/drivers/net/aironet4500_rid.c - 1.4 linux/Documentation/video4linux/bttv/CARDLIST - 1.14 linux/Documentation/video4linux/bttv/Insmod-options - 1.13 linux/include/linux/input.h - 1.18 linux/Documentation/usb/URB.txt - 1.5 linux/Documentation/usb/error-codes.txt - 1.7 linux/include/net/dsfield.h - 1.4 linux/drivers/ieee1394/raw1394.c - 1.18 linux/drivers/ieee1394/ieee1394_core.h - 1.12 linux/drivers/ieee1394/pcilynx.h - 1.9 linux/drivers/ieee1394/pcilynx.c - 1.21 linux/drivers/ieee1394/ieee1394_core.c - 1.20 linux/drivers/ieee1394/ohci1394.h - 1.15 linux/drivers/ieee1394/ohci1394.c - 1.22 linux/drivers/ieee1394/ieee1394_types.h - 1.14 linux/drivers/ieee1394/ieee1394_transactions.c - 1.11 linux/arch/i386/kernel/apic.c - 1.31 linux/drivers/ieee1394/hosts.h - 1.10 linux/drivers/ieee1394/hosts.c - 1.12 linux/arch/i386/kernel/mpparse.c - 1.23 linux/drivers/ieee1394/Config.in - 1.8 linux/drivers/ieee1394/Makefile - 1.14 linux/kernel/pm.c - 1.11 linux/include/linux/raid/md_k.h - 1.24 linux/fs/lockd/xdr4.c - 1.9 linux/drivers/net/bonding.c - 1.11 linux/include/linux/brlock.h - 1.8 linux/include/linux/usb.h - 1.41 linux/drivers/ide/via82cxxx.c - 1.31 linux/drivers/ide/trm290.c - 1.13 linux/drivers/ide/sl82c105.c - 1.14 linux/drivers/ide/sis5513.c - 1.22 linux/drivers/ide/piix.c - 1.27 linux/drivers/ide/pdc4030.c - 1.19 linux/drivers/ide/pdc202xx.c - 1.25 linux/drivers/ide/ns87415.c - 1.12 linux/drivers/ide/ide.c - 1.58 linux/drivers/ide/ide-tape.c - 1.30 linux/drivers/ide/ide-pmac.c - 1.18 linux/drivers/ide/ide-pci.c - 1.30 linux/drivers/ide/ide-floppy.c - 1.28 linux/drivers/ide/ide-disk.c - 1.40 linux/drivers/ide/ide-cd.c - 1.40 linux/drivers/ide/icside.c - 1.20 linux/drivers/ide/hpt366.c - 1.22 linux/drivers/ide/hpt34x.c - 1.16 linux/drivers/ide/cy82c693.c - 1.14 linux/drivers/ide/cs5530.c - 1.12 linux/drivers/ide/cmd64x.c - 1.18 linux/drivers/ide/alim15x3.c - 1.19 linux/drivers/ide/Config.in - 1.29 linux/Documentation/DocBook/kernel-api.tmpl - 1.19 linux/net/ipv4/netfilter/ip_tables.c - 1.15 linux/include/linux/usbdevice_fs.h - 1.9 linux/include/linux/nfs_xdr.h - 1.7 linux/include/asm-arm/arch-shark/system.h - 1.7 linux/include/asm-arm/arch-shark/param.h - 1.5 linux/fs/ramfs/inode.c - 1.27 linux/drivers/usb/serial/visor.c - 1.36 linux/drivers/ide/aec62xx.c - 1.12 linux/arch/ppc/kernel/m8260_setup.c - 1.15 linux/include/asm-arm/arch-l7200/param.h - 1.3 linux/fs/xfs/xfs_bit.c - 1.19 linux/fs/xfs/linux/xfs_iops.c - 1.168 linux/kdb/kdbmain.c - 1.31 linux/drivers/usb/storage/usb.h - 1.14 linux/drivers/usb/storage/usb.c - 1.24 linux/drivers/usb/storage/transport.c - 1.24 linux/drivers/usb/storage/scsiglue.c - 1.23 linux/drivers/acpi/tables/tbxface.c - 1.11 linux/drivers/acpi/tables/tbutils.c - 1.12 linux/drivers/acpi/tables/tbinstal.c - 1.11 linux/drivers/acpi/tables/tbget.c - 1.11 linux/drivers/acpi/resources/rslist.c - 1.10 linux/drivers/acpi/resources/rsirq.c - 1.9 linux/drivers/acpi/resources/rsio.c - 1.9 linux/drivers/acpi/resources/rscreate.c - 1.11 linux/drivers/acpi/parser/psxface.c - 1.11 linux/drivers/acpi/parser/psutils.c - 1.11 linux/drivers/acpi/parser/psparse.c - 1.12 linux/arch/arm/kernel/ptrace.h - 1.3 linux/drivers/acpi/namespace/nsnames.c - 1.11 linux/drivers/acpi/namespace/nsload.c - 1.10 linux/drivers/acpi/namespace/nseval.c - 1.13 linux/arch/arm/mm/proc-arm720.S - 1.14 linux/drivers/acpi/include/actypes.h - 1.13 linux/drivers/acpi/include/actables.h - 1.11 linux/drivers/acpi/include/acpixf.h - 1.13 linux/drivers/acpi/ec.c - 1.9 linux/drivers/acpi/dispatcher/dswload.c - 1.11 linux/drivers/acpi/dispatcher/dsobject.c - 1.13 linux/drivers/acpi/dispatcher/dsmethod.c - 1.11 linux/drivers/acpi/Makefile - 1.16 linux/include/asm-arm/arch-sa1100/assabet.h - 1.10 linux/drivers/ieee1394/video1394.c - 1.20 linux/include/linux/gameport.h - 1.7 linux/include/linux/serio.h - 1.5 linux/drivers/media/video/tvmixer.c - 1.9 linux/drivers/media/video/tuner.h - 1.8 linux/drivers/media/video/tuner.c - 1.11 linux/drivers/media/video/pms.c - 1.9 linux/drivers/media/video/msp3400.c - 1.11 linux/drivers/media/video/bttv-driver.c - 1.22 linux/drivers/media/video/bttv-cards.c - 1.13 linux/drivers/input/Makefile - 1.7 linux/drivers/input/Config.in - 1.5 linux/arch/arm/tools/mach-types - 1.17 linux/arch/arm/mach-footbridge/personal-pci.c - 1.5 linux/arch/arm/mm/proc-arm920.S - 1.11 linux/arch/i386/kernel/bluesmoke.c - 1.23 linux/drivers/acpi/include/acconfig.h - 1.13 linux/drivers/acpi/include/acdebug.h - 1.11 linux/drivers/acpi/include/acglobal.h - 1.10 linux/drivers/acpi/include/aclocal.h - 1.12 linux/drivers/acpi/include/acparser.h - 1.8 linux/drivers/acpi/include/actbl.h - 1.8 linux/drivers/macintosh/adbhid.c - 1.5 linux/drivers/macintosh/mac_hid.c - 1.4 linux/include/asm-arm/arch-tbox/param.h - 1.2 linux/drivers/media/video/tvaudio.c - 1.10 linux/drivers/media/video/bttvp.h - 1.8 linux/Documentation/SubmittingPatches - 1.2 linux/arch/arm/def-configs/neponset - 1.8 linux/drivers/usb/serial/empeg.c - 1.25 linux/include/asm-parisc/semaphore.h - 1.4 linux/arch/parisc/config.in - 1.7 linux/drivers/acpi/tables/tbconvrt.c - 1.9 linux/drivers/acpi/tables/tbxfroot.c - 1.9 linux/drivers/acpi/power.c - 1.5 linux/fs/reiserfs/stree.c - 1.26 linux/fs/reiserfs/super.c - 1.26 linux/drivers/acpi/acpi_ksyms.c - 1.8 linux/fs/reiserfs/ibalance.c - 1.10 linux/fs/reiserfs/fix_node.c - 1.24 linux/fs/reiserfs/do_balan.c - 1.13 linux/fs/reiserfs/buffer2.c - 1.14 linux/include/linux/reiserfs_fs.h - 1.28 linux/fs/reiserfs/Makefile - 1.8 linux/arch/cris/drivers/ide.c - 1.16 linux/arch/cris/kernel/signal.c - 1.9 linux/include/asm-cris/siginfo.h - 1.5 linux/include/asm-cris/pgtable.h - 1.10 linux/include/asm-arm/arch-integrator/param.h - 1.2 linux/drivers/usb/serial/io_edgeport.c - 1.26 linux/drivers/scsi/aic7xxx_old.c - 1.18 linux/arch/arm/mach-integrator/arch.c - 1.5 linux/drivers/net/irda/irda-usb.c - 1.20 linux/drivers/bluetooth/hci_usb.c - 1.9 linux/drivers/mtd/maps/Config.in - 1.5 linux/drivers/acpi/executer/exstore.c - 1.8 linux/drivers/acpi/utilities/utxface.c - 1.6 linux/drivers/acpi/utilities/utglobal.c - 1.8 linux/drivers/acpi/utilities/utcopy.c - 1.8 linux/drivers/acpi/Config.in - 1.5 linux/drivers/net/wireless/airo.c - 1.17 linux/drivers/acpi/include/platform/aclinux.h - 1.7 linux/drivers/acpi/debugger/dbdisasm.c - 1.6 linux/drivers/acpi/debugger/dbdisply.c - 1.8 linux/drivers/acpi/debugger/dbexec.c - 1.5 linux/drivers/acpi/debugger/dbfileio.c - 1.7 linux/drivers/acpi/executer/exconfig.c - 1.8 linux/drivers/acpi/executer/exdump.c - 1.8 linux/drivers/acpi/executer/exmisc.c - 1.7 linux/drivers/acpi/executer/exresnte.c - 1.9 linux/drivers/acpi/executer/exresolv.c - 1.8 linux/drivers/acpi/executer/exresop.c - 1.8 linux/arch/mips64/math-emu/ieee754.c - 1.2 linux/Documentation/video4linux/meye.txt - 1.4 linux/drivers/ieee1394/sbp2.c - 1.8 linux/drivers/ieee1394/sbp2.h - 1.7 linux/drivers/ieee1394/nodemgr.c - 1.10 linux/include/asm-arm/arch-sa1100/pfs168.h - 1.2 linux/drivers/ide/serverworks.c - 1.14 linux/drivers/ide/it8172.c - 1.10 linux/drivers/ide/amd74xx.c - 1.14 linux/arch/arm/mach-sa1100/xp860.c - 1.8 linux/arch/arm/mach-sa1100/sa1111.c - 1.7 linux/include/asm-arm/arch-anakin/param.h - 1.2 linux/arch/arm/mach-integrator/cpu.c - 1.4 linux/arch/arm/mach-sa1100/irq.c - 1.6 linux/include/asm-arm/mach/serial_sa1100.h - 1.4 linux/arch/arm/mach-sa1100/assabet.c - 1.10 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.3 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.5 linux/arch/arm/mach-sa1100/generic.c - 1.7 linux/Documentation/input/ff.txt - 1.2 linux/Documentation/input/input.txt - 1.2 linux/Documentation/input/joystick-parport.txt - 1.2 linux/Documentation/input/joystick.txt - 1.2 linux/Documentation/usb/hiddev.txt - 1.3 linux/include/linux/hiddev.h - 1.4 linux/fs/smbfs/proto.h - 1.5 linux/drivers/mtd/devices/blkmtd.c - 1.11 linux/drivers/usb/serial/ir-usb.c - 1.16 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.11 linux/arch/arm/mach-sa1100/adsbitsy.c - 1.9 linux/Documentation/video4linux/bttv/Tuners - 1.2 linux/Documentation/video4linux/bttv/Cards - 1.3 linux/drivers/acpi/executer/exoparg2.c - 1.6 linux/drivers/acpi/executer/exoparg1.c - 1.6 linux/include/asm-arm/arch-epxa10db/param.h - 1.2 linux/arch/arm/mach-sa1100/pm.c - 1.6 linux/arch/arm/mach-sa1100/sleep.S - 1.5 linux/include/linux/if_vlan.h - 1.3 linux/arch/arm/mm/proc-arm1020.S - 1.7 linux/arch/arm/mm/proc-arm926.S - 1.7 linux/fs/driverfs/inode.c - 1.16 linux/include/linux/namespace.h - 1.4 linux/drivers/usb/serial/kl5kusb105.c - 1.9 linux/arch/arm/mm/proc-xscale.S - 1.7 linux/arch/arm/mm/proc-arm922.S - 1.6 linux/arch/arm/mach-sa1100/system3.c - 1.9 linux/arch/arm/mach-sa1100/shannon.c - 1.2 linux/include/asm-arm/hardware/sa1111.h - 1.4 linux/include/asm-arm/arch-adifcc/param.h - 1.2 linux/include/asm-arm/arch-iop310/param.h - 1.2 linux/arch/arm/mach-iop310/iq80310-pci.c - 1.3 linux/include/asm-arm/arch-clps711x/param.h - 1.2 linux/arch/arm/mach-arc/small_page.c - 1.3 linux/drivers/ide/ide-taskfile.c - 1.17 linux/drivers/ieee1394/dv1394-private.h - 1.3 linux/drivers/ieee1394/dv1394.c - 1.5 linux/drivers/ieee1394/dv1394.h - 1.2 linux/arch/ppc/Config.help - 1.10 linux/drivers/acpi/Config.help - 1.4 linux/drivers/char/Config.help - 1.6 linux/drivers/input/Config.help - 1.4 linux/drivers/input/joystick/Makefile - 1.4 linux/drivers/input/joystick/Config.in - 1.3 linux/drivers/input/joystick/Config.help - 1.3 linux/drivers/input/gameport/Config.in - 1.3 linux/drivers/input/serio/Config.in - 1.3 linux/drivers/input/serio/Makefile - 1.4 linux/drivers/input/serio/serio.c - 1.3 linux/drivers/input/serio/serport.c - 1.3 linux/arch/ppc/4xx_io/stb_kb.c - 1.3 linux/sound/pci/cs46xx/cs46xx.c - 1.9 linux/sound/oss/trident.h - 1.2 linux/sound/oss/trident.c - 1.4 linux/sound/oss/sb_audio.c - 1.3 linux/sound/oss/mad16.c - 1.3 linux/sound/oss/es1371.c - 1.3 linux/sound/oss/es1370.c - 1.4 linux/arch/ppc/kernel/ppc4xx_setup.c - 1.5 linux/arch/ppc/platforms/apus_setup.c - 1.2 linux/arch/ppc/platforms/chrp_setup.c - 1.7 linux/arch/ppc/platforms/gemini_setup.c - 1.3 linux/arch/ppc/platforms/iSeries_setup.c - 1.3 linux/arch/ppc/platforms/oak_setup.c - 1.2 linux/arch/ppc/platforms/pmac_setup.c - 1.5 linux/arch/ppc/platforms/pplus_setup.c - 1.5 linux/arch/ppc/platforms/prep_setup.c - 1.7 linux/arch/ppc/platforms/sandpoint_setup.c - 1.5 linux/arch/ppc/platforms/spruce_setup.c - 1.3 linux/sound/oss/btaudio.c - 1.4 linux/sound/oss/ad1848.c - 1.2 linux/sound/oss/Config.in - 1.3 linux/arch/ppc64/kernel/pSeries_pci.c - 1.4 linux/arch/ppc64/xmon/start.c - 1.3 linux/arch/arm/mm/copypage-v5te.S - 1.3 linux/fs/jfs/jfs_debug.c - 1.4 linux/fs/jfs/jfs_debug.h - 1.4 linux/arch/arm/mm/abort-lv4t.S - 1.4 linux/arch/arm/mm/abort-ev5ej.S - 1.4 linux/arch/arm/mm/abort-ev4t.S - 1.3 linux/arch/arm/mm/abort-ev4.S - 1.3 linux/fs/jfs/jfs_logmgr.c - 1.11 linux/fs/jfs/super.c - 1.9 linux/include/asm-arm/glue.h - 1.4 linux/fs/jfs/jfs_txnmgr.c - 1.9 linux/fs/quota_v2.c - 1.5 linux/drivers/net/tg3.h - 1.7 linux/drivers/net/tg3.c - 1.7 linux/kernel/futex.c - 1.5 linux/mm/msync.c - 1.5 linux/arch/ia64/sn/fakeprom/README - 1.2 linux/drivers/media/video/video-buf.h - 1.2 linux/Documentation/video4linux/bttv/README.freeze - 1.3 linux/drivers/media/video/video-buf.c - 1.3 linux/drivers/acpi/acpi_bus.h - 1.4 linux/drivers/acpi/acpi_drivers.h - 1.5 linux/drivers/ide/ata-timing.c - 1.4 linux/drivers/ide/ata-timing.h - 1.5 linux/drivers/media/video/bttv-vbi.c - 1.3 linux/drivers/usb/class/bluetty.c - 1.5 linux/drivers/usb/input/Config.help - 1.3 linux/drivers/usb/class/cdc-acm.c - 1.5 linux/drivers/usb/core/devio.c - 1.5 linux/drivers/usb/core/hcd.c - 1.6 linux/drivers/usb/core/hub.c - 1.5 linux/drivers/usb/core/inode.c - 1.5 linux/drivers/usb/input/hid-core.c - 1.4 linux/drivers/usb/core/usb.c - 1.9 linux/drivers/usb/host/Makefile - 1.6 linux/drivers/usb/host/ehci-q.c - 1.6 linux/drivers/usb/host/ohci-dbg.c - 1.5 linux/drivers/usb/host/ohci-hcd.c - 1.8 linux/drivers/usb/host/ohci-q.c - 1.6 linux/drivers/usb/host/ohci.h - 1.5 linux/drivers/usb/host/uhci-debug.h - 1.2 linux/drivers/usb/media/stv680.c - 1.5 linux/drivers/usb/host/uhci.c - 1.6 linux/drivers/usb/host/uhci.h - 1.3 linux/drivers/usb/host/usb-uhci-debug.h - 1.2 linux/drivers/usb/host/usb-uhci.c - 1.5 linux/drivers/usb/host/usb-uhci.h - 1.2 linux/drivers/usb/input/Config.in - 1.4 linux/drivers/usb/input/Makefile - 1.5 linux/drivers/ieee1394/amdtp.c - 1.2 linux/drivers/usb/input/hid-debug.h - 1.2 linux/drivers/usb/input/hid-input.c - 1.2 linux/drivers/usb/input/hid.h - 1.2 linux/drivers/usb/input/hiddev.c - 1.6 linux/kernel/platform.c - 1.2 linux/drivers/usb/media/se401.c - 1.5 linux/drivers/usb/net/usbnet.c - 1.7 linux/drivers/usb/misc/emi26.c - 1.3 linux/drivers/usb/misc/tiglusb.c - 1.4 linux/drivers/isdn/hisax/Config.in - 1.5 linux/include/asm-arm/cacheflush.h - 1.2 linux/fs/ntfs/attrib.c - 1.6 linux/fs/ntfs/volume.h - 1.5 linux/fs/ntfs/compress.c - 1.6 linux/fs/ntfs/file.c - 1.3 linux/fs/ntfs/ntfs.h - 1.5 linux/fs/ntfs/mft.c - 1.5 linux/fs/ntfs/ChangeLog - 1.6 linux/fs/ntfs/aops.c - 1.6 linux/drivers/ide/tcq.c - 1.8 linux/drivers/usb/host/uhci-hcd.c - 1.5 linux/drivers/ide/pcihost.h - 1.4 linux/drivers/ide/pcidma.c - 1.7 linux/drivers/usb/host/usb-uhci-dbg.c - 1.3 linux/drivers/usb/host/usb-uhci-hcd.c - 1.4 linux/drivers/usb/host/usb-uhci-hcd.h - 1.2 linux/drivers/pci/probe.c - 1.3 linux/drivers/usb/host/usb-uhci-hub.c - 1.3 linux/drivers/usb/host/usb-uhci-mem.c - 1.3 linux/drivers/usb/host/usb-uhci-q.c - 1.4 linux/include/linux/buffer_head.h - 1.7 linux/include/asm-i386/suspend.h - 1.3 linux/kernel/suspend.c - 1.7 linux/drivers/ide/ioctl.c - 1.7 linux/drivers/ide/main.c - 1.4 linux/include/linux/atapi.h - 1.3 linux/drivers/ide/probe.c - 1.6 linux/include/linux/suspend.h - 1.4 linux/drivers/usb/core/urb.c - 1.3 linux/drivers/usb/core/message.c - 1.4 linux/drivers/acpi/battery.c - 1.2 linux/drivers/acpi/bus.c - 1.3 linux/drivers/acpi/pci_root.c - 1.3 linux/drivers/acpi/pci_link.c - 1.2 linux/drivers/acpi/pci_irq.c - 1.3 linux/drivers/acpi/thermal.c - 1.2 linux/drivers/acpi/system.c - 1.4 linux/drivers/acpi/processor.c - 1.4 linux/drivers/ide/device.c - 1.4 linux/drivers/acpi/osl.c - 1.3 linux/drivers/acpi/utils.c - 1.3 linux/drivers/usb/host/ohci-sa1111.c - 1.2 linux/arch/i386/kernel/suspend.c - 1.3 linux/arch/i386/kernel/cpu/intel.c - 1.2 linux/arch/i386/kernel/cpu/common.c - 1.2 linux/arch/arm/mm/proc-arm6_7.S - 1.2 linux/drivers/input/joystick/iforce/iforce.h - 1.2 linux/drivers/input/keyboard/atkbd.c - 1.2 linux/drivers/input/touchscreen/Makefile - 1.2 linux/drivers/input/touchscreen/Config.in - 1.2 linux/drivers/input/touchscreen/Config.help - 1.2 linux/drivers/input/serio/rpckbd.c - 1.2 linux/drivers/input/serio/parkbd.c - 1.2 linux/drivers/input/serio/i8042.h - 1.2 linux/drivers/input/serio/i8042.c - 1.2 linux/drivers/input/serio/ct82c710.c - 1.2 linux/drivers/input/evbug.c - 1.2 linux/drivers/input/mouse/rpcmouse.c - 1.2 linux/drivers/input/mouse/psmouse.c - 1.2 linux/drivers/input/joystick/iforce/Makefile - 1.2 linux/drivers/input/mouse/amimouse.c - 1.2 linux/drivers/input/joystick/iforce/iforce-main.c - 1.2 linux/drivers/input/joystick/iforce/iforce-packets.c - 1.2 linux/drivers/input/keyboard/Makefile - 1.2 linux/drivers/input/keyboard/Config.in - 1.2 linux/drivers/input/keyboard/Config.help - 1.2 From owner-linux-xfs@oss.sgi.com Thu Jul 18 12:03:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IJ3iRw006158 for ; Thu, 18 Jul 2002 12:03:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IJ3iOb006157 for linux-xfs-outgoing; Thu, 18 Jul 2002 12:03:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IJ3bRw006129 for ; Thu, 18 Jul 2002 12:03:38 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA70190 for ; Thu, 18 Jul 2002 14:04:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA44561 for ; Thu, 18 Jul 2002 14:04:07 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6IIxDq10068; Thu, 18 Jul 2002 13:59:13 -0500 Message-Id: <200207181859.g6IIxDq10068@jen.americas.sgi.com> Date: Thu, 18 Jul 2002 13:59:13 -0500 Subject: TAKE - remove linux/behavior.h and linux/vnode.h To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jul 18 12:02:32 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:123266a linux/fs/xfs/linux/xfs_linux.h - 1.81 linux/include/linux/behavior.h - 1.5 linux/include/linux/vnode.h - 1.10 linux/fs/xfs/linux/xfs_vnode.h - 1.53 linux/fs/xfs/linux/xfs_behavior.h - 1.8 From owner-linux-xfs@oss.sgi.com Thu Jul 18 13:02:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IK2JRw007021 for ; Thu, 18 Jul 2002 13:02:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IK2JoX007018 for linux-xfs-outgoing; Thu, 18 Jul 2002 13:02:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dc1.oscardom.de (oscar2.koeln.kkf.net [62.8.190.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IK2CRw006989 for ; Thu, 18 Jul 2002 13:02:13 -0700 Received: by dc1.oscardom.de with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jul 2002 22:02:48 +0200 Message-ID: <137CC1768083D411B4840008C7339FEE025CBB@dc1.oscardom.de> From: Stephan Boldt To: "'linux-xfs@oss.sgi.com'" Subject: ACL problems Date: Thu, 18 Jul 2002 22:02:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I just installed the xfs 1.1: I patched the original kernel 2.4.18, enabled all new xfs features, compiled and installed it. Then I created a new xfs fs with makefs.xfs an mounted it on /vol/aclpart When I wanted to test the acl-feature the following errors occured: [root@ws1 /vol/aclpart] ls . .. rute.pdf data [root@ws1 /vol/aclpart] chacl u:bolst:rwx rute.pdf chacl: u:bolst:rwx - Invalid argument [root@ws1 /vol/aclpart] chacl u::rwx rute.pdf chacl: access ACL 'u::rwx': Missing or wrong entry at entry 1 Have you got any idea what's going wrong? greets Stephan From owner-linux-xfs@oss.sgi.com Thu Jul 18 13:51:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IKpLRw008653 for ; Thu, 18 Jul 2002 13:51:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IKpLkG008652 for linux-xfs-outgoing; Thu, 18 Jul 2002 13:51:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cogent.jatosoft.com ([216.170.207.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IKpERw008624 for ; Thu, 18 Jul 2002 13:51:14 -0700 Received: from funk-bomb.jatosoft.com (unknown [216.170.207.50]) by cogent.jatosoft.com (Postfix) with ESMTP id 9F3E68004E2 for ; Thu, 18 Jul 2002 15:35:55 -0500 (CDT) Content-Type: text/plain; charset="iso-8859-1" From: Ben Gollmer Organization: Jatosoft LLC To: XFS Subject: Re: Software RAID, a bit OT Date: Thu, 18 Jul 2002 15:51:49 -0500 User-Agent: KMail/1.4.2 References: <3D36C9C3.BDFACE39@ch.sauter-bc.com> <1027002434.5457.26.camel@jen.americas.sgi.com> In-Reply-To: <1027002434.5457.26.camel@jen.americas.sgi.com> MIME-Version: 1.0 Message-Id: <200207181551.49007.ben@jatosoft.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6IKpFRw008625 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Everyone: Thanks for all your input. I'm going to stick with the Promise ATA-133 controllers, as they are only $30 at www.newegg.com. Also I am using software RAID, the 3ware controllers that I looked at were hardware RAID only and too expensive - I'd rather have more storage space. I'm planning to use RAID 0+1 with XFS on kernel 2.4.18 (or 2.4.19 if it's out by the time our disks come in). If there's any other good patches that you'd recommend for a server, let me know - I'm currently in the habit of running mostly vanilla kernels on my servers (except for XFS of course ;). Quick question for anyone with Linux software RAID experience: our RAID 0 will be composed of two RAID 1s, md0 and md1. if we decide we need more storage, is it easy to create another RAID 1 (md2) and add it to the stripe set? Or would that require something like LVM (or even a re-format)? Thanks again, Ben From owner-linux-xfs@oss.sgi.com Thu Jul 18 14:23:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ILNuRw009035 for ; Thu, 18 Jul 2002 14:23:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ILNu5Y009034 for linux-xfs-outgoing; Thu, 18 Jul 2002 14:23:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ILNnRw009006 for ; Thu, 18 Jul 2002 14:23:50 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA65301 for ; Thu, 18 Jul 2002 16:24:20 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA73309 for ; Thu, 18 Jul 2002 16:24:20 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA48769 for linux-xfs@oss.sgi.com; Thu, 18 Jul 2002 16:24:20 -0500 (CDT) Date: Thu, 18 Jul 2002 16:24:20 -0500 (CDT) From: Dean Roehrich Message-Id: <200207182124.QAA48769@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi: remove bhv pointer from dm_tokdata_t X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove bhv pointer from dm_tokdata_t and any remaining references to it. Date: Thu Jul 18 14:24:05 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123291a linux/fs/xfs_dmapi/xfsjunk.c - 1.12 - no longer need bhv_base_unlocked(). linux/fs/xfs_dmapi/dmapi_right.c - 1.12 linux/fs/xfs_dmapi/dmapi_private.h - 1.15 linux/fs/xfs_dmapi/dmapi_event.c - 1.9 - No Message Supplied From owner-linux-xfs@oss.sgi.com Thu Jul 18 15:43:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IMhmRw009680 for ; Thu, 18 Jul 2002 15:43:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IMhl9V009679 for linux-xfs-outgoing; Thu, 18 Jul 2002 15:43:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IMhgRw009651 for ; Thu, 18 Jul 2002 15:43:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA70676 for ; Thu, 18 Jul 2002 17:44:13 -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 RAA27725 for ; Thu, 18 Jul 2002 17:44:13 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6IMglm01873; Thu, 18 Jul 2002 17:42:47 -0500 Message-Id: <200207182242.g6IMglm01873@stout.americas.sgi.com> Date: Thu, 18 Jul 2002 17:42:47 -0500 Subject: TAKE - Use major() instead of MAJOR() X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another from christoph. Use major() instead of MAJOR() to keep in sync with 2.5 Date: Thu Jul 18 15:43:46 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123310a linux/fs/xfs/pagebuf/page_buf_locking.c - 1.19 From owner-linux-xfs@oss.sgi.com Thu Jul 18 16:12:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6INCkRw010366 for ; Thu, 18 Jul 2002 16:12:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6INCksV010365 for linux-xfs-outgoing; Thu, 18 Jul 2002 16:12:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6INCfRw010337 for ; Thu, 18 Jul 2002 16:12:41 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 QAA03097 for ; Thu, 18 Jul 2002 16:13:16 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06058; Fri, 19 Jul 2002 09:11:57 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) with ESMTP id g6INAL4U001032; Fri, 19 Jul 2002 09:10:21 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-4) id g6INAKGI001030; Fri, 19 Jul 2002 09:10:20 +1000 Date: Fri, 19 Jul 2002 09:10:20 +1000 From: Nathan Scott To: Stephan Boldt Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: ACL problems Message-ID: <20020718231020.GA453@frodo> References: <137CC1768083D411B4840008C7339FEE025CBB@dc1.oscardom.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <137CC1768083D411B4840008C7339FEE025CBB@dc1.oscardom.de> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jul 18, 2002 at 10:02:39PM +0200, Stephan Boldt wrote: > ... > [root@ws1 /vol/aclpart] ls > . .. rute.pdf data > [root@ws1 /vol/aclpart] chacl u:bolst:rwx rute.pdf > chacl: u:bolst:rwx - Invalid argument > [root@ws1 /vol/aclpart] chacl u::rwx rute.pdf > chacl: access ACL 'u::rwx': Missing or wrong entry at entry 1 > > Have you got any idea what's going wrong? Yes, chacl doesn't accept partial ACLs. You need to pass at least a "minimum ACL" for chacl to grok it - see the examples section of the chacl(1) man page. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jul 18 23:47:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6J6l8Rw015711 for ; Thu, 18 Jul 2002 23:47:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6J6l8Fh015710 for linux-xfs-outgoing; Thu, 18 Jul 2002 23:47:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6J6ksRw015682 for ; Thu, 18 Jul 2002 23:46:55 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 68C53C2A3; Fri, 19 Jul 2002 08:47:24 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA18435; Fri, 19 Jul 2002 08:47:23 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id DAF2C57307; Fri, 19 Jul 2002 08:47:17 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 2C48325835; Fri, 19 Jul 2002 08:47:17 +0200 (CEST) Message-ID: <3D37B5F4.D799185C@ch.sauter-bc.com> Date: Fri, 19 Jul 2002 08:47:16 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Ben Gollmer Cc: XFS Subject: Re: Software RAID, a bit OT References: <3D36C9C3.BDFACE39@ch.sauter-bc.com> <1027002434.5457.26.camel@jen.americas.sgi.com> <200207181551.49007.ben@jatosoft.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ben Gollmer schrieb: > > Everyone: > > Thanks for all your input. > > I'm going to stick with the Promise ATA-133 controllers, as they are only $30 > at www.newegg.com. Also I am using software RAID, the 3ware controllers that > I looked at were hardware RAID only and too expensive - I'd rather have more > storage space. > > I'm planning to use RAID 0+1 with XFS on kernel 2.4.18 (or 2.4.19 if it's out > by the time our disks come in). If there's any other good patches that you'd > recommend for a server, let me know - I'm currently in the habit of running > mostly vanilla kernels on my servers (except for XFS of course ;). Hi, There are some IDE and software RAID related patches you may want to use. I suggest looking at a recent RedHat kernel source RPM to get an idea of what might be appropriate. > > Quick question for anyone with Linux software RAID experience: our RAID 0 will > be composed of two RAID 1s, md0 and md1. if we decide we need more storage, > is it easy to create another RAID 1 (md2) and add it to the stripe set? Or > would that require something like LVM (or even a re-format)? RAID 0+1 can be created in two different ways, but only one of them performs well, the other way around the RAID performs _very_ bad. Create a RAID0 on top of two RAID1 like this: raiddev /dev/md0 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 #nr-spare-disks 0 device /dev/sda1 raid-disk 0 device /dev/sdb1 raid-disk 1 raiddev /dev/md1 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 #nr-spare-disks 0 device /dev/sdc1 raid-disk 0 device /dev/sdd1 raid-disk 1 raiddev /dev/md2 raid-level 0 <-- you may want to use 'linear' instead nr-raid-disks 2 chunk-size 64k persistent-superblock 1 #nr-spare-disks 0 device /dev/md0 raid-disk 0 device /dev/md1 raid-disk 1 Now, another idea comes in because you want to be able to expand existing arrays. I don't recommend LVM (LVM,EVMS,...) at the moment because it makes things more complicated and it isn't worth it if you only want to expand filesystems later by adding more disks. I recommend using a linear 'RAID' on top of the RAID1 volumes. To expand later, you may just create another RAID1 volume, append it to the linear array while it is stopped and then grow the XFS filesystem on it. WARNING: I have not tested linear arrays, if it works like the other RAID types, it should be okay. Simon > > Thanks again, > Ben From owner-linux-xfs@oss.sgi.com Fri Jul 19 00:48:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6J7mURw017279 for ; Fri, 19 Jul 2002 00:48:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6J7mUKY017278 for linux-xfs-outgoing; Fri, 19 Jul 2002 00:48:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6J7mLRw017250 for ; Fri, 19 Jul 2002 00:48:21 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6J7mt3o047781; Fri, 19 Jul 2002 09:48:56 +0200 (CEST) Message-Id: <4.3.2.7.2.20020719092149.035f0d10@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Jul 2002 09:47:49 +0200 To: Simon Matter , Ben Gollmer From: Seth Mos Subject: Re: Software RAID, a bit OT Cc: XFS In-Reply-To: <3D37B5F4.D799185C@ch.sauter-bc.com> References: <3D36C9C3.BDFACE39@ch.sauter-bc.com> <1027002434.5457.26.camel@jen.americas.sgi.com> <200207181551.49007.ben@jatosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:47 19-7-2002 +0200, Simon Matter wrote: > > I'm planning to use RAID 0+1 with XFS on kernel 2.4.18 (or 2.4.19 if > it's out > > by the time our disks come in). If there's any other good patches that > you'd > > recommend for a server, let me know - I'm currently in the habit of running > > mostly vanilla kernels on my servers (except for XFS of course ;). I believe there are some NFS patches floating around which some people recommend. It might be worth checking those out. >Now, another idea comes in because you want to be able to expand >existing arrays. I don't recommend LVM (LVM,EVMS,...) at the moment >because it makes things more complicated and it isn't worth it if you >only want to expand filesystems later by adding more disks. I recommend >using a linear 'RAID' on top of the RAID1 volumes. To expand later, you >may just create another RAID1 volume, append it to the linear array >while it is stopped and then grow the XFS filesystem on it. WARNING: I >have not tested linear arrays, if it works like the other RAID types, it >should be okay. I like the theory but someone needs to prove it and let us know. Normally you would need a abstraction layer like lvm for other raid levels to make this work. The linear option does kill performance to that of single disk and you don't get the added write speed of the extra spindles. The read speed could be up to twice the speed of single disk. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Jul 19 01:52:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6J8qaRw018771 for ; Fri, 19 Jul 2002 01:52:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6J8qaNO018770 for linux-xfs-outgoing; Fri, 19 Jul 2002 01:52:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpstore.strencom.net (ns1.strencom.net [217.75.0.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6J8qRRw018739 for ; Fri, 19 Jul 2002 01:52:28 -0700 Received: from raptor.raidtec.ie (unknown [217.75.2.18]) by smtpstore.strencom.net (Postfix) with SMTP id 40E44CEED9; Fri, 19 Jul 2002 09:06:46 +0000 (AZOST) Received: from no.name.available by raptor.raidtec.ie via smtpd (for ns1.strencom.net [217.75.0.66]) with SMTP; 19 Jul 2002 09:26:01 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: RE: ACL problems Date: Fri, 19 Jul 2002 09:53:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACL problems Thread-Index: AcIulupCNcb1RvSOTTqeGmUktMpn5QAai5gA From: "Juer Lee" To: "Stephan Boldt" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6J8qSRw018741 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You are running wrong command. Please read the manual of how to use chacl :) Juer >-----Original Message----- >From: Stephan Boldt [mailto:stephan.boldt@oscar.de] >Sent: 18 July 2002 21:03 >To: 'linux-xfs@oss.sgi.com' >Subject: ACL problems > > >Hello, > >I just installed the xfs 1.1: I patched the original kernel >2.4.18, enabled >all new xfs features, compiled and installed it. >Then I created a new xfs fs with makefs.xfs an mounted it on >/vol/aclpart >When I wanted to test the acl-feature the following errors occured: > >[root@ws1 /vol/aclpart] ls >. .. rute.pdf data >[root@ws1 /vol/aclpart] chacl u:bolst:rwx rute.pdf >chacl: u:bolst:rwx - Invalid argument >[root@ws1 /vol/aclpart] chacl u::rwx rute.pdf >chacl: access ACL 'u::rwx': Missing or wrong entry at entry 1 > >Have you got any idea what's going wrong? > >greets >Stephan > > From owner-linux-xfs@oss.sgi.com Fri Jul 19 04:52:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JBqVRw022484 for ; Fri, 19 Jul 2002 04:52:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JBqVrw022483 for linux-xfs-outgoing; Fri, 19 Jul 2002 04:52:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta03.algx.net (chimta03.algx.net [216.99.233.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JBqORw022455 for ; Fri, 19 Jul 2002 04:52:24 -0700 Received: from wiley.ceo.com (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx03.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GZH007JKVOESD@chimmx03.algx.net> for linux-xfs@oss.sgi.com; Fri, 19 Jul 2002 06:53:03 -0500 (CDT) Date: Fri, 19 Jul 2002 07:53:02 -0400 From: Danny Cox Subject: Re: Software RAID, a bit OT In-reply-to: <200207181551.49007.ben@jatosoft.com> To: Ben Gollmer Cc: XFS Mailing List Message-id: <1027079582.1150.7.camel@wiley> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7BIT References: <3D36C9C3.BDFACE39@ch.sauter-bc.com> <1027002434.5457.26.camel@jen.americas.sgi.com> <200207181551.49007.ben@jatosoft.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ben, On Thu, 2002-07-18 at 16:51, Ben Gollmer wrote: > I'm going to stick with the Promise ATA-133 controllers, as they are only $30 > at www.newegg.com. Also I am using software RAID, the 3ware controllers that > I looked at were hardware RAID only and too expensive - I'd rather have more > storage space. Cool! I didn't know they were so cheap (inexpensive). > Quick question for anyone with Linux software RAID experience: our RAID 0 will > be composed of two RAID 1s, md0 and md1. if we decide we need more storage, > is it easy to create another RAID 1 (md2) and add it to the stripe set? Or > would that require something like LVM (or even a re-format)? Well, actually, there *is* a utility that can convert between raid levels and # of disks. For example, you can convert a 3 disk raid5 to a 4 disk raid5. You can also do what you want to in your question. It's called "raidreconf", and is now included with the standard raid-tools package. The RAID must be offline, and the tool runs in user-space. It can run for long periods, and you should make a backup before hand, just in case. If it runs to completion (barring a power failure, for example), then it'll save you at least the copy in. See http://unthought.net/raidreconf/ for more info and warnings. In the spirit of full disclosure, I did write the RAID5 portion of the tool. Jakob Ostergaard did the real work. Hope this helps! -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Fri Jul 19 08:46:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JFkKRw001766 for ; Fri, 19 Jul 2002 08:46:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JFkKHu001765 for linux-xfs-outgoing; Fri, 19 Jul 2002 08:46:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JFkERw001737 for ; Fri, 19 Jul 2002 08:46:14 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA75717 for ; Fri, 19 Jul 2002 10:46:48 -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 KAA57168 for ; Fri, 19 Jul 2002 10:46:48 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6JFjGl14897; Fri, 19 Jul 2002 10:45:16 -0500 Message-Id: <200207191545.g6JFjGl14897@stout.americas.sgi.com> Date: Fri, 19 Jul 2002 10:45:16 -0500 Subject: TAKE - Make 2.4's xfs_super.c a bit more like 2.5 X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph's suggestion to keep 2.4 and 2.5 code a bit more similar. Remove DECLARE_FSTYPE_DEV macro, explicitly set struct file_system_type (closer to 2.5 code) Date: Fri Jul 19 08:45:53 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123350a linux/fs/xfs/linux/xfs_super.c - 1.194 From owner-linux-xfs@oss.sgi.com Fri Jul 19 08:56:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JFu8Rw002173 for ; Fri, 19 Jul 2002 08:56:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JFu8Hw002172 for linux-xfs-outgoing; Fri, 19 Jul 2002 08:56:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JFu2Rw002144 for ; Fri, 19 Jul 2002 08:56:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA83796 for ; Fri, 19 Jul 2002 10:56:36 -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 KAA99763 for ; Fri, 19 Jul 2002 10:56:36 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6JFt3a15986; Fri, 19 Jul 2002 10:55:03 -0500 Message-Id: <200207191555.g6JFt3a15986@stout.americas.sgi.com> Date: Fri, 19 Jul 2002 10:55:03 -0500 Subject: TAKE - Tweak Config.in options X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This adds XFS and pagebuf debugging back in, under $CONFIG_EXPERIMENTAL, along with some help text that tells you not to enable them. ;-) I just got tired of having to tweak Config.in every time I neede a debug kernel. Also moves CONFIG_XFS_RT under $CONFIG_EXPERIMENTAL since it's really not ready for general use. Finally, rename some of the XFS sub-options so they don't all start with "XFS..." - this makes the hotkeys work a bit better in menuconfig. Tweak Config.in options Date: Fri Jul 19 08:54:16 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123352a linux/fs/Config.in - 1.81 linux/Documentation/Configure.help - 1.135 From owner-linux-xfs@oss.sgi.com Fri Jul 19 09:38:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JGcMRw002797 for ; Fri, 19 Jul 2002 09:38:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JGcLk3002796 for linux-xfs-outgoing; Fri, 19 Jul 2002 09:38:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JGcBRw002763 for ; Fri, 19 Jul 2002 09:38:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA70824 for ; Fri, 19 Jul 2002 11:38: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 LAA25428 for ; Fri, 19 Jul 2002 11:38:45 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6JGbCB16528; Fri, 19 Jul 2002 11:37:12 -0500 Message-Id: <200207191637.g6JGbCB16528@stout.americas.sgi.com> Date: Fri, 19 Jul 2002 11:37:12 -0500 Subject: TAKE - move Atomic_spin from mrlock.c to xfs_globals.c X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From Christoph, "preparation of my mrlock-removal patch, also makes much more sense" move Atomic_spin from mrlock.c to xfs_globals.c Date: Fri Jul 19 09:38:08 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123361a linux/fs/xfs/linux/xfs_globals.c - 1.31 linux/fs/xfs/support/mrlock.c - 1.10 From owner-linux-xfs@oss.sgi.com Fri Jul 19 10:01:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JH1uRw003465 for ; Fri, 19 Jul 2002 10:01:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JH1uZn003464 for linux-xfs-outgoing; Fri, 19 Jul 2002 10:01:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JH1oRw003434 for ; Fri, 19 Jul 2002 10:01:50 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA70958 for ; Fri, 19 Jul 2002 12:02:24 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA05214 for ; Fri, 19 Jul 2002 12:02:24 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id MAA80382 for linux-xfs@oss.sgi.com; Fri, 19 Jul 2002 12:02:24 -0500 (CDT) Date: Fri, 19 Jul 2002 12:02:24 -0500 (CDT) From: Dean Roehrich Message-Id: <200207191702.MAA80382@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Add a dmapi<>fs hook to put a hold on a vnode/inode X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Jul 19 10:02:11 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123364a linux/fs/xfs/xfs_dmapi.c - 1.71 - Add xfs_dm_obj_ref_hold(), as interface to VN_HOLD(). linux/include/linux/dmapi_kern.h - 1.15 - create DM_FSYS_OBJ_REF_HOLD and dm_fsys_obj_ref_hold_t. linux/fs/xfs_dmapi/dmapi_private.h - 1.16 - Add dm_fsys_obj_ref_hold_t. linux/fs/xfs_dmapi/dmapi_mountinfo.c - 1.8 - Add DM_FSYS_OBJ_REF_HOLD. From owner-linux-xfs@oss.sgi.com Fri Jul 19 10:04:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JH4QRw003639 for ; Fri, 19 Jul 2002 10:04:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JH4QaQ003638 for linux-xfs-outgoing; Fri, 19 Jul 2002 10:04:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JH4LRw003609 for ; Fri, 19 Jul 2002 10:04:21 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA69676 for ; Fri, 19 Jul 2002 12:04:55 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA52654 for ; Fri, 19 Jul 2002 12:04:55 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id MAA28968 for linux-xfs@oss.sgi.com; Fri, 19 Jul 2002 12:04:55 -0500 (CDT) Date: Fri, 19 Jul 2002 12:04:55 -0500 (CDT) From: Dean Roehrich Message-Id: <200207191704.MAA28968@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - make dmapi use new ->obj_ref_hold vector X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Jul 19 10:04:50 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123365a linux/fs/xfs_dmapi/dmapi_right.c - 1.13 - Use the ->obj_ref_hold vector rather than VN_HOLD. linux/fs/xfs_dmapi/dmapi_register.c - 1.19 - Remove comments referring to VN_RELE. From owner-linux-xfs@oss.sgi.com Fri Jul 19 10:05:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JH5QRw003813 for ; Fri, 19 Jul 2002 10:05:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JH5QFg003812 for linux-xfs-outgoing; Fri, 19 Jul 2002 10:05:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from verein.lst.de (verein.lst.de [212.34.181.86]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JH5JRw003783 for ; Fri, 19 Jul 2002 10:05:20 -0700 Received: (from hch@localhost) by verein.lst.de (8.11.6/8.11.6) id g6JH5so18302; Fri, 19 Jul 2002 19:05:54 +0200 Date: Fri, 19 Jul 2002 19:05:54 +0200 From: Christoph Hellwig To: Dean Roehrich Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Add a dmapi<>fs hook to put a hold on a vnode/inode Message-ID: <20020719190554.A18268@lst.de> References: <200207191702.MAA80382@clink.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: <200207191702.MAA80382@clink.americas.sgi.com>; from roehrich@sgi.com on Fri, Jul 19, 2002 at 12:02:24PM -0500 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jul 19, 2002 at 12:02:24PM -0500, Dean Roehrich wrote: > Modid: 2.4.x-xfs:slinx:123364a > linux/fs/xfs/xfs_dmapi.c - 1.71 > - Add xfs_dm_obj_ref_hold(), as interface to VN_HOLD(). > > linux/include/linux/dmapi_kern.h - 1.15 > - create DM_FSYS_OBJ_REF_HOLD and dm_fsys_obj_ref_hold_t. > > linux/fs/xfs_dmapi/dmapi_private.h - 1.16 > - Add dm_fsys_obj_ref_hold_t. > > linux/fs/xfs_dmapi/dmapi_mountinfo.c - 1.8 > - Add DM_FSYS_OBJ_REF_HOLD. Wouldn't life be much simpler if dmapi gets moved back to fs/xfs/dmapi and into the xfs module so it can access all those APIs directly? The current code is of no use for other filesystems anyway.. From owner-linux-xfs@oss.sgi.com Fri Jul 19 10:06:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JH6KRw003999 for ; Fri, 19 Jul 2002 10:06:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JH6Kw3003998 for linux-xfs-outgoing; Fri, 19 Jul 2002 10:06:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JH6FRw003968 for ; Fri, 19 Jul 2002 10:06:16 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA75110 for ; Fri, 19 Jul 2002 12:06:50 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA44121 for ; Fri, 19 Jul 2002 12:06:50 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id MAA95312 for linux-xfs@oss.sgi.com; Fri, 19 Jul 2002 12:06:50 -0500 (CDT) Date: Fri, 19 Jul 2002 12:06:50 -0500 (CDT) From: Dean Roehrich Message-Id: <200207191706.MAA95312@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - delete xfsjunk.c from xfs_dmapi dir X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Jul 19 10:06:35 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123366a linux/fs/xfs_dmapi/xfsjunk.c - 1.13 linux/fs/xfs_dmapi/Makefile.in - 1.8 linux/fs/xfs_dmapi/Makefile - 1.7 - No Message Supplied From owner-linux-xfs@oss.sgi.com Fri Jul 19 10:38:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JHcYRw004481 for ; Fri, 19 Jul 2002 10:38:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JHcYQj004480 for linux-xfs-outgoing; Fri, 19 Jul 2002 10:38:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JHcSRw004451 for ; Fri, 19 Jul 2002 10:38:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA74636; Fri, 19 Jul 2002 12:39:02 -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 MAA45763; Fri, 19 Jul 2002 12:39:02 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id MAA15326; Fri, 19 Jul 2002 12:39:02 -0500 (CDT) Message-Id: <200207191739.MAA15326@slobber.americas.sgi.com> To: Christoph Hellwig cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Add a dmapi<>fs hook to put a hold on a vnode/inode Date: Fri, 19 Jul 2002 12:39:01 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Christoph Hellwig >Wouldn't life be much simpler if dmapi gets moved back to fs/xfs/dmapi >and into the xfs module so it can access all those APIs directly? We've been talking about moving it back. Even if I do that, I still want to make it a little less knowledgable about XFS. >The current code is of no use for other filesystems anyway.. I see no reason for anyone to start a new DMAPI project from scratch. This code can eventually be massaged into shape. The (relatively) recent fh_to_dentry and dentry_to_fh VFS hooks go a long way toward making this possible. Does anyone have an have an opinion on moving the dmapi code back to fs/xfs/dmapi? Dean From owner-linux-xfs@oss.sgi.com Fri Jul 19 10:41:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JHfoRw004658 for ; Fri, 19 Jul 2002 10:41:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JHfoBY004657 for linux-xfs-outgoing; Fri, 19 Jul 2002 10:41:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from verein.lst.de (verein.lst.de [212.34.181.86]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JHfiRw004629 for ; Fri, 19 Jul 2002 10:41:45 -0700 Received: (from hch@localhost) by verein.lst.de (8.11.6/8.11.6) id g6JHgLf18794; Fri, 19 Jul 2002 19:42:21 +0200 Date: Fri, 19 Jul 2002 19:42:21 +0200 From: Christoph Hellwig To: Dean Roehrich Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Add a dmapi<>fs hook to put a hold on a vnode/inode Message-ID: <20020719194221.A18755@lst.de> References: <200207191739.MAA15326@slobber.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: <200207191739.MAA15326@slobber.americas.sgi.com>; from roehrich@sgi.com on Fri, Jul 19, 2002 at 12:39:01PM -0500 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jul 19, 2002 at 12:39:01PM -0500, Dean Roehrich wrote: > We've been talking about moving it back. Even if I do that, I still want to > make it a little less knowledgable about XFS. Okay. Although this is only depend on the IRIX-ported vfs/vnode layer, not XFS itself. And this depency is hardcoded almost everywhere in the dmapi code. > >The current code is of no use for other filesystems anyway.. > > I see no reason for anyone to start a new DMAPI project from scratch. This > code can eventually be massaged into shape. Yes. But the "massaging" would be _major_ overhaul of the interfaces and should not happen in the XFS tree ubt rather on a copy of the code. > The (relatively) recent > fh_to_dentry and dentry_to_fh VFS hooks go a long way toward making this > possible. They're gone again in 2.5.. From owner-linux-xfs@oss.sgi.com Fri Jul 19 12:12:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JJCcRw027109 for ; Fri, 19 Jul 2002 12:12:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JJCc5B027108 for linux-xfs-outgoing; Fri, 19 Jul 2002 12:12:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cvo-exchange.cvo.roguewave.com (cvo-ext.roguewave.com [12.22.36.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JJCRRw027072 for ; Fri, 19 Jul 2002 12:12:28 -0700 Received: by cvo-exchange.cvo.roguewave.com with Internet Mail Service (5.5.2655.55) id ; Fri, 19 Jul 2002 12:07:56 -0700 Message-ID: From: Poul Petersen To: linux-xfs@oss.sgi.com Subject: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Date: Fri, 19 Jul 2002 12:07:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Since we started using XFS over a year ago, we have had periodic problems. At the worst, our server would die perhaps twice a week with a kswapd oops, or other Null Pointer errors. These problems persisted, though changed slightly (I don't remember the whole history now - but I've posted here several times) as we went from XFS 1.01, to 1.02, to 1.1 and from kernel 2.4.5, 2.4.14, to 2.4.18 (I think that is right - the only ones I remember for sure are 2.4.14+XFS-1.0.2 and 2.4.18+XFS-1.1). The problems definitely seemed to intensify as if the file-systems had become hopelessly corrupt. Indeed, running xfs_repair after each crash would extend the uptime between crashes to a week, perhaps 10 days. We also tried different hardware, in fact a total of three different machines. We also tried to duplicate the problem: we kept the original file-server OS disk with 2.4.5+XFS-1.01 which had been horribly unstable and installed it into identical hardware: cpu, SCSI controllers, SAN controller, SAN disks, network cards, etc. I then wrote a script which tried to duplicate our typical usage (a continuous build) and stressed the machine from 12 nodes for well over a week (pushing about 30MB/s: yup gig ether). I also added a continuous backup and I even threw in some memory stress tests as well as Bonnie. This configuration *never* crashed. I can only conclude that there is something about the real usage of our file systems that exposes a flaw in XFS, but I have no idea what it could be. I do feel that it is *not* a hardware problem. I state this because we have migrated all of our file-systems from XFS to ext3 (about 1TB of data). While I was going through the hassle of moving data, I decided to add LVM as well (much recommended to anyone considering LVM - way cool). This configuration, though more complicated, has been up solidly for about a month now - a time period which would have seen our XFS based file server crash perhaps 3 or 4 times. I debated not sending this message since it seemed like I might be taken as complaining. I'm not. We've given up on XFS simply because we can't duplicate the problem in a controlled environment, so we don't feel like we are going to be able to fix it. As this is a production machine, we simply can't have it crash each week. I felt it was important to let everyone know that there may be a significant bug, though obviously obscure. -poul Last XFS config: Dell 2550 Dual P-III (Coppermine) 933 MHz 1 GB Ram 1 9GB internal disk, aic7xxx driver (kernel) RedHat 7.2 kernel 2.4.18 + XFS 1.1 (and xfs tools) nfsutils-0.3.3 Qlogic 2200 SAN Adaptor firmware 2.02.01 running Qlogic driver 6.0b20 Intel PRO/1000 Gig-Fiber running Intel e1000 driver 4.0.7 Zzyzx RocketStor 2000 Raid Head Qlogic SAN box (Isolated Hard segment between file-server and Zzyzx) From owner-linux-xfs@oss.sgi.com Fri Jul 19 13:29:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JKTVRw028388 for ; Fri, 19 Jul 2002 13:29:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JKTVZL028387 for linux-xfs-outgoing; Fri, 19 Jul 2002 13:29:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JKTJRw028355 for ; Fri, 19 Jul 2002 13:29:19 -0700 Received: (qmail 6929 invoked by uid 500); 19 Jul 2002 20:29:54 -0000 Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops From: Austin Gonyou To: Poul Petersen Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2ZO0Y4uK01d4CWMWQ5fc" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 19 Jul 2002 15:29:54 -0500 Message-Id: <1027110594.6686.19.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-2ZO0Y4uK01d4CWMWQ5fc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just as a point of note. We run twelve 2550's in production taking ~75 to 100million hits/day. We run *nothing* but XFS. Also, just recently I brought up a 6650, P4 box, and run only XFS there as well. One thing I always do though, and is a good idea, is to use the -aa tree. It has XFS support, no code changes, just incorporation, as well as lots of other goodies for good systems like this.=20 Of note at this time on the 6650, I'm running 2.4.19-rc2-aa1.=20 In production it's 2.4.10 + xfs patches. With all honesty, it has been "uberstable" besides a couple of issues we've had, but that was our own stupidity, and nothing to do with XFS or hardware. (qlogic stuff) > Last XFS config: >=20 > Dell 2550 Dual P-III (Coppermine) 933 MHz > 1 GB Ram > 1 9GB internal disk, aic7xxx driver (kernel) > RedHat 7.2 > kernel 2.4.18 + XFS 1.1 (and xfs tools) > nfsutils-0.3.3 > Qlogic 2200 SAN Adaptor firmware 2.02.01 running Qlogic driver 6.0b20 > Intel PRO/1000 Gig-Fiber running Intel e1000 driver 4.0.7 > Zzyzx RocketStor 2000 Raid Head > Qlogic SAN box (Isolated Hard segment between file-server and Zzyzx) Are you running this server specifically for NFS purposes? If so, you might want to try the latest CVS, as well as looking at using the -aa tree. Personally, I love XFS for what it does. It's been the most resiliant, and stable FS we've run, not in the kernel tree.=20 --=20 Austin Gonyou Coremetrics, Inc. --=-2ZO0Y4uK01d4CWMWQ5fc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9OHbC94g6ZVmFMoIRAutoAJ987mJ9neKcZRoJY771dPii5sfBQACg78zb rIveisXg/4bQSi3L9XHavEI= =8j3r -----END PGP SIGNATURE----- --=-2ZO0Y4uK01d4CWMWQ5fc-- From owner-linux-xfs@oss.sgi.com Fri Jul 19 13:38:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JKcZRw028583 for ; Fri, 19 Jul 2002 13:38:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JKcZEq028582 for linux-xfs-outgoing; Fri, 19 Jul 2002 13:38:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JKcSRw028554 for ; Fri, 19 Jul 2002 13:38:29 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id E0D6E14821; Fri, 19 Jul 2002 22:39:02 +0200 (MEST) Date: Fri, 19 Jul 2002 22:38:54 +0200 From: Andi Kleen To: Poul Petersen Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Message-ID: <20020719223854.A11090@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When you see a oops on any linux box you should always save it, decode it with ksymoops and send it to one of the development lists (in this case to linux-xfs). If you don't do that you should not be surprised that bugs don't get fixed and you can only blame yourself. -Andi From owner-linux-xfs@oss.sgi.com Fri Jul 19 13:47:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JKl5Rw028766 for ; Fri, 19 Jul 2002 13:47:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JKl53B028765 for linux-xfs-outgoing; Fri, 19 Jul 2002 13:47:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JKkuRw028735 for ; Fri, 19 Jul 2002 13:46:57 -0700 Received: (qmail 6997 invoked by uid 500); 19 Jul 2002 20:47:23 -0000 Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops From: Austin Gonyou To: Andi Kleen Cc: Poul Petersen , linux-xfs@oss.sgi.com In-Reply-To: <20020719223854.A11090@wotan.suse.de> References: <20020719223854.A11090@wotan.suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oOER8D606ymb6I8AzXL4" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 19 Jul 2002 15:47:23 -0500 Message-Id: <1027111643.6687.26.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-oOER8D606ymb6I8AzXL4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I have to agree there. And if you don't know how, don't be shy,(or proud *grin*) just "ask" someone.=20 On Fri, 2002-07-19 at 15:38, Andi Kleen wrote: > When you see a oops on any linux box you should always save it, decode > it with ksymoops and send it to one of the development lists (in this > case to linux-xfs). If you don't do that you should not be surprised > that=20 > bugs don't get fixed and you can only blame yourself. >=20 > -Andi --=20 Austin Gonyou Coremetrics, Inc. --=-oOER8D606ymb6I8AzXL4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9OHrb94g6ZVmFMoIRAu0lAKDyeywqxsGIrcGzhvYmVB946VQaJgCg0PCa fMoLTzVEULPB4csF/6Rw/SU= =gTr1 -----END PGP SIGNATURE----- --=-oOER8D606ymb6I8AzXL4-- From owner-linux-xfs@oss.sgi.com Fri Jul 19 14:32:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JLWbRw029364 for ; Fri, 19 Jul 2002 14:32:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JLWbNQ029363 for linux-xfs-outgoing; Fri, 19 Jul 2002 14:32:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JLWJRw029333 for ; Fri, 19 Jul 2002 14:32:19 -0700 Received: (qmail 7123 invoked by uid 500); 19 Jul 2002 21:32:47 -0000 Subject: [Slightly OT] XFS for 2.5(6) Kernel potential. From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vlYXeGRMu/Ffh7AjGgIh" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 19 Jul 2002 16:32:47 -0500 Message-Id: <1027114367.6683.36.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-vlYXeGRMu/Ffh7AjGgIh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I was reading the LKML, then found this information regarding a potential roadmap over at kerneltrap.org. This is the summarized bits for 2.6 as far as order and must-haves vs. nice-to-haves vs. not-haves-(in 2.6). FYI. XFS is listed. I just wanted t post this to help answer/shed light on some of the more obvious questions around XFS and 2.5 kernel tree.=20 From: Guillaume Boissiere Subject: [2.6] The List, pass #2 Date: Fri, 19 Jul 2002 00:47:37 -0400 I've reorganized the list into 5 categories based on the feedback=20 I received. Now let's see what happens :-) In line with your expectations? -- Guillaume ---------------------------------------------------- Likely to be merged before feature freeze: =20 o New VM with reverse mappings o Add Linux Security Module (LSM) o New MTRR (Memory Type Range Register) driver o Add support for CPU clock/voltage scaling o Add User-Mode Linux (UML) o Direct pagecache BIO disk I/O o Fix device naming issues o Remove the 2TB block device limit=20 =20 ---------------------------------------------------- "The pressure is on! (TM)": (either gets merged before feature freeze or has to wait till 2.7) =20 o Rewrite of the console layer=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 o XFS (A journaling filesystem from SGI) o LVM (Logical Volume Manager) v2.0 o Zerocopy NFS o Asynchronous IO (aio) support o New kernel build system (kbuild 2.5) o Serial driver restructure=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 o Replace initrd by initramfs o ext2/ext3 large directory support: HTree index =20 ---------------------------------------------------- Can be merged after the feature freeze and before the 2.6 release: =20 o Strict address space accounting=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 o More complete NetBEUI stack=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 o Add hardware sensors drivers=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 o PCMCIA Zoom video support=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 o Change all drivers to new driver model o UDF Write support for CD-R/RW (packet writing) o USB gadget support =20 ---------------------------------------------------- Would be nice to have before feature freeze, but most likely 2.7: =20 o Improved i2o (Intelligent Input/Ouput) layer o Read-Copy Update Mutual Exclusion o New IO scheduler o Per-mountpoint read-only, union-mounts, unionfs o EVMS (Enterprise Volume Management System) o Dynamic Probes o Page table sharing o ext2/ext3 online resize support o Better event logging for enterprise systems o UMSDOS (Unix under MS-DOS) Rewrite o Scalable Statistics Counter o Linux Kernel Crash Dumps o SCTP (Stream Control Transmission Protocol) o High resolution timers o Overhaul PCMCIA support o Reiserfs v4 o New lightweight library (klibc) o New mount API o Generic parameter/command line interface o Full compliance with IPv6 o Serial ATA support=20=20=20=20=20=20 o Add support for NFS v4 =20 ---------------------------------------------------- Definitely 2.7: =20 o InfiniBand support o Add thrashing control o Remove all hardwired drivers from kernel --=20 Austin Gonyou Coremetrics, Inc. --=-vlYXeGRMu/Ffh7AjGgIh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9OIV/94g6ZVmFMoIRAjoDAKCinh4Bz4TeZRc3J5HDMBux83cozwCg7J0R gs4u13QNa9BGBfwI5qYldO4= =kUkx -----END PGP SIGNATURE----- --=-vlYXeGRMu/Ffh7AjGgIh-- From owner-linux-xfs@oss.sgi.com Fri Jul 19 15:15:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JMFQRw029827 for ; Fri, 19 Jul 2002 15:15:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JMFQlK029826 for linux-xfs-outgoing; Fri, 19 Jul 2002 15:15:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dns.securities.com (mail01.securities.com [57.69.15.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JMFARw029798 for ; Fri, 19 Jul 2002 15:15:10 -0700 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g6JMFh711856; Fri, 19 Jul 2002 18:15:43 -0400 Date: Fri, 19 Jul 2002 18:15:43 -0400 (EDT) From: Benito Venegas To: Poul Petersen cc: Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Poul: I have a similar HW, but using 650F and 630 F (one of this is without F :/) I have some minor problems with 2.4.9-13 and the previous one, but after to install 2.4.9-31 and I'haven;t experienced any problem Suggestion (like Austin and Andi said): Sent to the list or developers the result of ksymoops using the kernel Oops output (probably it's in /var/log/message or /var/log/kernel if you configured syslog.conf) System has been very well, without any problems and I can tell you my box it's like a Christmas tree. It's sharing through NFS to 5 differen systems and each one with different rates in I/O. Give us more details. Keith, Eric, and the rest of team can help you. Feel free to contact me if you want more details. Good luck.. On Fri, 19 Jul 2002, Poul Petersen wrote: > Since we started using XFS over a year ago, we have had periodic > problems. At the worst, our server would die perhaps twice a week with a > kswapd oops, or other Null Pointer errors. These problems persisted, though > changed slightly (I don't remember the whole history now - but I've posted > here several times) as we went from XFS 1.01, to 1.02, to 1.1 and from > kernel 2.4.5, 2.4.14, to 2.4.18 (I think that is right - the only ones I > remember for sure are 2.4.14+XFS-1.0.2 and 2.4.18+XFS-1.1). The problems > definitely seemed to intensify as if the file-systems had become hopelessly > corrupt. Indeed, running xfs_repair after each crash would extend the uptime > between crashes to a week, perhaps 10 days. > > We also tried different hardware, in fact a total of three different > machines. We also tried to duplicate the problem: we kept the original > file-server OS disk with 2.4.5+XFS-1.01 which had been horribly unstable and > installed it into identical hardware: cpu, SCSI controllers, SAN controller, > SAN disks, network cards, etc. I then wrote a script which tried to > duplicate our typical usage (a continuous build) and stressed the machine > from 12 nodes for well over a week (pushing about 30MB/s: yup gig ether). I > also added a continuous backup and I even threw in some memory stress tests > as well as Bonnie. This configuration *never* crashed. I can only conclude > that there is something about the real usage of our file systems that > exposes a flaw in XFS, but I have no idea what it could be. > > I do feel that it is *not* a hardware problem. I state this because > we have migrated all of our file-systems from XFS to ext3 (about 1TB of > data). While I was going through the hassle of moving data, I decided to add > LVM as well (much recommended to anyone considering LVM - way cool). This > configuration, though more complicated, has been up solidly for about a > month now - a time period which would have seen our XFS based file server > crash perhaps 3 or 4 times. > > I debated not sending this message since it seemed like I might be > taken as complaining. I'm not. We've given up on XFS simply because we can't > duplicate the problem in a controlled environment, so we don't feel like we > are going to be able to fix it. As this is a production machine, we simply > can't have it crash each week. I felt it was important to let everyone know > that there may be a significant bug, though obviously obscure. > > -poul > > Last XFS config: > > Dell 2550 Dual P-III (Coppermine) 933 MHz > 1 GB Ram > 1 9GB internal disk, aic7xxx driver (kernel) > RedHat 7.2 > kernel 2.4.18 + XFS 1.1 (and xfs tools) > nfsutils-0.3.3 > Qlogic 2200 SAN Adaptor firmware 2.02.01 running Qlogic driver 6.0b20 > Intel PRO/1000 Gig-Fiber running Intel e1000 driver 4.0.7 > Zzyzx RocketStor 2000 Raid Head > Qlogic SAN box (Isolated Hard segment between file-server and Zzyzx) > -- Benito A. Venegas System Engineer, Technology 225 Park Ave. South (6th floor ISI) New York, NY 10003 A Euromoney Institutional Investor company. ********************************************************************** This communication contains information which is confidential. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us by e-mail or by telephone (as above) and then delete the e-mail and all attachments and any copies thereof. ********************************************************************** From owner-linux-xfs@oss.sgi.com Fri Jul 19 15:18:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JMIaRw030001 for ; Fri, 19 Jul 2002 15:18:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JMIaFW030000 for linux-xfs-outgoing; Fri, 19 Jul 2002 15:18:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JMIURw029970 for ; Fri, 19 Jul 2002 15:18:30 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA78996 for ; Fri, 19 Jul 2002 17:19:06 -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 RAA33677 for ; Fri, 19 Jul 2002 17:19:05 -0500 (CDT) Subject: Who's using XFS? (again) From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 19 Jul 2002 17:17:31 -0500 Message-Id: <1027117051.12810.74.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all - I've been asked to take another pulse of the XFS user community; we did this a while ago, and the results are at http://oss.sgi.com/projects/xfs/xfs_users.html If you're using XFS in an interesting/large/impressive/unique installation, or your company is shipping a product using XFS (and you can go on the record about it*) I'd like to know, so I can update the information in the above web page. Rumor has it that Linus didn't think very many people were using XFS; perhaps I'll point him at this page when it's updated. :) Thanks, -Eric *If you can't go on the record, feel free to drop me an off-the-record note. :) -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Jul 19 15:59:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JMxERw031444 for ; Fri, 19 Jul 2002 15:59:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JMxEQo031443 for linux-xfs-outgoing; Fri, 19 Jul 2002 15:59:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cvo-exchange.cvo.roguewave.com (cvo-ext.roguewave.com [12.22.36.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JMx7Rw031408 for ; Fri, 19 Jul 2002 15:59:07 -0700 Received: by cvo-exchange.cvo.roguewave.com with Internet Mail Service (5.5.2655.55) id ; Fri, 19 Jul 2002 15:54:40 -0700 Message-ID: From: Poul Petersen To: linux-xfs@oss.sgi.com Subject: RE: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Date: Fri, 19 Jul 2002 15:54:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > When you see a oops on any linux box you should always save > it, decode > it with ksymoops and send it to one of the development lists (in this > case to linux-xfs). If you don't do that you should not be > surprised that > bugs don't get fixed and you can only blame yourself. Been there, done that. Spent many an anxious evening saving oops outputs, running them through ksymoops and adding trying to make sense of it all - I had plenty to choose from, and I shared them. A quick search finds: http://marc.theaimsgroup.com/?l=linux-xfs&m=99558768600852&w=2 http://marc.theaimsgroup.com/?l=linux-xfs&m=99721971620728&w=2 http://marc.theaimsgroup.com/?l=linux-xfs&m=100402789630290&w=2 http://marc.theaimsgroup.com/?l=linux-xfs&m=102264819826742&w=2 That last post evoked no responses and was pretty much the point when we decided to bail. To be fair, one of the earlier ones was an oops which resulted from a conflict between NFS and xfsdump (which I think was resolved later - we just switched amanda to use tar). There is no need to be defensive - I am not attacking XFS or saying it is garbage, etc. Our experience with XFS was a bad one, others not. Maybe we have some bizarre configuration, maybe we are doing it wrong. But we arrived at a point where the server was going down every week and we couldn't get a similar system in a controlled environment to fail, which was derailing any attempts to debug the problem - it's hard to spent time figuring out what is going wrong or testing patches with 100+ people waiting for the NFS server to come back up. Anyways, if every post was about how wonderful XFS was, what fun would that be? -poul From owner-linux-xfs@oss.sgi.com Fri Jul 19 16:09:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JN92Rw031706 for ; Fri, 19 Jul 2002 16:09:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JN92nv031705 for linux-xfs-outgoing; Fri, 19 Jul 2002 16:09:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cvo-exchange.cvo.roguewave.com (cvo-ext.roguewave.com [12.22.36.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JN8vRw031677 for ; Fri, 19 Jul 2002 16:08:57 -0700 Received: by cvo-exchange.cvo.roguewave.com with Internet Mail Service (5.5.2655.55) id ; Fri, 19 Jul 2002 16:04:30 -0700 Message-ID: From: Poul Petersen To: linux-xfs@oss.sgi.com Subject: RE: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Date: Fri, 19 Jul 2002 16:04:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Give us more details. > > Keith, Eric, and the rest of team can help you. > > Feel free to contact me if you want more details. > Thanks for the suggestions and offer of help - we are pretty happy without XFS for now, and since we aren't running it anymore I won't be able to send any other Oops output nor try other kernels/patches. I still can't get my test-box to fail and it is far too expensive to have the production server crashing. -poul From owner-linux-xfs@oss.sgi.com Fri Jul 19 18:49:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6K1nvRw000332 for ; Fri, 19 Jul 2002 18:49:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6K1nuuh000331 for linux-xfs-outgoing; Fri, 19 Jul 2002 18:49:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6K1nlRw000301 for ; Fri, 19 Jul 2002 18:49:47 -0700 Received: (qmail 8731 invoked by uid 500); 20 Jul 2002 01:50:15 -0000 Subject: RE: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops From: Austin Gonyou To: Poul Petersen Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bkrvIUDan+ZJP0xJ3vs0" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 19 Jul 2002 20:50:15 -0500 Message-Id: <1027129815.8681.6.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-bkrvIUDan+ZJP0xJ3vs0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable No offense, but it's these types of "odd" problems that the XFS team needs to clear corner cases, which it sounds like you're most recent problem is. Perhaps your previous post will help shed some light.=20 On Fri, 2002-07-19 at 18:04, Poul Petersen wrote: > > Give us more details. > >=20 > > Keith, Eric, and the rest of team can help you. > >=20 > > Feel free to contact me if you want more details. > >=20 >=20 > Thanks for the suggestions and offer of help - we are pretty > happy > without XFS for now, and since we aren't running it anymore I won't be > able > to send any other Oops output nor try other kernels/patches. I still > can't > get my test-box to fail and it is far too expensive to have the > production > server crashing.=20 >=20 > -poul --=20 Austin Gonyou Coremetrics, Inc. --=-bkrvIUDan+ZJP0xJ3vs0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9OMHX94g6ZVmFMoIRAoUQAJ9iegeebWBf+bzxqPDE1yuw+JA4pACcCTWk lB02g/FWEhjBgbMqd0oOYOs= =IdFz -----END PGP SIGNATURE----- --=-bkrvIUDan+ZJP0xJ3vs0-- From owner-linux-xfs@oss.sgi.com Fri Jul 19 19:12:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6K2CbRw000661 for ; Fri, 19 Jul 2002 19:12:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6K2CbGQ000660 for linux-xfs-outgoing; Fri, 19 Jul 2002 19:12:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6K2CWRw000632 for ; Fri, 19 Jul 2002 19:12:32 -0700 Received: from msumail2.Campus.mnsu.edu (msuex2.campus.mnsu.edu [134.29.52.40]) by deliverator.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 TAA06333 for ; Fri, 19 Jul 2002 19:13:10 -0700 (PDT) mail_from (jeffrey.hundstad@mnsu.edu) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Content-Type: text/plain; charset="Windows-1252" Date: Fri, 19 Jul 2002 21:11:48 -0500 Message-ID: Thread-Topic: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Thread-Index: AcIvkLDGo8tGgINLS4Sqes1LPzpBggAAG12p From: "Hundstad, Jeffrey E." To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6K2CXRw000633 X-Spam-Status: No, hits=0.9 required=5.0 tests=MAY_BE_FORGED,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It's too bad that XFS is losing people. I see we've made it to the finger pointing stage. Maybe we can step back.... If there already isn't too many hurt feelings is it possible to get a report on what TYPE of usage is causing problems. I've been using it on a 700GB server serving FTP, Samba and NetAtalk users to a couple of hundred university folk. Since we've gotten are hardware problems solved we've had no problems. I run it on my squid cache, my local workstation and laptop, no problems there either despite the batery running out and the XYL unplugging the hardware. If we could identify TYPES of load/services that perform well and those that perform poorly it may be as usfull as OOPS reports. Some users just don't have the time or ability, we all wish they did, but they CAN tell us what services were running. -- jeffrey hundstad From owner-linux-xfs@oss.sgi.com Fri Jul 19 20:00:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6K30bRw001326 for ; Fri, 19 Jul 2002 20:00:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6K30ba3001325 for linux-xfs-outgoing; Fri, 19 Jul 2002 20:00:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dns.securities.com (mail01.securities.com [57.69.15.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6K30QRw001245 for ; Fri, 19 Jul 2002 20:00:26 -0700 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g6K2o5O18756; Fri, 19 Jul 2002 22:50:05 -0400 Date: Fri, 19 Jul 2002 22:50:05 -0400 (EDT) From: Benito Venegas To: Austin Gonyou cc: Poul Petersen , Subject: RE: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops In-Reply-To: <1027129815.8681.6.camel@UberGeek> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, probably some of us (including myslef) can otain statistics and reference for this kind of "odd" problems and help to have a better XFS product. At least we can have more followers and show to Linus many things as Eric is trying to do. Have good weekend guys .. Vene On 19 Jul 2002, Austin Gonyou wrote: > No offense, but it's these types of "odd" problems that the XFS team > needs to clear corner cases, which it sounds like you're most recent > problem is. Perhaps your previous post will help shed some light. > > > On Fri, 2002-07-19 at 18:04, Poul Petersen wrote: > > > Give us more details. > > > > > > Keith, Eric, and the rest of team can help you. > > > > > > Feel free to contact me if you want more details. > > > > > > > Thanks for the suggestions and offer of help - we are pretty > > happy > > without XFS for now, and since we aren't running it anymore I won't be > > able > > to send any other Oops output nor try other kernels/patches. I still > > can't > > get my test-box to fail and it is far too expensive to have the > > production > > server crashing. > > > > -poul > -- Benito A. Venegas System Engineer, Technology 225 Park Ave. South (6th floor ISI) New York, NY 10003 A Euromoney Institutional Investor company. ********************************************************************** This communication contains information which is confidential. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us by e-mail or by telephone (as above) and then delete the e-mail and all attachments and any copies thereof. ********************************************************************** From owner-linux-xfs@oss.sgi.com Fri Jul 19 21:20:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6K4KDRw002121 for ; Fri, 19 Jul 2002 21:20:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6K4KDI1002118 for linux-xfs-outgoing; Fri, 19 Jul 2002 21:20:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6K4K7Rw002082 for ; Fri, 19 Jul 2002 21:20:08 -0700 Received: (qmail 8523 invoked from network); 20 Jul 2002 04:20:46 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 20 Jul 2002 04:20:46 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 84E063000B8; Sat, 20 Jul 2002 14:20:45 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 1675894; Sat, 20 Jul 2002 14:20:44 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: kdb@oss.sgi.com Subject: Debian 3.0 stable with XFS and KDB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Jul 2002 14:20:39 +1000 Message-ID: <7018.1027138839@ocs3.intra.ocs.com.au> X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk FYI, Debian 3.0 has been released as stable. It contains XFS and KDB. http://packages.debian.org/stable/devel/kernel-patch-xfs.html http://packages.debian.org/stable/devel/kernel-patch-kdb.html From owner-linux-xfs@oss.sgi.com Sat Jul 20 00:59:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6K7xPRw003636 for ; Sat, 20 Jul 2002 00:59:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6K7xPmG003634 for linux-xfs-outgoing; Sat, 20 Jul 2002 00:59:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6K7xJRw003594 for ; Sat, 20 Jul 2002 00:59:20 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id B69E11448F; Sat, 20 Jul 2002 09:59:56 +0200 (MEST) Date: Sat, 20 Jul 2002 09:59:56 +0200 From: Andi Kleen To: Poul Petersen Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Message-ID: <20020720095956.A3994@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Have you tried the usual tests like running memtest86 overnight to make sure you don't have a bad DIMM or some other hardware problem? When you switch to another filesystem and still get crashes you will eventually know. If that is the case you could at least report to the list later that it wasn't XFS to blame. Also you should make sure you are using a good compiler to compile XFS (e.g. some versions of the RedHat 2.96 gcc were pretty bad) -Andi From owner-linux-xfs@oss.sgi.com Sat Jul 20 03:15:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6KAF9Rw004505 for ; Sat, 20 Jul 2002 03:15:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6KAF9N9004504 for linux-xfs-outgoing; Sat, 20 Jul 2002 03:15:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from arx.inom.sector7.nu (root@as2-3-8.h.s.bonet.se [217.215.24.170]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6KAF0Rw004470 for ; Sat, 20 Jul 2002 03:15:02 -0700 Received: from inom.sector7.nu (patrik [192.168.1.16]) by arx.inom.sector7.nu (8.12.0/8.11.4) with SMTP id g6KAFkNp013447 for ; Sat, 20 Jul 2002 12:15:46 +0200 Received: by inom.sector7.nu (sSMTP sendmail emulation); Sat, 20 Jul 2002 12:18:19 +0200 Date: Sat, 20 Jul 2002 12:18:19 +0200 From: Patrik Kullman To: linux-xfs@oss.sgi.com Subject: XFS in the linux kernel before freeze? Message-ID: <20020720101819.GA31487@inom.sector7.nu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.4i X-PGP-Key: http://www.yes.nu/pubkey.asc X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline How likely is XFS to get into the linux kernel before the 2.5 freeze? I think I speak for thousands of users when I say that that would be one of the most important of the pending changes, if it got in. /Patrik --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9OTjrX9ySgNucgScRAmHMAKDJ2sRJBrawmrHpSLRC7Yt6chvdMgCfcoKN QEAdwdUDoDYf191PScE2oz4= =v8dG -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-linux-xfs@oss.sgi.com Sat Jul 20 07:20:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6KEKCRw006297 for ; Sat, 20 Jul 2002 07:20:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6KEKCAB006296 for linux-xfs-outgoing; Sat, 20 Jul 2002 07:20:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6KEK6Rw006268 for ; Sat, 20 Jul 2002 07:20:06 -0700 Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id E279F2FA04 for ; Sat, 20 Jul 2002 07:20:49 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 9766233ED for ; Sat, 20 Jul 2002 07:18:57 -0700 (PDT) Subject: Re: XFS in the linux kernel before freeze? From: Florin Andrei To: linux-xfs In-Reply-To: <20020720101819.GA31487@inom.sector7.nu> References: <20020720101819.GA31487@inom.sector7.nu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 20 Jul 2002 07:18:57 -0700 Message-Id: <1027174737.525.17.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.9 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 2002-07-20 at 03:18, Patrik Kullman wrote: > How likely is XFS to get into the linux kernel before the 2.5 freeze? > > I think I speak for thousands of users when I say that that would be one > of the most important of the pending changes, if it got in. Fairly likely: http://kerneltrap.org/node.php?id=348 What the article above means - our boys must be quite busy now working at the code. ;-) Let's help them by not bugging them with trivial matters. -- Florin Andrei Don't break things that don't need to be broken while you're fixing things that really need fixing. From owner-linux-xfs@oss.sgi.com Sat Jul 20 15:34:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6KMYoRw008985 for ; Sat, 20 Jul 2002 15:34:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6KMYo3P008984 for linux-xfs-outgoing; Sat, 20 Jul 2002 15:34:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6KMYeRw008956 for ; Sat, 20 Jul 2002 15:34:43 -0700 Received: (qmail 15235 invoked by uid 1010); 20 Jul 2002 22:35:24 -0000 Received: from unknown (HELO athlet) ([195.158.137.167]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 20 Jul 2002 22:35:24 -0000 Date: Sun, 21 Jul 2002 00:35:47 +0200 From: thomas X-Mailer: The Bat! (v1.60) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <587043127.20020721003547@ff33.cc> To: linux-xfs@oss.sgi.com Subject: data recovery after hdd failure MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello, a few days ago my 80GB HDD crashed and with it a 75GB XFS partition with important data. the drive was humming in my server for about a year with no problems but suddenly started to act funky. when i took a look in the logs i saw errors all over the place so i pulled the plug. the drive was _very_ hot. the drive still works, however i cant boot properly from it anymore nor can i mount any partition. i am pretty sure the drive was only damaged during the few minutes it was acting funky and that most of the data is still there. the partition table is damaged i believe, what was "hda: hda1 hda2 < hda5 >" is now reported as "hdc: [PTBL] [9964/255/63] hdc1 hdc2". so now i got myself a new 80GB and tried to restore at least the XFS partition (the other being ReiserFS, with less important data). xfs_repairs reports a bad superblock on hdc2, tries to find an alternate one and then stops after a while because of an I/O Error. So i tried to use dd with conv=noerror, and it seems to work (i stopped after ~500MB). with xfs_ncheck i get errors and some filelist on that recovered data, so i guess there is still hope left. i don't know how to use dd properly though. can i just dd conv=noerror /dev/hda5 and then xfs_repair /dev/hda5 or is it recommended to dd to a file? thanks for reading, any input is greatly appreciated. thomas From owner-linux-xfs@oss.sgi.com Sat Jul 20 22:51:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6L5pLRw011723 for ; Sat, 20 Jul 2002 22:51:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6L5pLA9011722 for linux-xfs-outgoing; Sat, 20 Jul 2002 22:51:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rebel.net.au (IDENT:root@ftp.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6L5pERw011694 for ; Sat, 20 Jul 2002 22:51:15 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id PAA26633; Sun, 21 Jul 2002 15:34:18 +0930 Message-ID: <3D3A4E14.7DEAF3D@rebel.net.au> Date: Sun, 21 Jul 2002 15:30:52 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: thomas CC: linux-xfs@oss.sgi.com Subject: Re: data recovery after hdd failure References: <587043127.20020721003547@ff33.cc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas > so now i got myself a new 80GB and tried to restore at least the XFS > partition (the other being ReiserFS, with less important data). > xfs_repairs reports a bad superblock on hdc2, tries to find an alternate > one and then stops after a while because of an I/O Error. So i tried to > use dd with conv=noerror, and it seems to work (i stopped after ~500MB). > with xfs_ncheck i get errors and some filelist on that recovered data, > so i guess there is still hope left. i don't know how to use dd properly > though. can i just dd conv=noerror /dev/hda5 and then > xfs_repair /dev/hda5 or is it recommended to dd to a file? I can't help you with the technical aspects but you'd do well to keep the damaged disk as COLD as possible when using it... (it sounds silly but it can make a difference) DSL From owner-linux-xfs@oss.sgi.com Sun Jul 21 01:41:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6L8fDRw012628 for ; Sun, 21 Jul 2002 01:41:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6L8fDh1012627 for linux-xfs-outgoing; Sun, 21 Jul 2002 01:41:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6L8f4Rw012599 for ; Sun, 21 Jul 2002 01:41:05 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6L8fiqb089160; Sun, 21 Jul 2002 10:41:49 +0200 (CEST) Message-Id: <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 21 Jul 2002 10:40:38 +0200 To: thomas , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: data recovery after hdd failure In-Reply-To: <587043127.20020721003547@ff33.cc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 00:35 21-7-2002 +0200, thomas wrote: >hello, >so now i got myself a new 80GB and tried to restore at least the XFS >partition (the other being ReiserFS, with less important data). >xfs_repairs reports a bad superblock on hdc2, tries to find an alternate >one and then stops after a while because of an I/O Error. So i tried to Repairing a disk with IO errors is near impossible. >use dd with conv=noerror, and it seems to work (i stopped after ~500MB). >with xfs_ncheck i get errors and some filelist on that recovered data, dump the disk with dd to a file on the new disk and repair that instead. This means that although not everything is recoverable you can at least repair what is left of it. Most disks that are failing are able to read sequentially but have big troubling seeking. Older Quantum fireball disks can show you this nicely. >so i guess there is still hope left. i don't know how to use dd properly >though. can i just dd conv=noerror /dev/hda5 and then >xfs_repair /dev/hda5 or is it recommended to dd to a file? I recommend doing it to a file but you may have space contraints and the dd file may not be able to fit on there. So dd'ing it straight to another disk might be a option. The geometry will probably have changed which might cause it to do funny things. I have too much failed IDE disks these days that I only run them in a raid 1 or 5 on important servers. Because IDE disks are rather cheap it's easier to just buy an extra and build me a raid array. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sun Jul 21 03:30:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6LAU0Rw013417 for ; Sun, 21 Jul 2002 03:30:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6LAU0UL013416 for linux-xfs-outgoing; Sun, 21 Jul 2002 03:30:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6LATsRw013387 for ; Sun, 21 Jul 2002 03:29:55 -0700 Received: from paragon.slim (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.11.6/linuxconf) with ESMTP id g6LAbvs10998; Sun, 21 Jul 2002 12:37:57 +0200 Subject: Re: Who's using XFS? (again) From: Jurgen Kramer To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1027117051.12810.74.camel@stout.americas.sgi.com> References: <1027117051.12810.74.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-2) Date: 21 Jul 2002 12:25:04 +0200 Message-Id: <1027247105.1110.1.camel@paragon.slim> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >Rumor has it that Linus didn't think very many people were using XFS; >perhaps I'll point him at this page when it's updated. :) Hmm this can be a problem. A lot of people are probably not using XFS because it is not in the standard kernel..:-( Cheers, Jurgen From owner-linux-xfs@oss.sgi.com Sun Jul 21 07:26:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6LEQERw020377 for ; Sun, 21 Jul 2002 07:26:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6LEQEDZ020376 for linux-xfs-outgoing; Sun, 21 Jul 2002 07:26:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6LEPwRw020348 for ; Sun, 21 Jul 2002 07:25:59 -0700 Received: (qmail 29940 invoked by uid 1010); 21 Jul 2002 14:26:45 -0000 Received: from unknown (HELO athlet) ([195.158.156.114]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 21 Jul 2002 14:26:45 -0000 Date: Sun, 21 Jul 2002 16:27:09 +0200 From: thomas X-Mailer: The Bat! (v1.60) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <18964124956.20020721162709@ff33.cc> To: linux-xfs@oss.sgi.com Subject: Re: data recovery after hdd failure In-Reply-To: <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> References: <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk here is some update: i dd'ed hdc2 (the xfs partition, that was hdc5 originally) to /dev/hda5 and luckily there were only a few bad blocks. so i began the recovery process, with no luck so far, maybe some can put some insight into this output, it would be much appreciated. +:~# xfs_check /dev/hda5 bad magic # 0x1dae3fd0 in inode 280 bmbt block 1/618521 expected level 0 got 25074 in inode 280 bmbt block 1/618521 bad btree nrecs (33556, min=127, max=254) in inode 280 bmap block 1667097 extent count for ino 280 data fork too low (0) for file format bad nblocks 192516 for inode 280, counted 1 bad nextents 10 for inode 280, counted 0 bad directory data magic # 0xc7beef5c for dir ino 1376607 block 0 no . entry for directory 1376607 no .. entry for directory 1376607 ... ... bad sb magic # 0 in ag 1 bad sb version # 0 in ag 1 bad agf magic # 0 in ag 1 bad agf version # 0 in ag 1 bad agi magic # 0 in ag 1 bad agi version # 0 in ag 1 ... ... bad sb magic # 0x68 in ag 9 bad sb version # 0xffff in ag 9 bad agf magic # 0x68 in ag 9 bad agf version # 0 in ag 9 bad agi magic # 0x68 in ag 9 bad agi version # 0x4f0 in ag 9 /usr/sbin/xfs_check: line 62: 11115 Segmentation fault xfs_db$ISFILE -i -p xfs_check -c "check$OPTS" $1 so this thing at least still gets recognized as a xfs partition. however it segfaults after ~400 lines of output. +:~# xfs_repair -n /dev/hda5 Phase 1 - find and verify superblock... couldn't verify primary superblock - not enough secondary superblocks with matching geometry !!! attempting to find secondary superblock........ and this goes on for a while, xfs_repair finds about 15 secondary superblocks but cant verify any of them. so it exits with no result. +:~# od -c /dev/hda5 | less 0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 001 035 M 263 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 267 022 226 276 031 ) L - 263 327 < 367 316 261 345 4 0000060 \0 \0 \0 \0 \0 220 \0 004 \0 \0 \0 \0 \0 \0 \0 200 0000100 \0 \0 \0 \0 \0 \0 \0 201 \0 \0 \0 \0 \0 \0 \0 202 0000120 \0 \0 \0 020 \0 020 \0 \0 \0 \0 \0 022 \0 \0 \0 \0 0000140 \0 \0 \b 352 204 002 \0 001 \0 \0 020 \0 \0 \0 \0 0000160 \0 \0 \0 \0 \0 \0 \0 \0 \f \t \b 004 024 \0 \0 031 0000200 \0 \0 \0 \0 \0 \0 200 300 \0 \0 \0 \0 \0 \0 C 335 0000220 \0 \0 \0 \0 \0 5 z } \0 \0 \0 \0 \0 \0 \0 \0 0000240 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000260 \0 \0 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 0000300 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001000 X A G F \0 \0 \0 001 \0 \0 \0 \0 \0 020 \0 \0 0001020 \0 \0 \0 001 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 0001040 \0 \0 \0 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 003 0001060 \0 \0 \0 004 \0 002 036 r \0 001 006 344 \0 \0 \0 \0 0001100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0002000 X A G I \0 \0 \0 001 \0 \0 \0 \0 \0 020 \0 \0 0002020 \0 \0 \a \0 \0 \0 \0 003 \0 \0 \0 001 \0 \0 004 ~ 0002040 \0 $ + 300 377 377 377 377 377 377 377 377 377 377 377 377 0002060 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 so the geometry seems to be right, the partition starts with the xfs superblock. why is the recovery not working then? is there sth. i can do to help xfs_repair? again any input is much appreciated :) thomas ps. since i'm not subscribed i really hope this shows up right on the list. From owner-linux-xfs@oss.sgi.com Sun Jul 21 08:01:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6LF1YRw020765 for ; Sun, 21 Jul 2002 08:01:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6LF1Ypo020764 for linux-xfs-outgoing; Sun, 21 Jul 2002 08:01:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6LF1SRw020735 for ; Sun, 21 Jul 2002 08:01:29 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6LF2Flr027531; Sun, 21 Jul 2002 17:02:15 +0200 (CEST) Message-Id: <4.3.2.7.2.20020721170008.037b6810@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 21 Jul 2002 17:00:48 +0200 To: thomas , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: data recovery after hdd failure In-Reply-To: <18964124956.20020721162709@ff33.cc> References: <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:27 21-7-2002 +0200, thomas wrote: >here is some update: >/usr/sbin/xfs_check: line 62: 11115 Segmentation fault xfs_db$ISFILE >-i -p xfs_check -c "check$OPTS" $1 Fetch newer tools from CVS. That might help alot. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sun Jul 21 08:54:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6LFsNRw021232 for ; Sun, 21 Jul 2002 08:54:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6LFsNwe021231 for linux-xfs-outgoing; Sun, 21 Jul 2002 08:54:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6LFsHRw021203 for ; Sun, 21 Jul 2002 08:54:18 -0700 Received: (qmail 2373 invoked by uid 1010); 21 Jul 2002 15:55:04 -0000 Received: from unknown (HELO athlet) ([195.158.156.114]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 21 Jul 2002 15:55:04 -0000 Date: Sun, 21 Jul 2002 17:55:26 +0200 From: thomas X-Mailer: The Bat! (v1.60) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <17969422374.20020721175526@ff33.cc> To: linux-xfs@oss.sgi.com Subject: Re: data recovery after hdd failure In-Reply-To: <4.3.2.7.2.20020721170008.037b6810@pop.xs4all.nl> References: <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> <4.3.2.7.2.20020721170008.037b6810@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Fetch newer tools from CVS. That might help alot. got 2.1.12 from the 2.4 cvs tree, unfortunately they show the same behaviour. thomas From owner-linux-xfs@oss.sgi.com Sun Jul 21 18:19:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6M1JFRw030547 for ; Sun, 21 Jul 2002 18:19:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6M1JFlt030546 for linux-xfs-outgoing; Sun, 21 Jul 2002 18:19:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from creon.profinet.sk (creon.profinet.sk [195.46.64.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6M1J0Rw030508 for ; Sun, 21 Jul 2002 18:19:01 -0700 Received: from host.sk (localhost.localdomain [127.0.0.1]) by creon.profinet.sk (Postfix) with ESMTP id 0948921EF11 for ; Mon, 22 Jul 2002 03:19:48 +0200 (CEST) From: "Stephane Poinsart" To: linux-xfs@oss.sgi.com Subject: xfs_repair problem 2 Date: Mon, 22 Jul 2002 02:19:48 +0100 Message-Id: <20020722011948.M55523@host.sk> X-Mailer: Open WebMail 1.70 20020710 X-OriginatingIP: 129.175.254.5 (sart) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I had a problem with the xfs_repair program, and seen the same in the mailing list archive. Here are the headers of this message : To: linux-xfs@oss.sgi.com Subject: xfs_repair problem From: Benito Venegas Date: Thu, 14 Mar 2002 11:55:14 -0500 URL : http://oss.sgi.com/projects/xfs/mail_archive/200203/msg00277.html If the problem have been fixed in CVS or in xfs_repair > 2.0.3, please ignore my message. (there was no valuable data on my system) after a power faillure when my PC was booting, my xfs 1.1 partition on my gentoo 1.2 i686 system get corrupted. after that, when I tryed to list or use the /etc directory, this crash the system without any message or log. When I tried to use xfs_repair, it leads to a "Fatal error". After the fisrt xfs_repair, a few error have been fixed, but it stop with a fatal error, and my /etc directory have disapeard. Here is the output when I rerun xfs_repair now : # xfs_repair /dev/hda3 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 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 128 - traversal finished ... - traversing all unattached subtrees ... fatal error -- can't read block 0 for directory inode 16909320 In the "Benito Venegas" message, you say that xfs_repair is probably runing out of memory. I have 256Mb of physical ram, and 256Mb of swap. Isn't that enough ? (my xfs partition is about 4.4 Gb, 97% used). thanks, and I hope this will help to correct the bug if there is one. -- Stéphane Poinsart (sart@host.sk) http://www.sart.host.sk From owner-linux-xfs@oss.sgi.com Sun Jul 21 19:29:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6M2TDRw008172 for ; Sun, 21 Jul 2002 19:29:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6M2TDNb008171 for linux-xfs-outgoing; Sun, 21 Jul 2002 19:29:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from paelxms1.vant.com.br (smtp.160.225.200.in-addr.arpa [200.225.160.33] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6M2T3Rw008143 for ; Sun, 21 Jul 2002 19:29:05 -0700 Received: from inf.ufrgs.br (paeig48.vant.com.br [200.225.166.233]) by paelxms1.vant.com.br (8.9.3/linuxconf) with ESMTP id XAA07755; Sun, 21 Jul 2002 23:29:51 -0300 Message-ID: <3D3B6F73.F10018E9@inf.ufrgs.br> Date: Sun, 21 Jul 2002 23:35:31 -0300 From: root X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13SGI_XFS_1.0.2 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Fault injection on XFS filesystems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, At first, i hope that you could excuse cause my english isn't better - but i'm brazilian, and here we talk in portuguese. I am a fault tolerance graduate student, and my work deals with development of fault injection techniches and tools for aspects related with Linux operating systems. Recently one of my dear colleagues, Mr F'abio Olive (by Conectiva Linux distro), presented his works in the 8th International Linux-Kongress, on Netherlands - talking about one fault injection tool for communications systems, using Netfilter. And i, by the way, are interested on XFS because my research sub-topic are the journaling filesystems ;-) Please, could you tell me what aspects you think that should be more interesting for a fault injection tool? I think that XFS is the best of the journaling filesystems that exists - rather than ext3, jfs. So, in despite of my opinion, i think that it could (and should) be proved under an academic point-of-view. I wanna know what you think that should be tested more carefully? What part you think that has more problems (solved and pending)?? I've seen mailing list archive, describing problems (which are solved very quickly, congratulations by that), but know i 'm accepting suggestions. My scenario is considering a RedHat 7.2 installed using the SGI cd-rom installer, and recompiled with XFS 1.1 to enable the CONFIG_XFS_DEBUG on kernel. I've been installed the latest version of tools (xfsdump, xfs_repair, etc)available on the FTP website. I don't made any synchronization with CVS. Finally, my congratulations for all by the well done work. I think that SGI made a great contribution to open-source world wide community licensing the XFS filesystem under GPL. ;-) Cheers, Leonardo Mello From owner-linux-xfs@oss.sgi.com Mon Jul 22 07:25:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6MEPMRw024523 for ; Mon, 22 Jul 2002 07:25:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6MEPM5r024522 for linux-xfs-outgoing; Mon, 22 Jul 2002 07:25:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6MEPDRw024493 for ; Mon, 22 Jul 2002 07:25:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA90217 for ; Mon, 22 Jul 2002 09:26:00 -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 JAA07213; Mon, 22 Jul 2002 09:25:59 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6MEO0a25240; Mon, 22 Jul 2002 09:24:00 -0500 Message-Id: <200207221424.g6MEO0a25240@stout.americas.sgi.com> Date: Mon, 22 Jul 2002 09:24:00 -0500 Subject: TAKE - remove kdev_t abuse from XFS X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From Christoph: "XFS already uses struct block_device for kernel interfaces where possible. In addition there are lots of places where device numbers are passed around in XFS, currently these are kdev_ts. They should be dev_t though so this patch changes over most places to use dev_t instead of kdev_t. The only place XFS still deals with kdev_t is inode->i_rdev, a VFS interface that will change to dev_t in late 2.5. I will also send a 2.4 sycnup patch that adds a kdev_t back to struct pb_target for the 2.4 VFS interfaces that still want it." remove kdev_t abuse from XFS Date: Mon Jul 22 07:24:36 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:123447a linux/fs/xfs/xfsidbg.c - 1.193 linux/fs/xfs/xfs_rw.c - 1.363 linux/fs/xfs/xfs_buf.h - 1.94 linux/fs/xfs/xfs_buf_item.c - 1.128 linux/fs/xfs/xfs_da_btree.h - 1.45 linux/fs/xfs/xfs_vnodeops.c - 1.543 linux/fs/xfs/xfs_rtalloc.c - 1.76 linux/fs/xfs/xfs_dmapi.c - 1.77 linux/fs/xfs/xfs_qm_syscalls.c - 1.65 linux/fs/xfs/xfs_log_recover.c - 1.239 linux/fs/xfs/xfs_vfsops.c - 1.361 linux/fs/xfs/xfs_dquot.c - 1.67 linux/fs/xfs/xfs_mount.h - 1.151 linux/fs/xfs/xfs_mount.c - 1.296 linux/fs/xfs/xfs_qm.c - 1.79 linux/fs/xfs/xfs_error.h - 1.27 linux/fs/xfs/xfs_fsops.c - 1.83 linux/fs/xfs/xfs_trans_buf.c - 1.104 linux/fs/xfs/linux/xfs_linux.h - 1.82 linux/fs/xfs/linux/xfs_super.h - 1.25 linux/fs/xfs/linux/xfs_super.c - 1.209 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.20 linux/fs/xfs/pagebuf/page_buf.h - 1.31 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.13 From owner-linux-xfs@oss.sgi.com Mon Jul 22 09:37:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6MGbvRw026979 for ; Mon, 22 Jul 2002 09:37:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6MGbvfb026978 for linux-xfs-outgoing; Mon, 22 Jul 2002 09:37:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6MGbnRw026950 for ; Mon, 22 Jul 2002 09:37:50 -0700 Received: from idcomm.com (IDENT:+kjV6iRBMl5mI4yhvJJ81PY0S+oQMXu7@tnt01-ppp-213.idcomm.com [216.98.194.213]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g6MGe4l14405 for ; Mon, 22 Jul 2002 10:40:04 -0600 Message-ID: <3D3C3528.3020709@idcomm.com> Date: Mon, 22 Jul 2002 10:39:04 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re [follow-up note]: TAKE - fix pagebuf locking bug References: <3D3729D1.CDDED1C1@idcomm.com> <1027347486.25120.1.camel@stout.americas.sgi.com> <3D3C25D5.9010009@idcomm.com> <1027351954.25130.12.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just to let everyone know, I had posted a message about a stall during large directory/file copy between ext2 and XFS earlier, using cvs 2.4.19-rc1-xfs. This turned out with a happy ending: within the 2.8 GB of files were some device special files, which cp does not know how to copy (e.g., how large is /dev/random and /dev/urandom?), and the cause was neither a bug nor in any way related to XFS. Use of find with cpio solved the problem, since this does not try to copy contents of device special files. D. Stimits, stimits @ idcomm.com From owner-linux-xfs@oss.sgi.com Mon Jul 22 09:50:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6MGoNRw027345 for ; Mon, 22 Jul 2002 09:50:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6MGoMaY027344 for linux-xfs-outgoing; Mon, 22 Jul 2002 09:50:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6MGoCRw027315 for ; Mon, 22 Jul 2002 09:50:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA94008 for ; Mon, 22 Jul 2002 11:50:59 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA96615 for ; Mon, 22 Jul 2002 11:50:59 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6MGmxH17865; Mon, 22 Jul 2002 11:48:59 -0500 Message-Id: <200207221648.g6MGmxH17865@stout.americas.sgi.com> Date: Mon, 22 Jul 2002 11:48:59 -0500 Subject: TAKE - rework of inode-related core changes X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More from Christoph: "Currently XFS has a bunch of inode-handling related changes in fs/inode.c, include/linux/fs.h and kernel/ksysm.c. There changes do: * add struct xfs_inode_info to struct inode * add a new function icreate() that is iget() without unlocking and an additional gfp_mask parameter passed down to alloc_inode() The first patch is already in Red Hat's current beta kernel and implements ->alloc_inode/->destroy_inode superblock methods to let the fs control inode allocation and store it's own inode data in the same slab object. This one is from Al Viro and thus very likely to go in. The second patch is from me and a backport of the iget_locked functionality from 2.5. It requires the above patch to get the gfp mask right. It might also go in the Red Hat 8.0 tree as it helps their new AFS client. Alltogether we have a slight increase of core changes, but these are a) much more likely to be merged and b) allow to make XFS for 2.4 and 2.5 _much_ more similar." So, fingers crossed that these really do hit Marcello's kernel, if not we can always revert or change any of it. rework of inode-related core changes Date: Mon Jul 22 09:43:26 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123456a linux/net/socket.c - 1.29 linux/kernel/ksyms.c - 1.130 linux/include/linux/fs.h - 1.156 linux/fs/super.c - 1.77 linux/fs/inode.c - 1.64 linux/fs/xfs/xfs_iget.c - 1.166 linux/fs/xfs/linux/xfs_linux.h - 1.79 linux/fs/xfs/linux/xfs_vnode.c - 1.89 linux/fs/xfs/linux/xfs_super.c - 1.195 linux/include/linux/behavior.h - 1.5 linux/include/linux/vnode.h - 1.8 linux/fs/xfs/linux/xfs_vnode.h - 1.51 linux/fs/xfs/linux/xfs_behavior.h - 1.8 From owner-linux-xfs@oss.sgi.com Mon Jul 22 11:06:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6MI6lRw028466 for ; Mon, 22 Jul 2002 11:06:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6MI6lfY028465 for linux-xfs-outgoing; Mon, 22 Jul 2002 11:06:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6MI6bRw028432 for ; Mon, 22 Jul 2002 11:06:37 -0700 Received: from fnal.gov ([131.225.7.82]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GZN00EBHX0HXX@smtp.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 22 Jul 2002 13:07:29 -0500 (CDT) Date: Mon, 22 Jul 2002 13:07:29 -0500 From: Dan Yocum Subject: Re: Who's using XFS? (again) To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Message-id: <3D3C49E1.8070504@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020618 References: <1027117051.12810.74.camel@stout.americas.sgi.com> X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We're up to, uhhhhh.... (2 * 1.39) + (8 * 1.12) + (4 * 1.67) = 18.42TB, and we'll buy another 10-12TB or so next fiscal year. So, go ahead and change our statement thusly: "...with EIDE disks configured as RAID50 arrays using XFS. Currently, 14 machines are in production accounting for over 18TB. By the scheduled end of the survey in 2005, 50TB of XFS disks will be online serving SDSS data to collaborators and the public." The CDF guys have 32.6TB now as a test bed, and are working on moving that up to 100-200TB Real Soon Now(tm). I'll ask them to send you a "statement." Cheers, Dan Eric Sandeen wrote: > Hi all - > > I've been asked to take another pulse of the XFS user community; we did > this a while ago, and the results are at > http://oss.sgi.com/projects/xfs/xfs_users.html > > If you're using XFS in an interesting/large/impressive/unique > installation, or your company is shipping a product using XFS (and you > can go on the record about it*) I'd like to know, so I can update the > information in the above web page. > > Rumor has it that Linus didn't think very many people were using XFS; > perhaps I'll point him at this page when it's updated. :) > > Thanks, > > -Eric > > *If you can't go on the record, feel free to drop me an off-the-record > note. :) > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Mon Jul 22 11:34:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6MIYgRw031902 for ; Mon, 22 Jul 2002 11:34:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6MIYgee031901 for linux-xfs-outgoing; Mon, 22 Jul 2002 11:34:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6MIYWRw031872 for ; Mon, 22 Jul 2002 11:34:33 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA90669 for ; Mon, 22 Jul 2002 13:35:20 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA15131 for ; Mon, 22 Jul 2002 13:35:20 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6MIXJL25386; Mon, 22 Jul 2002 13:33:19 -0500 Message-Id: <200207221833.g6MIXJL25386@stout.americas.sgi.com> Date: Mon, 22 Jul 2002 13:33:19 -0500 Subject: TAKE - remove kdev_t abuse from (2.4) XFS X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Same as the last one, but for 2.4 kernel remove kdev_t abuse from XFS Date: Mon Jul 22 11:34:31 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123471a linux/fs/xfs/xfsidbg.c - 1.190 linux/fs/xfs/xfs_rw.c - 1.360 linux/fs/xfs/xfs_buf.h - 1.91 linux/fs/xfs/xfs_buf_item.c - 1.125 linux/fs/xfs/xfs_da_btree.h - 1.45 linux/fs/xfs/xfs_vnodeops.c - 1.543 linux/fs/xfs/xfs_rtalloc.c - 1.76 linux/fs/xfs/xfs_dmapi.c - 1.72 linux/fs/xfs/xfs_qm_syscalls.c - 1.65 linux/fs/xfs/xfs_log_recover.c - 1.238 linux/fs/xfs/xfs_vfsops.c - 1.361 linux/fs/xfs/xfs_dquot.c - 1.67 linux/fs/xfs/xfs_mount.h - 1.152 linux/fs/xfs/xfs_mount.c - 1.292 linux/fs/xfs/xfs_qm.c - 1.79 linux/fs/xfs/xfs_error.h - 1.27 linux/fs/xfs/xfs_fsops.c - 1.83 linux/fs/xfs/xfs_trans_buf.c - 1.102 linux/fs/xfs/linux/xfs_linux.h - 1.80 linux/fs/xfs/linux/xfs_super.h - 1.25 linux/fs/xfs/linux/xfs_super.c - 1.196 linux/fs/xfs/pagebuf/page_buf_io.c - 1.51 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.20 linux/fs/xfs/pagebuf/page_buf.c - 1.43 linux/fs/xfs/pagebuf/page_buf.h - 1.27 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.12 From owner-linux-xfs@oss.sgi.com Mon Jul 22 13:50:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6MKoPRw006499 for ; Mon, 22 Jul 2002 13:50:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6MKoPQg006498 for linux-xfs-outgoing; Mon, 22 Jul 2002 13:50:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6MKoJRw006470 for ; Mon, 22 Jul 2002 13:50:19 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA90740 for ; Mon, 22 Jul 2002 15:51:07 -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 PAA56578 for ; Mon, 22 Jul 2002 15:51:07 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6MKn5w11337; Mon, 22 Jul 2002 15:49:05 -0500 Message-Id: <200207222049.g6MKn5w11337@stout.americas.sgi.com> Date: Mon, 22 Jul 2002 15:49:05 -0500 Subject: TAKE - kill LINVFS_GET_VPTR X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More from Christoph: this macro was used only to hide 2.4/2.5 differences and is now obsolete. This patch gives a few rejects against 2.5 that can safely be ignored. kill LINVFS_GET_VPTR Date: Mon Jul 22 13:50:38 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123488a linux/fs/xfs/xfsidbg.c - 1.191 linux/fs/xfs/xfs_vnodeops.c - 1.544 linux/fs/xfs/xfs_iget.c - 1.167 linux/fs/xfs/xfs_utils.c - 1.49 linux/fs/xfs/linux/xfs_file.c - 1.75 linux/fs/xfs/linux/xfs_vnode.c - 1.90 linux/fs/xfs/linux/xfs_super.c - 1.197 linux/fs/xfs/linux/xfs_iops.c - 1.165 linux/fs/xfs/linux/xfs_ioctl.c - 1.69 linux/fs/xfs/linux/xfs_vnode.h - 1.52 linux/fs/xfs/linux/xfs_xattr.c - 1.19 From owner-linux-xfs@oss.sgi.com Mon Jul 22 14:51:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6MLpXRw007179 for ; Mon, 22 Jul 2002 14:51:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6MLpXaJ007178 for linux-xfs-outgoing; Mon, 22 Jul 2002 14:51:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6MLpQRw007148 for ; Mon, 22 Jul 2002 14:51:26 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA92441 for ; Mon, 22 Jul 2002 16:52:14 -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 QAA59863 for ; Mon, 22 Jul 2002 16:52:14 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6MLoCs17381; Mon, 22 Jul 2002 16:50:12 -0500 Message-Id: <200207222150.g6MLoCs17381@stout.americas.sgi.com> Date: Mon, 22 Jul 2002 16:50:12 -0500 Subject: TAKE - kill LINVFS_GET_VPTR in 2.5 X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk kill LINVFS_GET_VPTR Date: Mon Jul 22 14:50:44 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea Author: sandeen Merged by: sandeen Merged mods: 2.4.x-xfs:slinx:123488a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:123488a linux/fs/xfs/xfsidbg.c - 1.194 linux/fs/xfs/xfs_vnodeops.c - 1.544 linux/fs/xfs/xfs_iget.c - 1.167 linux/fs/xfs/xfs_utils.c - 1.49 linux/fs/xfs/linux/xfs_file.c - 1.75 linux/fs/xfs/linux/xfs_vnode.c - 1.92 linux/fs/xfs/linux/xfs_super.c - 1.210 linux/fs/xfs/linux/xfs_iops.c - 1.169 linux/fs/xfs/linux/xfs_ioctl.c - 1.76 linux/fs/xfs/linux/xfs_vnode.h - 1.54 linux/fs/xfs/linux/xfs_xattr.c - 1.21 - Merge of 2.4.x-xfs:slinx:123488a by sandeen. From owner-linux-xfs@oss.sgi.com Mon Jul 22 18:46:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6N1kURw009486 for ; Mon, 22 Jul 2002 18:46:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6N1kTCa009485 for linux-xfs-outgoing; Mon, 22 Jul 2002 18:46:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6N1kKRw009457 for ; Mon, 22 Jul 2002 18:46:20 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.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 SAA09791 for ; Mon, 22 Jul 2002 18:47:12 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA06099; Tue, 23 Jul 2002 11:45:54 +1000 (AEST) Date: Tue, 23 Jul 2002 11:45:54 +1000 From: Tim Shimmin To: lgs@slab.de Cc: linux-xfs@oss.sgi.com Subject: problems with restore Message-ID: <20020723114554.J2935839@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Lars, You wrote on 10 Jul 2002: > XFS version: SGI_XFS_1.0.2 > Tape Drive: Tandberg SLR100 > ... > I am using XFS since version 1.0 and I am quite satisfied. I have one > peeve, that xfsdump/restore are a bit too complicated to use: It seems > impossible to restore a tape that I have copied file by file > to a harddisk without tweaking the source to xfsrestore. xfsrestore also > aborts with an assertion failure when I try to restore directly from > the tape. 1. I don't believe that xfsdump/restore is too complicated to use. It has an awful lot of options (I agree) but there are examples on what ones are needed to get a basic dump and restore happening: check out the examples sections in: - cmd/xfsdump/doc/README.xfsdump - xfsdump(8) and xfsrestore(8) man pages 2. xfsdump uses different formats for dumping to a tape than dumping to a file. A tape dump format has multiple media files (mini self contained dumps) and tape record headers, which provide redundant information in order to provide better chances for restoring stuff when only part of a tape has errors on it (I believe that's the idea anyway). So one is not supposed to copy a dump from tape onto a disk file and then restore it. After the "strategy" type (tape or file format) is chosen, it checks on restore to make sure the dump is of the correct matching strategy. 3. I don't know why xfsrestore is aborting with an assertion failure for you. You'll need to post: - the output from "mt status" - the command line used for xfsrestore - final verbose output from xfsrestore (e.g. -v5) - the actual assert message Some possibilites: - Some tape drives can be considered like QIC tape drives (check output from "mt status") and need the -q option. - There have been some fixes for asserts in recent times so it may be of use to get the latest xfsdump/restore from CVS. (Check out cmd/xfsdump/doc/CHANGES for info) Please post to linux-xfs@oss.sgi.com for xfsdump queries. Cheers, --Tim From owner-linux-xfs@oss.sgi.com Tue Jul 23 05:34:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NCYiRw024955 for ; Tue, 23 Jul 2002 05:34:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NCYi5F024954 for linux-xfs-outgoing; Tue, 23 Jul 2002 05:34:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NCYNRw024912 for ; Tue, 23 Jul 2002 05:34:23 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 775C4C23A; Tue, 23 Jul 2002 14:09:08 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA25573; Tue, 23 Jul 2002 14:09:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A36D457306; Tue, 23 Jul 2002 14:08:20 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id EB24D25835; Tue, 23 Jul 2002 14:08:19 +0200 (CEST) Message-ID: <3D3D4731.F7287924@ch.sauter-bc.com> Date: Tue, 23 Jul 2002 14:08:17 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Austin Gonyou Cc: Poul Petersen , linux-xfs@oss.sgi.com Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops References: <1027110594.6686.19.camel@UberGeek> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Austin Gonyou schrieb: > > Just as a point of note. We run twelve 2550's in production taking ~75 > to 100million hits/day. We run *nothing* but XFS. Also, just recently I > brought up a 6650, P4 box, and run only XFS there as well. One thing I > always do though, and is a good idea, is to use the -aa tree. It has XFS > support, no code changes, just incorporation, as well as lots of other > goodies for good systems like this. > > Of note at this time on the 6650, I'm running 2.4.19-rc2-aa1. > In production it's 2.4.10 + xfs patches. With all honesty, it has been > "uberstable" besides a couple of issues we've had, but that was our own > stupidity, and nothing to do with XFS or hardware. (qlogic stuff) Another source for good kernels are the one RedHat provides. They include lots of patches which you may need while still being stable. The only problem I found was that they refuse to include XFS till now. I'm running many servers with the XFS enabled RH 2.4.9-XX kernels without any problems and with months of uptime, although they are not so heavy loadedservers. I was able to crash any 2.4.5-XFS kernel within minutes with some simple scripts but that's gone and I'm very happy with it. Simon > > > Last XFS config: > > > > Dell 2550 Dual P-III (Coppermine) 933 MHz > > 1 GB Ram > > 1 9GB internal disk, aic7xxx driver (kernel) > > RedHat 7.2 > > kernel 2.4.18 + XFS 1.1 (and xfs tools) > > nfsutils-0.3.3 > > Qlogic 2200 SAN Adaptor firmware 2.02.01 running Qlogic driver 6.0b20 > > Intel PRO/1000 Gig-Fiber running Intel e1000 driver 4.0.7 > > Zzyzx RocketStor 2000 Raid Head > > Qlogic SAN box (Isolated Hard segment between file-server and Zzyzx) > > Are you running this server specifically for NFS purposes? If so, you > might want to try the latest CVS, as well as looking at using the -aa > tree. Personally, I love XFS for what it does. It's been the most > resiliant, and stable FS we've run, not in the kernel tree. > > -- > Austin Gonyou > Coremetrics, Inc. > > ------------------------------------------------------------------------ > Name: signature.asc > signature.asc Type: application/pgp-signature > Description: This is a digitally signed message part From owner-linux-xfs@oss.sgi.com Tue Jul 23 05:51:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NCpMRw025439 for ; Tue, 23 Jul 2002 05:51:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NCpMej025438 for linux-xfs-outgoing; Tue, 23 Jul 2002 05:51:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NCp4Rw025401 for ; Tue, 23 Jul 2002 05:51:05 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 93F78C2B8; Tue, 23 Jul 2002 14:28:40 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA26939; Tue, 23 Jul 2002 14:28:39 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id B564A57306; Tue, 23 Jul 2002 14:20:15 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 0C23E25835; Tue, 23 Jul 2002 14:20:15 +0200 (CEST) Message-ID: <3D3D49FE.EC788195@ch.sauter-bc.com> Date: Tue, 23 Jul 2002 14:20:14 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Jurgen Kramer Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Who's using XFS? (again) References: <1027117051.12810.74.camel@stout.americas.sgi.com> <1027247105.1110.1.camel@paragon.slim> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jurgen Kramer schrieb: > > >Rumor has it that Linus didn't think very many people were using XFS; My boss didn't want us to use Linux because he didn't think very many people were using Linux :) > >perhaps I'll point him at this page when it's updated. :) > > Hmm this can be a problem. A lot of people are probably not using XFS > because it is not in the standard kernel..:-( > > Cheers, > > Jurgen From owner-linux-xfs@oss.sgi.com Tue Jul 23 06:45:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NDjWRw026609 for ; Tue, 23 Jul 2002 06:45:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NDjWx1026608 for linux-xfs-outgoing; Tue, 23 Jul 2002 06:45:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NDjQRw026580 for ; Tue, 23 Jul 2002 06:45:27 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6NDkFgH097678; Tue, 23 Jul 2002 15:46:15 +0200 (CEST) Message-Id: <4.3.2.7.2.20020723154437.03ae2018@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jul 2002 15:45:05 +0200 To: Simon Matter , Jurgen Kramer From: Seth Mos Subject: Re: Who's using XFS? (again) Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3D3D49FE.EC788195@ch.sauter-bc.com> References: <1027117051.12810.74.camel@stout.americas.sgi.com> <1027247105.1110.1.camel@paragon.slim> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:20 23-7-2002 +0200, Simon Matter wrote: >Jurgen Kramer schrieb: > > > > >Rumor has it that Linus didn't think very many people were using XFS; > >My boss didn't want us to use Linux because he didn't think very many >people were using Linux :) 3% percent of 500 Million is still a lot. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Jul 23 07:11:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NEAxRw027149 for ; Tue, 23 Jul 2002 07:11:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NEAxqE027148 for linux-xfs-outgoing; Tue, 23 Jul 2002 07:10:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from issv0170.isis.de (issv0170.isis.de [195.158.131.222]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NEAmRw027119 for ; Tue, 23 Jul 2002 07:10:49 -0700 Received: (qmail 24409 invoked by uid 1010); 23 Jul 2002 14:11:42 -0000 Received: from unknown (HELO ATHLET) ([195.158.137.161]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 23 Jul 2002 14:11:42 -0000 Date: Tue, 23 Jul 2002 16:12:05 +0200 From: thomas X-Mailer: The Bat! (v1.60) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <12310497033.20020723161205@ff33.cc> To: linux-xfs@oss.sgi.com Subject: Re: data recovery after hdd failure In-Reply-To: <4.3.2.7.2.20020721170008.037b6810@pop.xs4all.nl> References: <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> <4.3.2.7.2.20020721170008.037b6810@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk i found out that the last dd i did was incomplete, so i did a new one (which took over 24h) and there were more bad blocks than i thought before. about 1-2% of the hdd are bad blocks. i got xfs_check to work now (xfs_ncheck still segfaults though), but things don't look too got. it complains on every block: ... block 10/5704 out of range block 10/5705 out of range block 10/5706 out of range ... what does that mean? it's not mentioned in the manpage. xfs_repair still doesn't work, finds many secondary superblocks but can't verify them. when i try to mount the fs i get: Jul 23 15:17:40 knecht kernel: XFS mounting filesystem ide0(3,5) Jul 23 15:17:40 knecht kernel: XFS: Log inconsistent or not a log (last==0, first!=1) Jul 23 15:17:40 knecht kernel: XFS: empty log check failed Jul 23 15:17:40 knecht kernel: XFS: log mount/recovery failed Jul 23 15:17:40 knecht kernel: XFS: log mount failed anyone got some ideas what i can do? i thought maybe the dd options weren't correct, i used: dd conv=noerror /dev/hda5 now i found the following in the dd manpage: sync pad every input block with NULs to ibs-size; when used maybe that'd be a good idea. what is the standard xfs blocksize, 4096 no? that'd be dd conv=noerror,sync bs=4096 /dev/hda5 it would actually help me a lot already if i'd just get the filenames and directory structure out of the partition, is there some way to do this besides xfs_ncheck? can anyone comment on this? help much appreciated :) thomas From owner-linux-xfs@oss.sgi.com Tue Jul 23 07:16:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NEGJRw027421 for ; Tue, 23 Jul 2002 07:16:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NEGIkB027420 for linux-xfs-outgoing; Tue, 23 Jul 2002 07:16:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.89.54]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NEG2Rw027390 for ; Tue, 23 Jul 2002 07:16:03 -0700 Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id g6NEGup21746; Tue, 23 Jul 2002 16:16:56 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15677.25943.919190.769477@slime.wu-wien.ac.at> Date: Tue, 23 Jul 2002 16:16:55 +0200 To: linux-xfs@oss.sgi.com Subject: xfs and openafs problem In-Reply-To: References: X-Mailer: VM 7.06 under Emacs 21.2.1 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! A few days ago, Jeffrey E. Hundstad wrote: > It's too bad that XFS is losing people. I agree with that! However, we could be in a situation, where nothing else remains... :-( As Alexander Bergolth wrote on July 15, we found a problem creating large files when using OpenAFS (no answeres yet): http://marc.theaimsgroup.com/?l=linux-xfs&m=102675120214280&w=2 In short: When using Distribution: XFS-RH 7.3 Kernel: kernel-2.4.18-4SGI_XFS_1.1 AFS: openafs-1.2.5-rh7.3.1 writing largs files (ie the following command) hangs in the "close" syscall: head -c 700000000 /dev/zero > testfile We tried 3 differnt boxes, everyone showed the same. strace of the file writing process yields: [] truncate_list_pages [kernel] 0x1f6 [] truncate_inode_pages [kernel] 0x3b [] xfs_itruncate_start [kernel] 0x74 [] xfs_inactive_free_eofblocks [kernel] 0x1c4 [] xfs_release [kernel] 0x97 [] linvfs_release [kernel] 0x20 [] fput [kernel] 0x4d [] filp_close [kernel] 0x53 [] sys_close [kernel] 0x43 [] system_call [kernel] 0x33 strace of the AFS daemon: [] schedule_timeout [kernel] 0x14 [] ll_copy_to_user [kernel] 0x38 [] wait_for_packet [kernel] 0xe6 [] skb_recv_datagram [kernel] 0xb0 [] udp_recvmsg [kernel] 0x59 [] __make_request [kernel] 0x25c [] inet_recvmsg [kernel] 0x39 [] sock_recvmsg [kernel] 0x31 [] xfs_bmbt_get_state [kernel] 0x25 [] xfs_bmap_do_search_extents [kernel] 0x348 [] osi_NetReceive [libafs-2.4.18-4SGI_XFS_1.1-i686] 0xbd [] xfs_bmap_search_extents [kernel] 0x48 [] __wake_up [kernel] 0x32 [] afs_osi_Wakeup [libafs-2.4.18-4SGI_XFS_1.1-i686] 0xe [] rxi_AllocDataBuf [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x2d [] rxk_ReadPacket [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x95 [] rxk_Listener [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x6e [] afs_syscall_call [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x15e [] afs_RX_Running [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x0 [] xfs_bmbt_get_state [kernel] 0x25 [] xfs_bmap_do_search_extents [kernel] 0x2b6 [] xfs_bmap_search_extents [kernel] 0x48 [] xfs_bmapi [kernel] 0x34b [] ide_dmaproc [kernel] 0x1ec [] generic_unplug_device [kernel] 0x1e [] filemap_nopage [kernel] 0xbc [] __alloc_pages [kernel] 0x75 [] page_remove_rmap [kernel] 0x5d [] do_wp_page [kernel] 0x229 [] handle_mm_fault [kernel] 0x106 [] do_page_fault [kernel] 0x12a [] afs_syscall [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x10b [] sys_setpriority [kernel] 0x60 [] system_call [kernel] 0x33 Kernel 2.4.9-21SGI_XFS_1.0.2 seems to work fine with AFS (no hangs). Also, any other filesystem we tried (ext2, ext3) didn't show this effect. Has anybody an idea what this could be? What can we do to find out? We are willing to make any test in that matter, but we don't know how to start. AFS is a requirement on our campus, so we cannot abandon it. We would be very unhappy if we had to abandon xfs, becaus we think it's the best filesystem for linux! In any case, thank you _very_ much for your work on xfs! \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/9207 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Jul 23 07:18:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NEIkRw027688 for ; Tue, 23 Jul 2002 07:18:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NEIkvH027687 for linux-xfs-outgoing; Tue, 23 Jul 2002 07:18:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NEIfRw027658 for ; Tue, 23 Jul 2002 07:18:42 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17X0Vk-00061I-00; Tue, 23 Jul 2002 15:19:36 +0100 Date: Tue, 23 Jul 2002 15:19:36 +0100 From: Christoph Hellwig To: Willi Langenberger Cc: linux-xfs@oss.sgi.com Subject: Re: xfs and openafs problem Message-ID: <20020723151936.A23121@infradead.org> References: <15677.25943.919190.769477@slime.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15677.25943.919190.769477@slime.wu-wien.ac.at>; from wlang@wu-wien.ac.at on Tue, Jul 23, 2002 at 04:16:55PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jul 23, 2002 at 04:16:55PM +0200, Willi Langenberger wrote: > As Alexander Bergolth wrote on July 15, we found a problem creating > large files when using OpenAFS (no answeres yet): OpenAFS is broken. No serious kernel deveoper (XFS or not) will care for your reports if you have this piece of crap loaded. From owner-linux-xfs@oss.sgi.com Tue Jul 23 07:24:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NEO9Rw027903 for ; Tue, 23 Jul 2002 07:24:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NEO8kW027902 for linux-xfs-outgoing; Tue, 23 Jul 2002 07:24:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NEO3Rw027874 for ; Tue, 23 Jul 2002 07:24:04 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6NEOgnK037233; Tue, 23 Jul 2002 16:24:47 +0200 (CEST) Message-Id: <4.3.2.7.2.20020723162204.037e0c48@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jul 2002 16:23:32 +0200 To: thomas , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: data recovery after hdd failure In-Reply-To: <12310497033.20020723161205@ff33.cc> References: <4.3.2.7.2.20020721170008.037b6810@pop.xs4all.nl> <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> <4.3.2.7.2.20020721170008.037b6810@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:12 23-7-2002 +0200, thomas wrote: >maybe that'd be a good idea. what is the standard xfs blocksize, 4096 >no? that'd be dd conv=noerror,sync bs=4096 /dev/hda5 4096 is correct. >it would actually help me a lot already if i'd just get the filenames >and directory structure out of the partition, is there some way to do >this besides xfs_ncheck? Do you still have an old locate database which you can query? That's what I do when I lose stuff. That way at least I know what went missing. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Jul 23 07:43:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NEhsRw028323 for ; Tue, 23 Jul 2002 07:43:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NEhsdQ028322 for linux-xfs-outgoing; Tue, 23 Jul 2002 07:43:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.89.54]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NEhlRw028294 for ; Tue, 23 Jul 2002 07:43:48 -0700 Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id g6NEigZ21836; Tue, 23 Jul 2002 16:44:42 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15677.27610.440858.682675@slime.wu-wien.ac.at> Date: Tue, 23 Jul 2002 16:44:42 +0200 To: linux-xfs@oss.sgi.com Subject: Re: xfs and openafs problem In-Reply-To: <20020723151936.A23121@infradead.org> References: <15677.25943.919190.769477@slime.wu-wien.ac.at> <20020723151936.A23121@infradead.org> X-Mailer: VM 7.06 under Emacs 21.2.1 Reply-To: Willi.Langenberger@wu-wien.ac.at X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk According to Christoph Hellwig: > OpenAFS is broken. No serious kernel deveoper (XFS or not) will care > for your reports if you have this piece of crap loaded. Have you any pointers? OpenAFS is installed on any linux box here and works quite well so far... Anyway, what makes you sure, that it's OpenAFS' fault (besides that it is crap)? Thanks, \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/9207 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Jul 23 08:05:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NF51Rw028789 for ; Tue, 23 Jul 2002 08:05:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NF50j2028786 for linux-xfs-outgoing; Tue, 23 Jul 2002 08:05:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NF4rRw028750 for ; Tue, 23 Jul 2002 08:04:54 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17X1ET-0006AJ-00; Tue, 23 Jul 2002 16:05:49 +0100 Date: Tue, 23 Jul 2002 16:05:49 +0100 From: Christoph Hellwig To: Willi.Langenberger@wu-wien.ac.at Cc: linux-xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: xfs and openafs problem Message-ID: <20020723160549.A23577@infradead.org> References: <15677.25943.919190.769477@slime.wu-wien.ac.at> <20020723151936.A23121@infradead.org> <15677.27610.440858.682675@slime.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15677.27610.440858.682675@slime.wu-wien.ac.at>; from wlang@wu-wien.ac.at on Tue, Jul 23, 2002 at 04:44:42PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jul 23, 2002 at 04:44:42PM +0200, Willi Langenberger wrote: > According to Christoph Hellwig: > > OpenAFS is broken. No serious kernel deveoper (XFS or not) will care > > for your reports if you have this piece of crap loaded. > > Have you any pointers? http://www.openafs.org/cgi-bin/cvsweb.cgi/openafs/src/afs/ > Anyway, what makes you sure, that it's OpenAFS' fault (besides that it > is crap)? lack of understanding and thus abuse of the Linux API. Generally broken code in all respects. If you need specific examples look at how they patch the syscall table, the way the ifdefs to support 64bit systems are organized or their struct vnode that is smaller than a linux inode but casted to it all the time anyway. One could also look at the way they hack into the Linux VM internals or other broken abuses of the API. Just DON't use OpenAFS if you want a sane machine. (The same is true for Transarc's propritary fork, btw - it's not better at all). From owner-linux-xfs@oss.sgi.com Tue Jul 23 08:48:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NFmnRw029355 for ; Tue, 23 Jul 2002 08:48:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NFmnNJ029354 for linux-xfs-outgoing; Tue, 23 Jul 2002 08:48:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NFmcRw029324 for ; Tue, 23 Jul 2002 08:48:39 -0700 Received: (qmail 17871 invoked by uid 500); 23 Jul 2002 15:49:23 -0000 Subject: Re: Who's using XFS? (again) From: Austin Gonyou To: Simon Matter Cc: Jurgen Kramer , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3D3D49FE.EC788195@ch.sauter-bc.com> References: <3D3D49FE.EC788195@ch.sauter-bc.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-N3QpKsMOwDOrf3k62mvw" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 23 Jul 2002 10:49:23 -0500 Message-Id: <1027439363.17845.1.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-N3QpKsMOwDOrf3k62mvw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sorry..but... BWAaaaahahahahahahah!!!! Ok..I'm done. :) On Tue, 2002-07-23 at 07:20, Simon Matter wrote: > Jurgen Kramer schrieb: > >=20 > > >Rumor has it that Linus didn't think very many people were > using XFS; >=20 > My boss didn't want us to use Linux because he didn't think very many > people were using Linux :) >=20 > > >perhaps I'll point him at this page when it's updated. :) > >=20 > > Hmm this can be a problem. A lot of people are probably not using > XFS > > because it is not in the standard kernel..:-( > >=20 > > Cheers, > >=20 > > Jurgen --=20 Austin Gonyou Coremetrics, Inc. --=-N3QpKsMOwDOrf3k62mvw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9PXsD94g6ZVmFMoIRAg+2AJoC05I6p7Tm4HTgYvUJZumHUrmvcQCeO7yR e6sc5PsJgH5rKMPES3gRakA= =TU4W -----END PGP SIGNATURE----- --=-N3QpKsMOwDOrf3k62mvw-- From owner-linux-xfs@oss.sgi.com Tue Jul 23 09:17:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NGHwRw005368 for ; Tue, 23 Jul 2002 09:17:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NGHwFC005367 for linux-xfs-outgoing; Tue, 23 Jul 2002 09:17:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NGHoRw005336 for ; Tue, 23 Jul 2002 09:17:50 -0700 Received: from starfleet.thompson.us (slip-32-101-12-219.wi.us.prserv.net[32.101.12.219]) by prserv.net (out2) with ESMTP id <2002072316183520200q7edde>; Tue, 23 Jul 2002 16:18:41 +0000 Received: from thangorodrim.thompson.us ([192.168.0.254]) by starfleet.thompson.us (8.11.6/8.11.6) with ESMTP id g6NExBY12739 for ; Tue, 23 Jul 2002 09:59:11 -0500 Received: by thangorodrim.thompson.us (Postfix, from userid 502) id C47F9DC128; Tue, 23 Jul 2002 09:58:40 -0500 (CDT) Date: Tue, 23 Jul 2002 09:58:40 -0500 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: NFS Message-ID: <20020723145840.GB2018@thangorodrim.thompson.us> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline User-Agent: Mutt/1.4i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: smtp1.thompson.us X-System: Dual 450MHz Xeons with 256MB PC100 ECC-SDRAM X-Machine: IBM Intellistation Z Pro 6865-22U X-Operating-System: Red Hat Linux 7.2 with kernel 2.4.18-grsec-1.9.4 Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 26 2002 21:28:16) X-Spam-Status: No, hits=3.2 required=5.0 tests=KNOWN_BAD_DIALUPS,SUBJ_ALL_CAPS version=2.20 X-Spam-Level: *** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Is XFS still unstable when accessed over NFS? I know that was an issue for a while, and I myself had near-instant hangs on my server whenever NFS requests went to an XFS filesystem. I am thinking of moving over to XFS due to better quota support, but I need to be able to use NFS as well. --=20 -- Skylar Thompson (skylar@attglobal.net) --f2QGlHpHGjS2mn6Y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9PW8gYyzijMrwBxERAiGjAJ9Ep+Pd/Bp9lHvWTKGl0VfeSrGnEwCePMe2 2NDDSpfopmLER3K+WAUhzBk= =0BDN -----END PGP SIGNATURE----- --f2QGlHpHGjS2mn6Y-- From owner-linux-xfs@oss.sgi.com Tue Jul 23 09:36:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NGaLRw005710 for ; Tue, 23 Jul 2002 09:36:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NGaLRQ005709 for linux-xfs-outgoing; Tue, 23 Jul 2002 09:36:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NGaGRw005680 for ; Tue, 23 Jul 2002 09:36:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA97166 for ; Tue, 23 Jul 2002 11:37:07 -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 LAA90668 for ; Tue, 23 Jul 2002 11:37:07 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6NGYvK17621; Tue, 23 Jul 2002 11:34:57 -0500 Message-Id: <200207231634.g6NGYvK17621@stout.americas.sgi.com> Date: Tue, 23 Jul 2002 11:34:57 -0500 Subject: TAKE - remove unused xfs_bmapi vars X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk About 10 places in XFS were allocating, initializing, and passing a variable to xfs_bmapi() in the read case - but that variable was never used. Yank it out; this saves a whopping 288 bytes in my kernel. :) remove unused xfs_bmapi vars Date: Tue Jul 23 09:35:37 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123536a linux/fs/xfs/xfs_da_btree.c - 1.130 linux/fs/xfs/xfs_vnodeops.c - 1.545 linux/fs/xfs/xfs_dmapi.c - 1.73 linux/fs/xfs/xfs_dquot.c - 1.68 linux/fs/xfs/xfs_inode.c - 1.344 linux/fs/xfs/xfs_bmap.c - 1.288 linux/fs/xfs/xfs_attr.c - 1.93 linux/fs/xfs/linux/xfs_lrw.c - 1.161 From owner-linux-xfs@oss.sgi.com Tue Jul 23 09:42:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NGgVRw006097 for ; Tue, 23 Jul 2002 09:42:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NGgVXV006096 for linux-xfs-outgoing; Tue, 23 Jul 2002 09:42:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NGgORw006068 for ; Tue, 23 Jul 2002 09:42:24 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA98692; Tue, 23 Jul 2002 11:43:15 -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 LAA35286; Tue, 23 Jul 2002 11:43:15 -0500 (CDT) Date: Tue, 23 Jul 2002 11:41:05 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Skylar Thompson cc: linux-xfs@oss.sgi.com Subject: Re: NFS In-Reply-To: <20020723145840.GB2018@thangorodrim.thompson.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Skylar - NFS + Linux XFS is quite useable in general - we've chased down several problems over the past few months. There are some outstanding issues, but those generally show up under very high stress. The only real answer, of course, is to test it in your environment, but I expect that it will work well for you. -Eric On Tue, 23 Jul 2002, Skylar Thompson wrote: > Is XFS still unstable when accessed over NFS? I know that was an issue for > a while, and I myself had near-instant hangs on my server whenever NFS > requests went to an XFS filesystem. I am thinking of moving over to XFS due > to better quota support, but I need to be able to use NFS as well. > > -- > -- Skylar Thompson (skylar@attglobal.net) > From owner-linux-xfs@oss.sgi.com Tue Jul 23 09:51:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NGpjRw006909 for ; Tue, 23 Jul 2002 09:51:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NGpj08006908 for linux-xfs-outgoing; Tue, 23 Jul 2002 09:51:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NGpQRw006873 for ; Tue, 23 Jul 2002 09:51:26 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA01292; Tue, 23 Jul 2002 11:52:17 -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 LAA88585; Tue, 23 Jul 2002 11:52:17 -0500 (CDT) Date: Tue, 23 Jul 2002 11:50:07 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Willi Langenberger cc: linux-xfs@oss.sgi.com Subject: Re: xfs and openafs problem In-Reply-To: <15677.25943.919190.769477@slime.wu-wien.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Willi - We're not ignoring you, but we just haven't gotten to this one yet. If you have kdb enabled, you might check to see what it shows you for stacks on the hung process; compiling with egcs/kgcc usually gives you better stacks. -Eric On Tue, 23 Jul 2002, Willi Langenberger wrote: > Hi! > > A few days ago, Jeffrey E. Hundstad wrote: > > It's too bad that XFS is losing people. > > I agree with that! However, we could be in a situation, where nothing > else remains... :-( > > As Alexander Bergolth wrote on July 15, we found a problem creating > large files when using OpenAFS (no answeres yet): > > http://marc.theaimsgroup.com/?l=linux-xfs&m=102675120214280&w=2 > > In short: When using > > Distribution: XFS-RH 7.3 > Kernel: kernel-2.4.18-4SGI_XFS_1.1 > AFS: openafs-1.2.5-rh7.3.1 > > writing largs files (ie the following command) hangs in the "close" syscall: > > head -c 700000000 /dev/zero > testfile > > We tried 3 differnt boxes, everyone showed the same. > > strace of the file writing process yields: > > [] truncate_list_pages [kernel] 0x1f6 > [] truncate_inode_pages [kernel] 0x3b > [] xfs_itruncate_start [kernel] 0x74 > [] xfs_inactive_free_eofblocks [kernel] 0x1c4 > [] xfs_release [kernel] 0x97 > [] linvfs_release [kernel] 0x20 > [] fput [kernel] 0x4d > [] filp_close [kernel] 0x53 > [] sys_close [kernel] 0x43 > [] system_call [kernel] 0x33 > > strace of the AFS daemon: > > [] schedule_timeout [kernel] 0x14 > [] ll_copy_to_user [kernel] 0x38 > [] wait_for_packet [kernel] 0xe6 > [] skb_recv_datagram [kernel] 0xb0 > [] udp_recvmsg [kernel] 0x59 > [] __make_request [kernel] 0x25c > [] inet_recvmsg [kernel] 0x39 > [] sock_recvmsg [kernel] 0x31 > [] xfs_bmbt_get_state [kernel] 0x25 > [] xfs_bmap_do_search_extents [kernel] 0x348 > [] osi_NetReceive [libafs-2.4.18-4SGI_XFS_1.1-i686] 0xbd > [] xfs_bmap_search_extents [kernel] 0x48 > [] __wake_up [kernel] 0x32 > [] afs_osi_Wakeup [libafs-2.4.18-4SGI_XFS_1.1-i686] 0xe > [] rxi_AllocDataBuf [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x2d > [] rxk_ReadPacket [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x95 > [] rxk_Listener [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x6e > [] afs_syscall_call [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x15e > [] afs_RX_Running [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x0 > [] xfs_bmbt_get_state [kernel] 0x25 > [] xfs_bmap_do_search_extents [kernel] 0x2b6 > [] xfs_bmap_search_extents [kernel] 0x48 > [] xfs_bmapi [kernel] 0x34b > [] ide_dmaproc [kernel] 0x1ec > [] generic_unplug_device [kernel] 0x1e > [] filemap_nopage [kernel] 0xbc > [] __alloc_pages [kernel] 0x75 > [] page_remove_rmap [kernel] 0x5d > [] do_wp_page [kernel] 0x229 > [] handle_mm_fault [kernel] 0x106 > [] do_page_fault [kernel] 0x12a > [] afs_syscall [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x10b > [] sys_setpriority [kernel] 0x60 > [] system_call [kernel] 0x33 > > Kernel 2.4.9-21SGI_XFS_1.0.2 seems to work fine with AFS (no hangs). > > Also, any other filesystem we tried (ext2, ext3) didn't show this > effect. > > Has anybody an idea what this could be? What can we do to find out? We > are willing to make any test in that matter, but we don't know how to > start. > > AFS is a requirement on our campus, so we cannot abandon it. > > We would be very unhappy if we had to abandon xfs, becaus we think > it's the best filesystem for linux! > > In any case, thank you _very_ much for your work on xfs! > > > \wlang{} > > -- > Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/9207 > Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria > From owner-linux-xfs@oss.sgi.com Tue Jul 23 10:03:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NH3ORw011092 for ; Tue, 23 Jul 2002 10:03:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NH3OLx011091 for linux-xfs-outgoing; Tue, 23 Jul 2002 10:03:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NH3JRw011063 for ; Tue, 23 Jul 2002 10:03:20 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA43582 for ; Tue, 23 Jul 2002 12:04:11 -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 MAA81557 for ; Tue, 23 Jul 2002 12:04:11 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6NH21s17741; Tue, 23 Jul 2002 12:02:01 -0500 Message-Id: <200207231702.g6NH21s17741@stout.americas.sgi.com> Date: Tue, 23 Jul 2002 12:02:01 -0500 Subject: TAKE - remove vnlist leftovers X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More from Christoph. Dead code trembles in fear! "struct vnlist + assorted prototypes are unused for ages" remove vnlist leftovers Date: Tue Jul 23 10:03:11 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123537a linux/fs/xfs/linux/xfs_vnode.h - 1.53 From owner-linux-xfs@oss.sgi.com Tue Jul 23 12:24:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NJOBRw030041 for ; Tue, 23 Jul 2002 12:24:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NJOBns030040 for linux-xfs-outgoing; Tue, 23 Jul 2002 12:24:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NJO2Rw030009 for ; Tue, 23 Jul 2002 12:24:03 -0700 Received: from starfleet.thompson.us (slip-32-101-12-154.wi.us.prserv.net[32.101.12.154]) by prserv.net (out2) with ESMTP id <2002072319245820206d9si9e>; Tue, 23 Jul 2002 19:24:59 +0000 Received: from thangorodrim.thompson.us ([192.168.0.254]) by starfleet.thompson.us (8.11.6/8.11.6) with ESMTP id g6NHmeY24087 for ; Tue, 23 Jul 2002 12:48:40 -0500 Received: by thangorodrim.thompson.us (Postfix, from userid 502) id 4CC90DC128; Tue, 23 Jul 2002 12:47:39 -0500 (CDT) Date: Tue, 23 Jul 2002 12:47:38 -0500 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: Who's using XFS? (again) Message-ID: <20020723174738.GA13166@thangorodrim.thompson.us> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: <1027117051.12810.74.camel@stout.americas.sgi.com> <1027247105.1110.1.camel@paragon.slim> <4.3.2.7.2.20020723154437.03ae2018@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20020723154437.03ae2018@pop.xs4all.nl> User-Agent: Mutt/1.4i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: smtp1.thompson.us X-System: Dual 450MHz Xeons with 256MB PC100 ECC-SDRAM X-Machine: IBM Intellistation Z Pro 6865-22U X-Operating-System: Red Hat Linux 7.2 with kernel 2.4.18-grsec-1.9.4 Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 26 2002 21:28:16) X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK,KNOWN_BAD_DIALUPS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2002 at 03:45:05PM +0200, Seth Mos wrote: > At 14:20 23-7-2002 +0200, Simon Matter wrote: > >Jurgen Kramer schrieb: > >> > >> >Rumor has it that Linus didn't think very many people were using= =20 > >XFS; > > > >My boss didn't want us to use Linux because he didn't think very many > >people were using Linux :) >=20 > 3% percent of 500 Million is still a lot. I think it's even a little bit higher than that. The last I heard, it was almost beating the Mac, which has around 4.5% market share. Anything that can beat the Mac is definitely a viable platform. --=20 -- Skylar Thompson (skylar@attglobal.net) --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9PZa6YyzijMrwBxERAnJXAJ9WNcuiSR2JjGPkNiBcl1Arx1p8PACgj6Qn VeR+51Ry3RHARgHDus9mJWk= =7Pwb -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-linux-xfs@oss.sgi.com Tue Jul 23 13:54:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NKsSRw012869 for ; Tue, 23 Jul 2002 13:54:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NKsSm7012868 for linux-xfs-outgoing; Tue, 23 Jul 2002 13:54:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NKsJRw012839 for ; Tue, 23 Jul 2002 13:54:19 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g6NKt1R00873 for linux-xfs@oss.sgi.com; Tue, 23 Jul 2002 15:55:01 -0500 Date: Tue, 23 Jul 2002 15:55:01 -0500 From: Dean Roehrich Message-Id: <200207232055.g6NKt1R00873@rope.americas> Subject: TAKE - big dmapi build system cleanup X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From Chris Hellwig: * CONFIG_XFS_DMAPI is now a dep_mbool on CONFIG_XFS_FS, fs/xfs_dmapi/ is entered based on CONFIG_XFS_FS if CONFIG_XFS_DMAPI is set to keep the old behaviour. * CONFIG_HAVE_XFS_DMAPI is gone, as CONFIG_XFS_DMAPI has the same meaning now. * we refuse to mount with dmapi/xdsm options now if we can't support it. * this way the dmapi_mount vfs method can't be called without dmapi support anymore. declare the two dmapi-related vfs methods only if we build with dmapi support. * fs/xfs/xfsdmapistubs.c is gone, all stubs for XFS-own dmapi-related functions are inlines in xfs_dmapi.h now. * xfs_dmapi_mmap_event is renamed to xfs_dm_send_mmap_event to match the other xfs_dm_send_* functions Date: Tue Jul 23 13:54:30 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/2.4.x-xfs-b The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123567a linux/fs/Makefile - 1.51 linux/fs/Config.in - 1.84 linux/Documentation/Configure.help - 1.137 linux/fs/xfs/xfs_dmapi.h - 1.29 linux/fs/xfs/xfs_dmapi.c - 1.74 linux/fs/xfs/Makefile - 1.148 linux/fs/xfs/xfs_vfsops.c - 1.362 linux/fs/xfs/xfsdmapistubs.c - 1.13 linux/fs/xfs/linux/xfs_dmistubs.c - 1.20 linux/fs/xfs/linux/Makefile - 1.55 linux/fs/xfs/linux/xfs_file.c - 1.76 linux/fs/xfs/linux/xfs_super.h - 1.26 linux/fs/xfs/linux/xfs_super.c - 1.198 - No Message Supplied From owner-linux-xfs@oss.sgi.com Tue Jul 23 14:56:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NLuaRw013678 for ; Tue, 23 Jul 2002 14:56:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NLuaSv013677 for linux-xfs-outgoing; Tue, 23 Jul 2002 14:56:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rebel.net.au (IDENT:root@news.tellurian.com.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NLuURw013641 for ; Tue, 23 Jul 2002 14:56:31 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id HAA24819; Wed, 24 Jul 2002 07:39:53 +0930 Message-ID: <3D3DD34C.BBFCBF7C@rebel.net.au> Date: Wed, 24 Jul 2002 07:36:04 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Simon Matter , Jurgen Kramer , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Who's using XFS? (again) References: <1027117051.12810.74.camel@stout.americas.sgi.com> <1027247105.1110.1.camel@paragon.slim> <4.3.2.7.2.20020723154437.03ae2018@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.0 required=5.0 tests=FROM_ENDS_IN_NUMS,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: ** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 97% of 500 Million is even more... > 3% percent of 500 Million is still a lot. :-( From owner-linux-xfs@oss.sgi.com Tue Jul 23 15:11:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6NMBARw015320 for ; Tue, 23 Jul 2002 15:11:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6NMBAnN015319 for linux-xfs-outgoing; Tue, 23 Jul 2002 15:11:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6NMB4Rw015254 for ; Tue, 23 Jul 2002 15:11:05 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA97074 for ; Tue, 23 Jul 2002 17:11:57 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA91349 for ; Tue, 23 Jul 2002 17:11:57 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6NM9ja21215; Tue, 23 Jul 2002 17:09:45 -0500 Message-Id: <200207232209.g6NM9ja21215@stout.americas.sgi.com> Date: Tue, 23 Jul 2002 17:09:45 -0500 Subject: TAKE - remove two useless pagebuf macros X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More(!) from Christoph. "they were introduce to stay compatinle to 2.4.9-rh, but the current tree is far of beeing backportable to something that old." remove two useless pagebuf macros Date: Tue Jul 23 15:11:23 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123578a linux/fs/xfs/pagebuf/page_buf_locking.c - 1.21 linux/fs/xfs/pagebuf/page_buf.c - 1.44 linux/fs/xfs/pagebuf/page_buf.h - 1.28 From owner-linux-xfs@oss.sgi.com Tue Jul 23 17:01:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6O01ARw016682 for ; Tue, 23 Jul 2002 17:01:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6O01AAh016681 for linux-xfs-outgoing; Tue, 23 Jul 2002 17:01:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6O014Rw016653 for ; Tue, 23 Jul 2002 17:01:04 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 RAA04516 for ; Tue, 23 Jul 2002 17:02:01 -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 JAA72337 for linux-xfs@oss.sgi.com; Wed, 24 Jul 2002 09:58:09 +1000 (EST) Date: Wed, 24 Jul 2002 09:58:09 +1000 (EST) From: Nathan Scott Message-Id: <200207232358.JAA72337@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 23 17:00:02 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:123586a linux/kernel/sysctl.c - 1.50 linux/include/linux/sysctl.h - 1.48 linux/include/linux/quota.h - 1.15 linux/fs/dquot.c - 1.49 linux/fs/quota.c - 1.13 - quota sync-up with 2.5 from Christoph -- stats in /proc/sys/fs/quota, change quota hashing to use the superblock instead of dev_t, and misc naming and comment changes. From owner-linux-xfs@oss.sgi.com Tue Jul 23 18:56:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6O1uNRw018163 for ; Tue, 23 Jul 2002 18:56:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6O1uNVO018162 for linux-xfs-outgoing; Tue, 23 Jul 2002 18:56:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6O1uDRw018131 for ; Tue, 23 Jul 2002 18:56:14 -0700 Received: from starfleet.thompson.us (slip-32-101-12-92.wi.us.prserv.net[32.101.12.92]) by prserv.net (out2) with ESMTP id <2002072401571020206okgtae>; Wed, 24 Jul 2002 01:57:11 +0000 Received: from thangorodrim.thompson.us ([192.168.0.254]) by starfleet.thompson.us (8.11.6/8.11.6) with ESMTP id g6O1vAY06225 for ; Tue, 23 Jul 2002 20:57:10 -0500 Received: by thangorodrim.thompson.us (Postfix, from userid 502) id A5C03DC128; Tue, 23 Jul 2002 20:57:09 -0500 (CDT) Date: Tue, 23 Jul 2002 20:57:09 -0500 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: NFS Message-ID: <20020724015709.GA3324@thangorodrim.thompson.us> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020723145840.GB2018@thangorodrim.thompson.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: smtp1.thompson.us X-System: Dual 450MHz Xeons with 256MB PC100 ECC-SDRAM X-Machine: IBM Intellistation Z Pro 6865-22U X-Operating-System: Red Hat Linux 7.2 with kernel 2.4.18-grsec-1.9.4 Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 26 2002 21:28:16) X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,KNOWN_BAD_DIALUPS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2002 at 11:41:05AM -0500, Eric Sandeen wrote: > Hi Skylar -=20 >=20 > NFS + Linux XFS is quite useable in general - we've chased down several > problems over the past few months. There are some outstanding issues, > but those generally show up under very high stress. OK. I'm not planning anything really big; I'll be storing about 40GB of data, and serving about 3GB of that over Samba and NFS. =20 > The only real answer, of course, is to test it in your environment, > but I expect that it will work well for you. OK. I'll report back on the results once I finish the transition tonight. --=20 -- Skylar Thompson (skylar@attglobal.net) --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9Pgl1YyzijMrwBxERAgMNAJwKfgfk/EqLhDInq/6FD0reJdwZmgCeJaTv v7Cgw1Vp4jr5qWlHo58/I4M= =H5eo -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-linux-xfs@oss.sgi.com Tue Jul 23 20:20:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6O3K9Rw019437 for ; Tue, 23 Jul 2002 20:20:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6O3K8TC019436 for linux-xfs-outgoing; Tue, 23 Jul 2002 20:20:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6O3JwRw019403 for ; Tue, 23 Jul 2002 20:19:58 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.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 UAA03233 for ; Tue, 23 Jul 2002 20:20:55 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g6O3KqB11247; Wed, 24 Jul 2002 13:20:52 +1000 Date: Wed, 24 Jul 2002 13:20:52 +1000 From: Keith Owens Message-Id: <200207240320.g6O3KqB11247@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade kbuild 2.5 rules for XFS and DMAPI X-Spam-Status: No, hits=2.2 required=5.0 tests=MAY_BE_FORGED,MISSING_HEADERS version=2.20 X-Spam-Level: ** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade the kbuild 2.5 rules to reflect recent changes to XFS and DMAPI. Unfortunately the backport of the 2.5 quota changes to 2.4 are a problem for kbuild 2.5. The quota changes affect fs/Makefile and therefore fs/Makefile.in. However fs/Makefile.in is not part of the XFS tree, it is part of the kbuild 2.5 patches, but the quota changes are not yet in 2.4 mainline so kbuild 2.5 cannot be updated either. To work around this conflict, the XFS tree contains fs/Makefile.in.xfs. After merging XFS with kbuild 2.5 for 2.4.19-pre10, cd linux mv fs/Makefile.in.xfs fs/Makefile.in to replace the kbuild 2.5 mainline code with the XFS+quota replacement. This is a temporary workaround until the quota patches are in the mainline kernel, that should be in 2.4.20-pre1 or thereabouts. Date: Tue Jul 23 19:53:19 PDT 2002 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:123593a linux/fs/xfs/Makefile.in - 1.21 linux/fs/xfs_dmapi/Makefile.in - 1.9 linux/fs/Makefile.in.xfs - 1.2 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123596a linux/fs/xfs/linux/Makefile.in - 1.10 linux/fs/xfs_dmapi/Makefile.in - 1.10 linux/fs/Makefile.in.xfs - 1.3 Date: Tue Jul 23 19:53:19 PDT 2002 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:123593a linux/fs/xfs/Makefile.in - 1.21 linux/fs/xfs_dmapi/Makefile.in - 1.9 linux/fs/Makefile.in.xfs - 1.2 From owner-linux-xfs@oss.sgi.com Wed Jul 24 07:18:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OEIoRw019460 for ; Wed, 24 Jul 2002 07:18:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OEIoKl019459 for linux-xfs-outgoing; Wed, 24 Jul 2002 07:18:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OEIeRw019431 for ; Wed, 24 Jul 2002 07:18:41 -0700 Received: from user1.cybercity.dk (fxp0.user1.ip.cybercity.dk [212.242.41.34]) by cicero0.cybercity.dk (Postfix) with ESMTP id 9466E102923 for ; Wed, 24 Jul 2002 16:19:40 +0200 (CEST) Received: from tix.pir.eli (port50.cvx2-mal.ppp.netlink.se [62.66.13.51]) by user1.cybercity.dk (Postfix) with ESMTP id 1EC6016B for ; Wed, 24 Jul 2002 16:19:39 +0200 (CEST) Received: (from mdomo@localhost) by tix.pir.eli (8.9.3/8.8.7) id HAA14012 for linux-xfs@oss.sgi.com; Wed, 24 Jul 2002 07:26:29 +0200 Date: Wed, 24 Jul 2002 07:26:29 +0200 From: Daniel Mose To: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Message-ID: <20020724072629.B13199@extra.netlink.se> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_COST,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hundstad, Jeffrey E. wrote: > It's too bad that XFS is losing people. > > I see we've made it to the finger pointing stage. > > Maybe we can step back.... > > If there already isn't too many hurt feelings is it possible to get a report on what TYPE of usage is causing problems. I've been using it on a 700GB server serving FTP, Samba and NetAtalk users to a couple of hundred university folk. Since we've gotten are hardware problems solved we've had no problems. I run it on my squid cache, my local workstation and laptop, no problems there either despite the batery running out and the XYL unplugging the hardware. > > If we could identify TYPES of load/services that perform well and those that perform poorly it may be as usfull as OOPS reports. Some users just don't have the time or ability, we all wish they did, but they CAN tell us what services were running. Cheer up people, The guy that you just lost was working with XFS in a production environment. He simply couldn't take the responsability towards his boss for having a production server that broke down every three days or so. It was quite brave of him to have XFS running at his company in the first place. If you want the XFS file system to function well in a high throughput production environment, I suggest that you do something similar to what Novel is doing: They offer No cost web services like mail for instance that runs on their own development beta software.(www.myrealbox.com) In this way they get their software tested "for real". This kind of service would probably not be very hard to set up. I believe it could be done at some university by some professor, or student, where the XFS is already running. (I have the feeling that a lot of XFS testing and development is done by academy people now as we speak) A POP3 mail service (Not web-based) was the simplest idea I could think of. Other Ideas are: Free or low cost Conference Services, TV-stations, Journalist (photography) relaying servers for news, Music Exchange, anything that would exchange the kind of data through your file system in a way that you need to do testing on. The service offered will of course have to be of big public desire, otherwise people will not find it and thus not use it, oh and it had better be clean as well. =) Kind Regards Daniel Mose. From owner-linux-xfs@oss.sgi.com Wed Jul 24 08:01:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OF1uRw020434 for ; Wed, 24 Jul 2002 08:01:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OF1tmk020433 for linux-xfs-outgoing; Wed, 24 Jul 2002 08:01:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OF1lRw020402 for ; Wed, 24 Jul 2002 08:01:47 -0700 Received: from arcus.vexcel.com (arcus.vexcel.com [192.92.90.44]) by biobio.vexcel.com (8.12.1/8.12.1) with ESMTP id g6OF2dSC017704; Wed, 24 Jul 2002 09:02:39 -0600 (MDT) Received: from vexcel.com (localhost.localdomain [127.0.0.1]) by arcus.vexcel.com (8.11.6/8.11.6) with ESMTP id g6OF2Sa03877; Wed, 24 Jul 2002 09:02:28 -0600 Message-ID: <3D3EC184.E53F3CAB@vexcel.com> Date: Wed, 24 Jul 2002 09:02:28 -0600 From: Vincent Cassi X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Steve Lord Subject: Re: memory leak when write in a file (with O_DIRECT flag). References: <3D2C4D10.C9F37CE9@vexcel.com> <1026314548.2644.14.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > On Wed, 2002-07-10 at 10:04, Vincent Cassi wrote: > > Hi, > > > > I have a small program that take a buffer and copy it in a file. > > If (and only if) the flag O_DIRECT is given to the open command, a > > memory leak appeares. > > The /proc/meminfo file, show the free memory going down each time that > > the program is running. > > > > The average of the memory leak is 160 kBytes with a buffer of 80 Meg > > Bytes. > > The buffer is alligned and mlocked before the write. > > The system used: Mandrake: 8.2 > > XFS: 2.0.0-1 mdk > > linux: 2.4.18 > > > > What I'm doing wrong ??? > > Thanks for any help. > > > > Vincent > > Is there any chance you can try a cvs kernel, there have been major > changes in this area since 2.4.18. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com I did new tests with the kernel 2.4.19-rc1 and its corresponding XFS patch. It looks like the memory leak is still there but a lot smaller. Thanks, Vincent From owner-linux-xfs@oss.sgi.com Wed Jul 24 08:25:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OFPIRw021988 for ; Wed, 24 Jul 2002 08:25:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OFPH4r021987 for linux-xfs-outgoing; Wed, 24 Jul 2002 08:25:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OFPBRw021957 for ; Wed, 24 Jul 2002 08:25:11 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA04595; Wed, 24 Jul 2002 10:26:06 -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 KAA08860; Wed, 24 Jul 2002 10:26:05 -0500 (CDT) Subject: Re: memory leak when write in a file (with O_DIRECT flag). From: Eric Sandeen To: Vincent Cassi Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D3EC184.E53F3CAB@vexcel.com> References: <3D2C4D10.C9F37CE9@vexcel.com> <1026314548.2644.14.camel@jen.americas.sgi.com> <3D3EC184.E53F3CAB@vexcel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 24 Jul 2002 10:23:47 -0500 Message-Id: <1027524227.23229.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Vincent - A couple more things, could you verify that you don't see this leak on, say, ext3 or some other filesystem? Just to narrow it down to XFS. If you don't mind sharing your test program, I'd like to try to duplicate the problem here, when I get some time. Thanks, -Eric On Wed, 2002-07-24 at 10:02, Vincent Cassi wrote: > I did new tests with the kernel 2.4.19-rc1 and its corresponding XFS patch. > It looks like the memory leak is still there but a lot smaller. > > Thanks, > Vincent > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Jul 24 08:35:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OFZARw022330 for ; Wed, 24 Jul 2002 08:35:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OFZAAk022329 for linux-xfs-outgoing; Wed, 24 Jul 2002 08:35:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ursa.xanoptix.com (host-64-65-199-187.man.choiceone.net [64.65.199.187]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OFZ3Rw022301 for ; Wed, 24 Jul 2002 08:35:04 -0700 Received: from kend-linux.xanoptix.com ([10.20.1.45] helo=xanoptix.com)by ursa.xanoptix.comwith smtp(Exim 3.20 #1 (Debian))id 17XNw2-0000eI-00; Wed, 24 Jul 2002 11:20:18 -0400 Received: from 10.20.1.45 (SquirrelMail authenticated user kend) by kend-linux.xanoptix.com with HTTP; Wed, 24 Jul 2002 11:20:18 -0400 (EDT) Message-ID: <35367.10.20.1.45.1027524018.squirrel@kend-linux.xanoptix.com> Date: Wed, 24 Jul 2002 11:20:18 -0400 (EDT) Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops From: "Ken D'Ambrosio" To: In-Reply-To: <20020724072629.B13199@extra.netlink.se> References: <20020724072629.B13199@extra.netlink.se> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: X-Mailer: SquirrelMail (version 1.2.5) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hundstad, Jeffrey E. wrote: >> It's too bad that XFS is losing people. >> [...] >> If there already isn't too many hurt feelings is it possible to get a >> report on what TYPE of usage is causing problems. I've been using it >> on a 700GB server serving FTP, Samba and NetAtalk users to a couple of >> hundred university folk. Since we've gotten are hardware problems >> solved we've had no problems. I run it on my squid cache, my local >> workstation and laptop, no problems there either despite the batery >> running out and the XYL unplugging the hardware. One thing I've noticed -- and feel free, guys, to correct me if I'm wrong, since I'm *not* a kernel hacker -- is that "Built-in Kernel Debugger support" is enabled by default, at least for the CVS copy I have. The problem here, I believe, is that if the system has an OOPS, instead of logging it to syslog and going on its way, it dumps you into the debugger. While this doesn't crash your system, per-se, it *does* make it unavailable until someone manually types "go" at the debug prompt. This can create big problems in a production environment (alas, I proved this myself last week). I've since re-compiled all my kernels to -not- have the debugger included, and all proceeds smoothly. Perhaps the debugger should _NOT_ be enabled by default in the .config file included with XFS' Linux kernel tree? $.02, -Ken From owner-linux-xfs@oss.sgi.com Wed Jul 24 08:54:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OFsmRw031628 for ; Wed, 24 Jul 2002 08:54:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OFsmov031627 for linux-xfs-outgoing; Wed, 24 Jul 2002 08:54:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from issv0170.isis.de (issv0170.isis.de [195.158.131.222]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OFsfRw031599 for ; Wed, 24 Jul 2002 08:54:42 -0700 Received: (qmail 27670 invoked by uid 1010); 24 Jul 2002 15:55:41 -0000 Received: from unknown (HELO ATHLET) ([195.158.147.173]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 24 Jul 2002 15:55:41 -0000 Date: Wed, 24 Jul 2002 17:56:02 +0200 From: thomas X-Mailer: The Bat! (v1.60) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <443851548.20020724175602@ff33.cc> To: linux-xfs@oss.sgi.com Subject: Re: data recovery after hdd failure In-Reply-To: <4.3.2.7.2.20020723162204.037e0c48@pop.xs4all.nl> References: <4.3.2.7.2.20020721170008.037b6810@pop.xs4all.nl> <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> <4.3.2.7.2.20020721103502.03ceb2b0@pop.xs4all.nl> <4.3.2.7.2.20020721170008.037b6810@pop.xs4all.nl> <4.3.2.7.2.20020723162204.037e0c48@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk GOOD NEWS EVERYONE! i have all my data back. dd conv=noerror,sync bs=4096 did the trick. ^^^^^^^^^^^^ again it took many hours but after that the actual recovery was a piece of cake. xfs_ncheck didn't segfault this time so i got the full file list which already made me happy. xfs_repair then complained about inconsistend metadata so i erased the log, mounted the filesystem and taadaa there was my data. about 99% was there, the rest was in lost+found of which i could reconstruct about 90% so i have like no data loss at all. i really love the sophisticated repair tools of xfs. many thanks to the coders! i will probably get myself another 80GB IDE and make some nice RAID1 just to be extra safe, because even xfs_repair won't help me much with a nice head crash or sth. of that sort i guess :) thomas ps. if someone wants to know the 80GB that ran too hot was a Maxtor 80GB 5400rpm(!), got myself a 80GB IBM 7200rpm now but will probably exchange it for one or two Seagate Barracudas which are supposed to be more quiet, reliable and don't get so hot. From owner-linux-xfs@oss.sgi.com Wed Jul 24 08:55:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OFtLRw031740 for ; Wed, 24 Jul 2002 08:55:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OFtL2X031739 for linux-xfs-outgoing; Wed, 24 Jul 2002 08:55:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OFtDRw031663 for ; Wed, 24 Jul 2002 08:55:13 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA05188; Wed, 24 Jul 2002 10:56:07 -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 KAA36344; Wed, 24 Jul 2002 10:56:06 -0500 (CDT) Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops From: Eric Sandeen To: "Ken D'Ambrosio" Cc: mdomo@extra.netlink.se, linux-xfs@oss.sgi.com In-Reply-To: <35367.10.20.1.45.1027524018.squirrel@kend-linux.xanoptix.com> References: <20020724072629.B13199@extra.netlink.se> <35367.10.20.1.45.1027524018.squirrel@kend-linux.xanoptix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 24 Jul 2002 10:53:47 -0500 Message-Id: <1027526028.23229.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Ken - Hm, I don't think -any- .config file is supplied via CVS, although KDB is set to be on in linux/arch/i386/defconfig. KDB is generally a good thing to have on in a CVS kernel, I think, because CVS is not expected to be super-stable, and may offer many debugging opportunities. The latest -released- XFS version (1.1) did not have kdb enabled, however. Frankly, if you're taking a CVS kernel & running it in a production environment, without understanding the implications of the options that are enabled, you are bound to have problems. :) FWIW, you can also control kdb via /proc/sys/kernel/kdb -Eric On Wed, 2002-07-24 at 10:20, Ken D'Ambrosio wrote: > One thing I've noticed -- and feel free, guys, to correct me if I'm wrong, > since I'm *not* a kernel hacker -- is that "Built-in Kernel Debugger > support" is enabled by default, at least for the CVS copy I have. The > problem here, I believe, is that if the system has an OOPS, instead of > logging it to syslog and going on its way, it dumps you into the debugger. > While this doesn't crash your system, per-se, it *does* make it unavailable > until someone manually types "go" at the debug prompt. This can create big > problems in a production environment (alas, I proved this myself last week). > I've since re-compiled all my kernels to -not- have the debugger included, > and all proceeds smoothly. Perhaps the debugger should _NOT_ be enabled by > default in the .config file included with XFS' Linux kernel tree? > > $.02, > > -Ken -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Jul 24 10:02:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OH2hRw002444 for ; Wed, 24 Jul 2002 10:02:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OH2hEn002443 for linux-xfs-outgoing; Wed, 24 Jul 2002 10:02:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from endeavour.uwyo.edu (endeavour.uwyo.edu [129.72.10.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OH2VRw002415 for ; Wed, 24 Jul 2002 10:02:32 -0700 Received: from CONVERSION-DAEMON.endeavour.uwyo.edu by endeavour.uwyo.edu (PMDF V6.1-1 #40460) id <0GZR00D01JDWCY@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Wed, 24 Jul 2002 11:03:32 -0600 (MDT) Received: from asuwlink.uwyo.edu (asuwlink.uwyo.edu [129.72.60.2]) by endeavour.uwyo.edu (PMDF V6.1-1 #40460) with ESMTP id <0GZR00D1PJDW44@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Wed, 24 Jul 2002 11:03:32 -0600 (MDT) Received: from localhost (fletcher@localhost) by asuwlink.uwyo.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA05335 for ; Wed, 24 Jul 2002 11:03:32 -0600 (MDT) Date: Wed, 24 Jul 2002 11:03:31 -0600 (MDT) From: Walter R Fletcher Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops To: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: asuwlink.uwyo.edu: fletcher owned process doing -bs X-Spam-Status: No, hits=-0.5 required=5.0 tests=DEAR_SOMEBODY version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear People, I take care of a modest number of SGI, Sun, and Linux based systems in the department labs and offices. The one resource that gets continually exhausted is disk space. Some time ago I read an article on the web describing a way to make a large RAID for a meager cost. Some further searching revealed a modest body of information about this subject. I got approval to set up a test system. The filesystem type I chose was XFS because I had used it for over 5 years on my Challenge-S fileserver (15 different filesystems, about 350 gigabytes) without a single snag. The test system consisted of a collection of 23 and 70 gigabyte disks. Tests were flawless, so I bought a good motherboard (Tyan ThunderK7, a good RAID card (3ware 7850), 8 120 gigabyte Maxtors (plus some spares), and a small disk for the system. I went with a hardware RAID because I didn't trust the Linux software RAID at the time. I ended up with an 860 gigabyte filesystem. Initially I used the SGI XFS ISO (RH7.1 I think) to set the system up. The system ran OK except for frequent rpc timeout problems reported by the NFS clients but only during write operations. The problem could be made to happen by setting processes running on each client which wrote data to the NFS server at the fastest rate possible, i.e.: dd if=/dev/zero count= bs= of=/big/file The dd parameters were chosen to mimic the record sizes and quantities typical of the the processing being done by the users, i.e.: count = whatever would result in an approximately 100gig sized file given the block size chosen. bs = anywhere from 6000 to 16000 bytes. Size didn't seem to matter. I would set this in motion on 1, 2, or 3 systems at once, depending on how many systems with 100baseT interfaces were free at the moment. This would also mimic a normal load at any given time. Over time I tried tweaks of various parameters used to tune NFS or other aspects of the system to improve performance and reliability, but never did totally get rid of the failures so I've never been sure I was tweaking anything/everything really meaningful. I wish there was better documentation of the /proc filesystem/NFS parameters. Recently I downloaded the 2.4.18/XFS 1.1 ISO image installer from SGI to do a clean update. There had been so many tinkerings and patches to the system I was beginning to worry that the server would suffer or unravel altogether. The new install has been much more stable. I have only once been able to hang the system. That failure took nearly 24 hours of continual onslaught before it finally happened. The system has been returned to normal service. No problems have been reported by the users for several weeks. I'm keeping a hopeful eye on it. All in all, I now believe XFS based filesystems as NFS exports are sufficiently reliable and will continue to improve such that I'm in the process of building two more servers like the first. We need the space. -- Reid Walter Reid Fletcher, WB7CJO Senior Systems Analyst / Unix Systems Administrator Department of Geology and Geophysics P. O. Box 3006 University of Wyoming 1-307-766-6227 Laramie, WY 82071 Internet: Fletcher @ UWyo.Edu Are we all roadkill on the information highway? - Jeff Greenfield From owner-linux-xfs@oss.sgi.com Wed Jul 24 10:26:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OHQNRw002946 for ; Wed, 24 Jul 2002 10:26:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OHQNhD002945 for linux-xfs-outgoing; Wed, 24 Jul 2002 10:26:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OHQERw002917 for ; Wed, 24 Jul 2002 10:26:14 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 41FDE147F0; Wed, 24 Jul 2002 19:27:10 +0200 (MEST) Date: Wed, 24 Jul 2002 19:27:06 +0200 From: Andi Kleen To: Walter R Fletcher Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Message-ID: <20020724192706.A17637@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Initially I used the SGI XFS ISO (RH7.1 I think) to set > the system up. The system ran OK except for frequent rpc timeout > problems reported by the NFS clients but only during write operations. > The problem could be made to happen by setting processes running on > each client which wrote data to the NFS server at the fastest rate > possible, i.e.: > > dd if=/dev/zero count= bs= of=/big/file [...] A common problem with many older linux kernels is that NFS is using a 64K socket buffer only. This can cause packets to get dropped when the buffer queue is overloaded on the NFS server. What you can do is to increase /proc/sys/net/core/[rw]mem_{default,max}. This has to be done before the kernel nfs server is initialized, e.g. in the NFS server start script before the daemons are started. Newer kernels should do the tuning automatically. Same can be done on the clients. Another common cause for dropped packets is a Ethernet half/full duplex mismatch between switch and server. May be worth checking for. -Andi From owner-linux-xfs@oss.sgi.com Wed Jul 24 11:06:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OI61Rw003773 for ; Wed, 24 Jul 2002 11:06:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OI61jX003772 for linux-xfs-outgoing; Wed, 24 Jul 2002 11:06:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OI5oRw003724 for ; Wed, 24 Jul 2002 11:05:50 -0700 Received: from extrly.fac.com (extrly.fac.com [64.239.86.39]) 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 LAA05836 for ; Wed, 24 Jul 2002 11:07:17 -0700 (PDT) mail_from (Jameel_Akari@fac.com) Received: from albexsvr.fac.com (albexsvr.fac.com [12.152.246.67]) by extrly.fac.com (8.11.6/8.11.6) with ESMTP id g6OHnZq21616 for ; Wed, 24 Jul 2002 13:49:36 -0400 Received: from albcm01.fac.com (albcm01.fac.com [10.2.5.60]) by albexsvr.fac.com (8.12.2/8.12.1) with ESMTP id g6OHnTgE013399 for ; Wed, 24 Jul 2002 13:49:29 -0400 Received: from remus.fac.com (remus.fac.com [10.2.6.4]) by albcm01.fac.com (Switch-2.1.1/Switch-2.1.1) with ESMTP id U6OH2DTB13736 for ; Wed, 24 Jul 2002 13:49:29 -0400 Received: from albsmtp01.fac.com (albsmtp01 [10.2.5.41]) by remus.fac.com (8.11.3/8.11.3) with ESMTP id g6OHnTs06276 for ; Wed, 24 Jul 2002 13:49:29 -0400 (EDT) Subject: Re: (NFS) 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jameel Akari" Date: Wed, 24 Jul 2002 13:49:28 -0400 X-MIMETrack: Serialize by Router on ALBSMTP01/First Albany(Release 5.0.8 |June 18, 2001) at 07/24/2002 01:47:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MailScanner: Found to be clean X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Note that an Ethernet duplex mismatch will result in a very slow transfer rate indeed.. I consistently see 47KB/sec when we find a 100Mb half-duplex / full-duplex mismatch, pretty much independant of protocol. I've found it to be painfully common among Cisco switches, from 2924 to 6500s. Have you tried tweaking the rsize and wsize parameters on your NFS mounts as well? -- Jameel Akari UNIX Admin First Albany Corp Andi Kleen To: Walter R Fletcher Sent by: cc: linux-xfs@oss.sgi.com owner-linux-xfs@o Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops ss.sgi.com 07/24/2002 01:27 PM > Initially I used the SGI XFS ISO (RH7.1 I think) to set > the system up. The system ran OK except for frequent rpc timeout > problems reported by the NFS clients but only during write operations. > The problem could be made to happen by setting processes running on > each client which wrote data to the NFS server at the fastest rate > possible, i.e.: > > dd if=/dev/zero count= bs= of=/big/file [...] A common problem with many older linux kernels is that NFS is using a 64K socket buffer only. This can cause packets to get dropped when the buffer queue is overloaded on the NFS server. What you can do is to increase /proc/sys/net/core/[rw]mem_{default,max}. This has to be done before the kernel nfs server is initialized, e.g. in the NFS server start script before the daemons are started. Newer kernels should do the tuning automatically. Same can be done on the clients. Another common cause for dropped packets is a Ethernet half/full duplex mismatch between switch and server. May be worth checking for. -Andi From owner-linux-xfs@oss.sgi.com Wed Jul 24 11:23:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OIN0Rw004208 for ; Wed, 24 Jul 2002 11:23:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OIN024004207 for linux-xfs-outgoing; Wed, 24 Jul 2002 11:23:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OIMtRw004178 for ; Wed, 24 Jul 2002 11:22:56 -0700 Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 103882FA04 for ; Wed, 24 Jul 2002 11:23:57 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id A1B233444 for ; Wed, 24 Jul 2002 11:23:46 -0700 (PDT) Subject: logdev on IDE From: Florin Andrei To: linux-xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Jul 2002 11:23:46 -0700 Message-Id: <1027535026.1648.5.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From a pure performance perspective, i wonder if anyone tried to put the logdev on IDE while using SCSI for the actual XFS disks/arrays. Theoretically, the new IDE drives should be quite fast, but anyway, if anyone tried that, i'd like to hear whatever good/bad things happened, performance-wise. -- Florin Andrei "Still wondering why they called it 'United Linux'. Firstly it sounds like a football team and secondly wouldn't 'Turbo Susiva' have sounded much better?" - Alan Cox From owner-linux-xfs@oss.sgi.com Wed Jul 24 11:33:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OIXmRw004474 for ; Wed, 24 Jul 2002 11:33:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OIXmRk004473 for linux-xfs-outgoing; Wed, 24 Jul 2002 11:33:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OIXeRw004431 for ; Wed, 24 Jul 2002 11:33:41 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id UAA08948 for ; Wed, 24 Jul 2002 20:34:41 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17XQy9-0002ze-00 for ; Wed, 24 Jul 2002 20:34:41 +0200 Date: Wed, 24 Jul 2002 20:34:41 +0200 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops Message-ID: <20020724203441.E791@pc9391.uni-regensburg.de> References: <20020724192706.A17637@wotan.suse.de> <20020724203318.C791@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20020724203318.C791@pc9391.uni-regensburg.de>; from christian.guggenberger@physik.uni-regensburg.de on Wed, Jul 24, 2002 at 20:33:18 +0200 X-Mailer: Balsa 1.2.4 Lines: 28 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 24 Jul 2002 19:27:06 Andi Kleen wrote: > > Initially I used the SGI XFS ISO (RH7.1 I think) to set > > the system up. The system ran OK except for frequent rpc timeout > > problems reported by the NFS clients but only during write operations. > > The problem could be made to happen by setting processes running on > > each client which wrote data to the NFS server at the fastest rate > > possible, i.e.: > > > > dd if=/dev/zero count= bs= of=/big/file > > [...] > > A common problem with many older linux kernels is that NFS is using a 64K > socket buffer only. This can cause packets to get dropped when the buffer > queue is overloaded on the NFS server. What you can do is to increase > /proc/sys/net/core/[rw]mem_{default,max}. This has to be done before the > kernel nfs server is initialized, e.g. in the NFS server start script > before the daemons are started. > Newer kernels should do the tuning automatically. Same can be done on > the clients. ... we are planning to integrate a gigabit interface (intel e1000) in our fileserver (NFS) soon. Could one of you point out some kernel (proc) tunings i should do ? Or should the default settings work fine (and performant) ? Christian From owner-linux-xfs@oss.sgi.com Wed Jul 24 11:36:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OIa8Rw004710 for ; Wed, 24 Jul 2002 11:36:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OIa8Ki004709 for linux-xfs-outgoing; Wed, 24 Jul 2002 11:36:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OIa2Rw004676 for ; Wed, 24 Jul 2002 11:36:02 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA00298; Wed, 24 Jul 2002 13:36:58 -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 NAA91263; Wed, 24 Jul 2002 13:36:58 -0500 (CDT) Subject: Re: logdev on IDE From: Eric Sandeen To: Florin Andrei Cc: linux-xfs In-Reply-To: <1027535026.1648.5.camel@stantz.corp.sgi.com> References: <1027535026.1648.5.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 24 Jul 2002 13:34:38 -0500 Message-Id: <1027535678.14036.28.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hm, if that IDE speed is coming from the write-cache on the drive, you may as well just put your log on a ramdisk. :) Of course, log integrity might suffer on a crash. Seriously, unless you -really- trust that write cache, be careful! -Eric On Wed, 2002-07-24 at 13:23, Florin Andrei wrote: > >From a pure performance perspective, i wonder if anyone tried to put the > logdev on IDE while using SCSI for the actual XFS disks/arrays. > > Theoretically, the new IDE drives should be quite fast, but anyway, if > anyone tried that, i'd like to hear whatever good/bad things happened, > performance-wise. > > -- > Florin Andrei > > "Still wondering why they called it 'United Linux'. Firstly it sounds > like a football team and secondly wouldn't 'Turbo Susiva' have sounded > much better?" - Alan Cox -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Jul 24 11:49:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OInURw005036 for ; Wed, 24 Jul 2002 11:49:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OInUd3005035 for linux-xfs-outgoing; Wed, 24 Jul 2002 11:49:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from metrony.com (webware.metrony.com [207.159.131.106]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OInLRw005007 for ; Wed, 24 Jul 2002 11:49:22 -0700 Received: from metrony.com (metrony.com [207.159.131.106]) by metrony.com (8.11.0/8.11.0) with SMTP id g6OIoNT45511 for ; Wed, 24 Jul 2002 18:50:23 GMT (envelope-from aaron@metrony.com) Received: from 65.206.44.6 (SquirrelMail authenticated user aaron) by metrony.com with HTTP; Wed, 24 Jul 2002 18:50:23 -0000 (GMT) Message-ID: <24910.65.206.44.6.1027536623.squirrel@metrony.com> Date: Wed, 24 Jul 2002 18:50:23 -0000 (GMT) Subject: XFS success story From: "Aaron Held" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.5) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk To the XFS team: Thanks for a great software product! Due to your efforts I can now go home and spend time with my new baby rather then fixing a server. Over a year ago I won a contract to build a large database server. My system had to handle very large files passed from an IBM AS/400 and I needed XFS for its ability to handle 10+ gig files. Currently the system runs postgresql with about 120 million records on a 100 Gig XFS partition. Recently the Dell server started having issues with its RAID controller and the fix was to install a newer kernel. Also recently my wife gave birth to a baby girl and I did not look forward to spending the day recompiling software and testing my apps. I came across the update RPM for the 1.1 system and installed them. Other then a typo (on my part) the installation directions were perfect. I did not expect such a complex upgrade to go so well. The first time I installed XFS is was a mess of patching and compiling (partly due to other dell drivers that I needed - Now thoes drivers are in the stock RH kernel) Thanks again, Once I go back to work I will write a letter to RedHat telling them about my experience (and how I sold RedHat linux into a primarily Windows shop on the merits of the XFS filesystem.) This app is in use for a large financial company and and I am now working with my client to develop a larger app that will require a 300Gig database to be used by other fortune 500 firms. (Along with another few costly RedHat support contracts) A year ago XFS helped me make money, today the completeness of the project is saving me time. Thanks again, -Aaron Held From owner-linux-xfs@oss.sgi.com Wed Jul 24 12:00:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OJ09Rw005496 for ; Wed, 24 Jul 2002 12:00:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OJ08Xi005494 for linux-xfs-outgoing; Wed, 24 Jul 2002 12:00:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OIxYRw005441 for ; Wed, 24 Jul 2002 11:59:35 -0700 Received: from arcus.vexcel.com (arcus.vexcel.com [192.92.90.44]) by biobio.vexcel.com (8.12.1/8.12.1) with ESMTP id g6OJ0OSC006098; Wed, 24 Jul 2002 13:00:25 -0600 (MDT) Received: from vexcel.com (localhost.localdomain [127.0.0.1]) by arcus.vexcel.com (8.11.6/8.11.6) with ESMTP id g6OJ0Da09947; Wed, 24 Jul 2002 13:00:13 -0600 Message-ID: <3D3EF93D.9FFDBBF3@vexcel.com> Date: Wed, 24 Jul 2002 13:00:13 -0600 From: Vincent Cassi X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: "linux-xfs@oss.sgi.com" Subject: Re: memory leak when write in a file (with O_DIRECT flag). References: <3D2C4D10.C9F37CE9@vexcel.com> <1026314548.2644.14.camel@jen.americas.sgi.com> <3D3EC184.E53F3CAB@vexcel.com> <1027524227.23229.6.camel@stout.americas.sgi.com> Content-Type: multipart/mixed; boundary="------------A67B9837330DED58B94971A6" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------A67B9837330DED58B94971A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > Hi Vincent - > > A couple more things, could you verify that you don't see this leak on, > say, ext3 or some other filesystem? Just to narrow it down to XFS. > > If you don't mind sharing your test program, I'd like to try to > duplicate the problem here, when I get some time. > > Thanks, > > -Eric > > On Wed, 2002-07-24 at 10:02, Vincent Cassi wrote: > > I did new tests with the kernel 2.4.19-rc1 and its corresponding XFS patch. > > It looks like the memory leak is still there but a lot smaller. > > > > Thanks, > > Vincent > > > > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 Hi Eric, Here is the shell program which call the copy program (speed_w2f_block_leak): j=0 while [ 1 ] do printf "Repetition: %d \n" "${j}" cat /proc/meminfo sleep 5 /utility/speed_w2f_block_leak 20 qq.out sleep 2 cat /proc/meminfo printf "\n\n" let j=j+1 done Attached is the copy program (speed_w2f_block_leak.c). I built it with the following command: gcc -D__KERNEL__ -DMODULE -I$(KERNEDIR)/include -O -Wall -o speed_w2f_block_leak speed_w2f_block_leak.c Thanks, Vincent --------------A67B9837330DED58B94971A6 Content-Type: text/plain; charset=us-ascii; name="speed_w2f_block_leak.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="speed_w2f_block_leak.c" /*cs---------------------------------------------------------------------------- * * * Module: speed_w2f_block_leak.c * * Purpose: Calculate the speed for copying block of 4 Mbytes data * to a file (using sgi XFS). * Test leak memmory. * * Comments: * * Arguments: argv[1] = number of block. * argv[2] = name of the file where the program write data. * * Author: Vincent Cassi * * Date: 07.09.2002 * * Revisions: * * ----------------------------------------------------------------------------ce*/ #define _GNU_SOURCE #include /* exit, atoi, ... */ #include /* sprintf */ #include /* write */ #include /* open */ #include /* ioctl */ #include /* gettimeofday */ #include /* mlock */ #include /* S_IRUSR */ /* XFS */ #include #include /* memalign */ int main(int argc, char* argv[]) { dma_addr_t *buffer_a = NULL; unsigned long size; int i,j; char cursor; int file_descriptor_w_0; int error_write; int write_count; struct timeval st, et; struct timezone unused; float elapsed_usec; float megahertz; /* XFS */ struct dioattr dio; int error_dioinfo; /* Check number of arguments */ if (argc != 3) { printf("!!! Wrong number of arguments !!!\n"); printf(" Number of given arguments = %x\n", (argc - 1)); printf("Give two arguments\n"); printf(" The first argument is the number of block\n"); printf(" The second argument is the name of the file\n"); exit(-1); } size = atoi(argv[1]) * 4194304; printf("\nOpen file and write ...\n\n"); write_count = 0; cursor = '\\'; /* * Open the file where the data have to be written */ for(j = 0 ; j < 1 ; j++){ /* Commit buffer cache to disk */ /*sync();*/ gettimeofday(&st, &unused); file_descriptor_w_0 = open64(argv[2], O_WRONLY | O_CREAT | O_TRUNC | O_DIRECT , S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP); if (file_descriptor_w_0 < 0) { perror(argv[2]); goto failed; } error_dioinfo = ioctl(file_descriptor_w_0, XFS_IOC_DIOINFO, &dio); if (error_dioinfo < 0) { perror("Dioinfo "); goto failed_buffer; } /* Get a buffer aligned the way we need it */ buffer_a = memalign(dio.d_mem, size) ; if (!buffer_a) { perror("memalign"); goto failed_buffer; } if (mlock(buffer_a, size)) { perror("mlock"); goto failed_buffer; } /* Initialize and the buffer */ for (i = 0; i < size / 4 ; i = i + 2) { buffer_a[i] = 0x000000fc; buffer_a[i + 1] = 0x0300fc03; } /* Write */ error_write = write(file_descriptor_w_0, buffer_a, size); if(close(file_descriptor_w_0)) { perror("close"); goto failed_buffer_lock; } gettimeofday(&et, &unused); elapsed_usec = (et.tv_sec * 1000000.0 + et.tv_usec) - (st.tv_sec * 1000000.0 + st.tv_usec); megahertz = (size * 8) / elapsed_usec; if (error_write < 0) { perror("write on file"); goto failed_buffer_lock; } printf("%c Write count: %10d %c\n", cursor, error_write, cursor); write_count += error_write; printf( "%c %s Clock rate: %6.1f MHz, Data buffer alignment: %d, %d, %d %c\n", cursor, argv[2] , megahertz, dio.d_mem, dio.d_miniosz, dio.d_maxiosz, cursor); cursor = cursor == '\\' ? '/' : '\\'; if (munlock(buffer_a, size)) { perror("munlock"); goto failed_buffer; } free(buffer_a); } /* * Usual Output */ exit(0); /* * Failed Output */ failed_buffer_lock: munlock(buffer_a, size); failed_buffer: free(buffer_a); failed: /* Commit buffer cache to disk */ /*sync();*/ exit(-1); } --------------A67B9837330DED58B94971A6-- From owner-linux-xfs@oss.sgi.com Wed Jul 24 12:40:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OJeIRw007215 for ; Wed, 24 Jul 2002 12:40:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OJeIfc007214 for linux-xfs-outgoing; Wed, 24 Jul 2002 12:40:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OJe8Rw007186 for ; Wed, 24 Jul 2002 12:40:09 -0700 Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 5CE362FA04 for ; Wed, 24 Jul 2002 12:41:10 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id F060A343A for ; Wed, 24 Jul 2002 12:40:59 -0700 (PDT) Subject: Re: logdev on IDE From: Florin Andrei To: linux-xfs In-Reply-To: <1027535678.14036.28.camel@stout.americas.sgi.com> References: <1027535026.1648.5.camel@stantz.corp.sgi.com> <1027535678.14036.28.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Jul 2002 12:40:59 -0700 Message-Id: <1027539660.1648.11.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Indeed, that would be a problem. Anyway, some generous souls just gave me an external SCSI drive, so the case for the IDE is closed. ;-) But, for future refference, is there a way to tell if an IDE drive is doing bad things? I mean, other than pressing Reset repeatedly... Or perhaps someone put up a list of good/bad IDE drives, in regard to the caching problem... I guess this should be interesting for anyone using a journalised FS. On Wed, 2002-07-24 at 11:34, Eric Sandeen wrote: > Hm, if that IDE speed is coming from the write-cache on the drive, you > may as well just put your log on a ramdisk. :) Of course, log > integrity might suffer on a crash. > > Seriously, unless you -really- trust that write cache, be careful! > > -Eric > > On Wed, 2002-07-24 at 13:23, Florin Andrei wrote: > > >From a pure performance perspective, i wonder if anyone tried to put the > > logdev on IDE while using SCSI for the actual XFS disks/arrays. > > > > Theoretically, the new IDE drives should be quite fast, but anyway, if > > anyone tried that, i'd like to hear whatever good/bad things happened, > > performance-wise. > > > > -- > > Florin Andrei > > > > "Still wondering why they called it 'United Linux'. Firstly it sounds > > like a football team and secondly wouldn't 'Turbo Susiva' have sounded > > much better?" - Alan Cox > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > -- Florin Andrei "Still wondering why they called it 'United Linux'. Firstly it sounds like a football team and secondly wouldn't 'Turbo Susiva' have sounded much better?" - Alan Cox From owner-linux-xfs@oss.sgi.com Wed Jul 24 12:50:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OJoaRw009657 for ; Wed, 24 Jul 2002 12:50:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OJoapd009656 for linux-xfs-outgoing; Wed, 24 Jul 2002 12:50:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OJoRRw009621 for ; Wed, 24 Jul 2002 12:50:28 -0700 Received: (qmail 23369 invoked by uid 500); 24 Jul 2002 19:51:11 -0000 Subject: Re: Who's using XFS? (again) From: Austin Gonyou To: linux-xfs@oss.sgi.com Cc: Eric Sandeen In-Reply-To: <3D3DD34C.BBFCBF7C@rebel.net.au> References: <3D3DD34C.BBFCBF7C@rebel.net.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Ugz9vUu3tHbjKoFic+Jv" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 24 Jul 2002 14:51:11 -0500 Message-Id: <1027540271.23316.3.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-Ugz9vUu3tHbjKoFic+Jv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We are currently using XFS for 25+ production web-servers, ~900GB Oracle db servers, with potentially 15+ more servers by mid 2003, with ~900GB+ databases. All XFS installed.=20 Also, our dev environment, except for the Sun boxes which all are being migrated to X86 in the aforementioned server additions, plus the dev Sun boxes as well, are all x86 dual proc servers running Oracle, application servers, or web services as needed. All servers run XFS from images we've got on our SystemImager servers. All production back-end servers are connected via FC1 or FC2 to a SAN containing ~13TB of raw storage, which, will soon be converted from VxFS to XFS with the migration of Oracle to our x86 platforms.=20 This number will only increase as time goes on. So, I'd say, "Yeah, we use XFS too." :) --=20 Austin Gonyou Coremetrics, Inc. --=-Ugz9vUu3tHbjKoFic+Jv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9PwUv94g6ZVmFMoIRAu5rAJ4hCQ5yo4s4y0zUBzpU64sR87JrPQCguDSQ yj1++lptY5i2V+xefWTCKCE= =YsZP -----END PGP SIGNATURE----- --=-Ugz9vUu3tHbjKoFic+Jv-- From owner-linux-xfs@oss.sgi.com Wed Jul 24 14:02:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OL2ARw014538 for ; Wed, 24 Jul 2002 14:02:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OL2AIm014537 for linux-xfs-outgoing; Wed, 24 Jul 2002 14:02:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OL25Rw014509 for ; Wed, 24 Jul 2002 14:02:05 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g6OL36xg031597; Wed, 24 Jul 2002 23:03:06 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g6OL36327869; Wed, 24 Jul 2002 23:03:06 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 24 Jul 2002 23:03:06 +0200 (CEST) From: Seth Mos To: Willi Langenberger cc: linux-xfs@oss.sgi.com Subject: Re: xfs and openafs problem In-Reply-To: <15677.25943.919190.769477@slime.wu-wien.ac.at> Message-ID: <20020724230227.I27801-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 23 Jul 2002, Willi Langenberger wrote: > Kernel 2.4.9-21SGI_XFS_1.0.2 seems to work fine with AFS (no hangs). Can you try CVS as well? Thanks, Seth From owner-linux-xfs@oss.sgi.com Wed Jul 24 14:07:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OL7NRw014766 for ; Wed, 24 Jul 2002 14:07:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OL7NCx014765 for linux-xfs-outgoing; Wed, 24 Jul 2002 14:07:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OL7IRw014737 for ; Wed, 24 Jul 2002 14:07:19 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g6OL8IXU091794; Wed, 24 Jul 2002 23:08:18 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g6OL8Ic28061; Wed, 24 Jul 2002 23:08:18 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 24 Jul 2002 23:08:18 +0200 (CEST) From: Seth Mos To: Skylar Thompson cc: linux-xfs@oss.sgi.com Subject: Re: NFS In-Reply-To: <20020723145840.GB2018@thangorodrim.thompson.us> Message-ID: <20020724230655.O27801-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 23 Jul 2002, Skylar Thompson wrote: > Is XFS still unstable when accessed over NFS? I know that was an issue for > a while, and I myself had near-instant hangs on my server whenever NFS > requests went to an XFS filesystem. I am thinking of moving over to XFS due > to better quota support, but I need to be able to use NFS as well. Lot's of people are using it on this list including me and it works for them. I do know of issues with simultaneous local and nfs access of files. (xfsdump backup and used of NFS) cheers Seth From owner-linux-xfs@oss.sgi.com Wed Jul 24 14:09:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OL9ARw014939 for ; Wed, 24 Jul 2002 14:09:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OL9Apa014938 for linux-xfs-outgoing; Wed, 24 Jul 2002 14:09:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OL8wRw014909 for ; Wed, 24 Jul 2002 14:08:58 -0700 Received: from mail.automatix.de (www.automatix.de [212.4.161.35]) 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 OAA04765 for ; Wed, 24 Jul 2002 14:10:31 -0700 (PDT) mail_from (jojo@automatix.de) Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17XTFE-0002N2-00 for linux-xfs@oss.sgi.com; Wed, 24 Jul 2002 23:00:28 +0200 Received: from [192.168.11.12] (helo=pc2) by s.automatix.de with esmtp (Exim 3.15 #1) id 17XTDF-0006hq-00; Wed, 24 Jul 2002 22:58:25 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Juergen Sauer Organization: AutomatiX GmbH To: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Who's using XFS? (again) Date: Wed, 24 Jul 2002 22:58:07 +0200 User-Agent: KMail/1.4.2 References: <1027117051.12810.74.camel@stout.americas.sgi.com> In-Reply-To: <1027117051.12810.74.camel@stout.americas.sgi.com> MIME-Version: 1.0 Message-Id: <200207242258.12989.jojo@automatix.de> X-MIME-Autoconverted: from 8bit to quoted-printable by sgi.com id OAA04765 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6OL8xRw014910 X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK,PORN_11,PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 20. Juli 2002 00:17 schrieb Eric Sandeen: > Hi all - > I've been asked to take another pulse of the XFS user community; we did > this a while ago, and the results are at > http://oss.sgi.com/projects/xfs/xfs_users.html > If you're using XFS in an interesting/large/impressive/unique > installation, or your company is shipping a product using XFS (and you > can go on the record about it*) I'd like to know, so I can update the > information in the above web page. We use XFS exlusively on about 15 production servers. The biggest is called 'goliath', which is a fileserver >4 TeraByte. We run XFS 1.1 in Kernel 2.4.18-xfs, CVS from 1,5 month ago. XFS seems to us the most reliable an most usable filesystem in the Linux world. My production test on goliath was Power-off without any shutdown, more than 10 times. The system (XFS is root fs) came up in a glance. Later a SapDB Server was added on extra hdd space. XFS succeeded our hard-core crash/power down crash tests also very fine. SapDB (see: http://www.sapdb.org, http://sapdb.automatix.de, GPLed enterprise class RDBMS, compareable to Oracle, successor and anchestor of Adabas D) runns very fin on XFS in Linux. We were heavyly disapointed in reiserfs. Sure the theretical specs are impressive, but there was missing realiabilit. We say only: NFS+disapearing files until next boot. We can not recommend ext2/ext3 due extensive filesystem checks. Ext3 is a journaled fs for starter. We hate IBM jfs due big instability. JFS is not usable for a stable, reliable system. Needs manually repair filesystem after powerloss, jfs looses data during this 'repair filesystem'. My opinion: forget jfs. As JFS was designated by SuSE as IBM partner, it was included jfs in 7.3 distribution, so we took in in a IBM friendly customer's server. We earned Only troubles. The support exchanged it against XFS on month later, now this server runns 137 days up without any further troubles. To Linus: You may forward this eMail to Linus. PErhaps he recognizes the fine work of the XFS staff. To XFS staff: GREAT WORK. KEEP ON. mfG J. Sauer CEO AutomatiX Ltd. Germany - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0/FOMACgkQW7UKI9EqarE0qgCghVZSJS8zGpl8ulQUYhtqSTkl RUQAni7p7EjTB9b1EtejkoBaABOt2sYI =uOE4 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Jul 24 14:37:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OLbNRw015355 for ; Wed, 24 Jul 2002 14:37:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OLbNcH015354 for linux-xfs-outgoing; Wed, 24 Jul 2002 14:37:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OLbDRw015326 for ; Wed, 24 Jul 2002 14:37:14 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g6OLZYV0000885; Wed, 24 Jul 2002 23:35:34 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g6OLZYO28696; Wed, 24 Jul 2002 23:35:34 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 24 Jul 2002 23:35:34 +0200 (CEST) From: Seth Mos To: Daniel Mose cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops In-Reply-To: <20020724072629.B13199@extra.netlink.se> Message-ID: <20020724232542.I27801-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 24 Jul 2002, Daniel Mose wrote: > Cheer up people, The guy that you just lost was working with XFS in > a production environment. He simply couldn't take the responsability > towards his boss for having a production server that broke down every > three days or so. It was quite brave of him to have XFS running at his > company in the first place. I had a test box in my department december 2000 that did all the stuff the stuff that the rest of my machines also did including testing with all the different clients. It wasn't untill May 2001 (Official 1.0 release) that I started using it on production machines (one by one). Today it is on all production machines and we have had a few very small XFS problems yes but most were not caused directly by XFS. Our current internet gateway/web/squid/mail server is XFS and is running a 2.4.18 CVS XFS for the last 130 days or so. The box ran a 1.0.2 release before that which was the only version that acted funny together with a squid cache. After moving up the problem never came back. Previous releases <1.0.2 never gave problems either. It just shows you that you need to test in your environment and stay off when it works flawless. I am not inclined to upgrade the kernel of this box for a long time since everything is working dandy now. > This kind of service would probably not be very hard to set up. I believe > it could be done at some university by some professor, or student, where > the XFS is already running. > (I have the feeling that a lot of XFS testing and development is done by > academy people now as we speak) the oss.sgi.com server is a server with XFS filesystems and is used no only by the XFS folks but also for the MIPS folks for instance. It does get a beating and maybe Russel, Eric or Steve can quote some numbers of GB/day it dishes out. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Jul 24 14:47:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OLlSRw016043 for ; Wed, 24 Jul 2002 14:47:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OLlS8U016042 for linux-xfs-outgoing; Wed, 24 Jul 2002 14:47:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OLlKRw016014 for ; Wed, 24 Jul 2002 14:47:21 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla2.xs4all.nl (8.12.3/8.12.3) with ESMTP id g6OLmKWA038251; Wed, 24 Jul 2002 23:48:20 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g6OLmKR28885; Wed, 24 Jul 2002 23:48:20 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 24 Jul 2002 23:48:20 +0200 (CEST) From: Seth Mos To: thomas cc: linux-xfs@oss.sgi.com Subject: Re: data recovery after hdd failure In-Reply-To: <443851548.20020724175602@ff33.cc> Message-ID: <20020724234328.N27801-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 24 Jul 2002, thomas wrote: > GOOD NEWS EVERYONE! Yay! > i will probably get myself another 80GB IDE and make some nice RAID1 > just to be extra safe, because even xfs_repair won't help me much with a > nice head crash or sth. of that sort i guess :) Then this is for you! http://www.tldp.org/HOWTO/mini/Boot+Root+Raid+LILO-4.html > ps. if someone wants to know the 80GB that ran too hot was a Maxtor 80GB > 5400rpm(!), got myself a 80GB IBM 7200rpm now but will probably exchange > it for one or two Seagate Barracudas which are supposed to be more > quiet, reliable and don't get so hot. Out of 3 IBM disks (2*30, 60) and 7 Maxtor disks (2*27, 4*40, 60) I have lost 1 IBM disk and 1 Maxtor disk. Bith were a year old. The rest is still running 24/7 in various raid arrays where possible. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Jul 24 14:54:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OLsnRw016247 for ; Wed, 24 Jul 2002 14:54:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OLsnMI016246 for linux-xfs-outgoing; Wed, 24 Jul 2002 14:54:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla1.xs4all.nl (mxzilla1.xs4all.nl [194.109.6.54]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OLsgRw016218 for ; Wed, 24 Jul 2002 14:54:43 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla1.xs4all.nl (8.12.3/8.12.3) with ESMTP id g6OLthSU063835; Wed, 24 Jul 2002 23:55:44 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g6OLthA29034; Wed, 24 Jul 2002 23:55:43 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 24 Jul 2002 23:55:43 +0200 (CEST) From: Seth Mos To: Florin Andrei cc: linux-xfs Subject: Re: logdev on IDE In-Reply-To: <1027535026.1648.5.camel@stantz.corp.sgi.com> Message-ID: <20020724235215.T27801-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 24 Jul 2002, Florin Andrei wrote: > From a pure performance perspective, i wonder if anyone tried to put the > logdev on IDE while using SCSI for the actual XFS disks/arrays. > > Theoretically, the new IDE drives should be quite fast, but anyway, if > anyone tried that, i'd like to hear whatever good/bad things happened, > performance-wise. For single processes and IDE disk is quite sufficient. When the filesystem starts to get busy to disk is getting hopelessly slaughterd. Dumping Norton Ghost disk images on IDE disks works like a charm. Dumping lot's of small files on there is not such a good idea. The sequential speed is really good. It's amazing performance wise how far you can come with IDE disks these days in various forms of raid, hardware of software. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Jul 24 14:59:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OLxNRw016481 for ; Wed, 24 Jul 2002 14:59:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OLxN19016480 for linux-xfs-outgoing; Wed, 24 Jul 2002 14:59:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OLxGRw016452 for ; Wed, 24 Jul 2002 14:59:16 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g6OM0H71008248; Thu, 25 Jul 2002 00:00:17 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g6OM0H729143; Thu, 25 Jul 2002 00:00:17 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Thu, 25 Jul 2002 00:00:17 +0200 (CEST) From: Seth Mos To: Christian Guggenberger cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops In-Reply-To: <20020724203441.E791@pc9391.uni-regensburg.de> Message-ID: <20020724235619.K27801-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 24 Jul 2002, Christian Guggenberger wrote: > we are planning to integrate a gigabit interface (intel e1000) in our > fileserver (NFS) soon. > Could one of you point out some kernel (proc) tunings i should do ? > Or should the default settings work fine (and performant) ? At least make the network buffers larger as is mentioned above which makes a order of magnitude difference in performance for gigabit networks. The Intel 4.1.7 drivers are not the latest but are the best performing drivers under linux for these cards. Note that the 4.2.? drivers are reported to have halved throughput for most people.[1] Coming sunday I will replace the various broadcom gigabit cards in our network servers since the drivers prove to be less then stellar. Cheers 1. According to people on linux-poweredge@dell.com. grep the list archives. there. http://lists.us.dell.com/ From owner-linux-xfs@oss.sgi.com Wed Jul 24 15:33:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6OMX8Rw017094 for ; Wed, 24 Jul 2002 15:33:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6OMX8tB017093 for linux-xfs-outgoing; Wed, 24 Jul 2002 15:33:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6OMWvRw017061 for ; Wed, 24 Jul 2002 15:32:58 -0700 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id SAA02279 for ; Wed, 24 Jul 2002 18:33:54 -0400 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA10957 for ; Wed, 24 Jul 2002 18:33:54 -0400 Subject: Re: NFS From: Derek Glidden To: "linux-xfs@oss.sgi.com" In-Reply-To: <20020724230655.O27801-100000@xs1.xs4all.nl> References: <20020724230655.O27801-100000@xs1.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Jul 2002 18:33:54 -0400 Message-Id: <1027550034.21591.13.camel@two.nks.net> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-24 at 17:08, Seth Mos wrote: > On Tue, 23 Jul 2002, Skylar Thompson wrote: > > > Is XFS still unstable when accessed over NFS? I know that was an issue for > > a while, and I myself had near-instant hangs on my server whenever NFS > > requests went to an XFS filesystem. I am thinking of moving over to XFS due > > to better quota support, but I need to be able to use NFS as well. > > Lot's of people are using it on this list including me and it works for > them. I do know of issues with simultaneous local and nfs access of files. > (xfsdump backup and used of NFS) At some point, I saw something on this list that prompted me to put the "wsync" flag on all the XFS mounts that I would be sharing over NFS. Honestly, it was because someone here who understood what it meant said to do it rather than my understanding what it does. Nonetheless, I've been doing NFS on XFS at home for quite some time with no problems and our main file server here at work (about a dozen users, ofttimes very heavy activity) is all XFS shared over NFS and samba. Is 'wsync' still applicable for NFS shared XFS volumes? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Wed Jul 24 18:31:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6P1VJRw018551 for ; Wed, 24 Jul 2002 18:31:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6P1VJGH018550 for linux-xfs-outgoing; Wed, 24 Jul 2002 18:31:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6P1VCRw018522 for ; Wed, 24 Jul 2002 18:31:13 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 13DBDC01863 for ; Thu, 25 Jul 2002 09:32:09 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id B0587C01862; Thu, 25 Jul 2002 09:31:58 +0800 (PHT) Date: Thu, 25 Jul 2002 09:31:58 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: 2.4.19-rc3 Message-ID: <20020725013158.GB1325@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everyone, I noticed that 2.4.19-rc3. I haven't seen an announcement myself, but the timestamp on kernel.org shows it was released a few days after 2.4.19-rc2. Just in case this will be useful to the XFS kernel team. (CVS is still at -rc2, right? If it's already at -rc3 then I must've goofed up. Haven't seen any merge TAKE messages, though). :) --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Wed Jul 24 19:57:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6P2vaRw020740 for ; Wed, 24 Jul 2002 19:57:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6P2va6c020739 for linux-xfs-outgoing; Wed, 24 Jul 2002 19:57:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6P2vTRw020711 for ; Wed, 24 Jul 2002 19:57:29 -0700 Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) 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 TAA08161 for ; Wed, 24 Jul 2002 19:59:04 -0700 (PDT) mail_from (john.trostel@quantum.com) Received: from user-1120tm5.dsl.mindspring.com ([66.32.118.197] helo=[192.168.2.24]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17XYgn-0006PN-00; Wed, 24 Jul 2002 22:49:17 -0400 Subject: Re: 2.4.19-rc3 From: John M Trostel To: Federico Sevilla III Cc: Linux-XFS Mailing List In-Reply-To: <20020725013158.GB1325@leathercollection.ph> References: <20020725013158.GB1325@leathercollection.ph> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 24 Jul 2002 22:48:51 -0400 Message-Id: <1027565332.2165.10.camel@jtsdell> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The CVS was up to -rc3 by 7/22... ;-> On Wed, 2002-07-24 at 21:31, Federico Sevilla III wrote: > Hi everyone, > > I noticed that 2.4.19-rc3. I haven't seen an announcement myself, but > the timestamp on kernel.org shows it was released a few days after > 2.4.19-rc2. > > Just in case this will be useful to the XFS kernel team. (CVS is still > at -rc2, right? If it's already at -rc3 then I must've goofed up. > Haven't seen any merge TAKE messages, though). :) > > --> Jijo > > -- > Federico Sevilla III : > Network Administrator : The Leather Collection, Inc. > GnuPG Key ID : 0x93B746BE > -- John M. Trostel Senior Software Engineer Quantum Corp. / SSG john.trostel@quantum.com From owner-linux-xfs@oss.sgi.com Wed Jul 24 21:14:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6P4EtRw022161 for ; Wed, 24 Jul 2002 21:14:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6P4EtRf022160 for linux-xfs-outgoing; Wed, 24 Jul 2002 21:14:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6P4EmRw022130 for ; Wed, 24 Jul 2002 21:14:49 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 6850EC01870 for ; Thu, 25 Jul 2002 12:15:46 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 69390C0186F; Thu, 25 Jul 2002 12:15:37 +0800 (PHT) Date: Thu, 25 Jul 2002 12:15:37 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Re: 2.4.19-rc3 Message-ID: <20020725041537.GF1325@leathercollection.ph> References: <20020725013158.GB1325@leathercollection.ph> <1027565332.2165.10.camel@jtsdell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1027565332.2165.10.camel@jtsdell> User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jul 24, 2002 at 10:48:51PM -0400, John M Trostel wrote: > The CVS was up to -rc3 by 7/22... ;-> Hrmm... I didn't seem to get any notice about that via the usual TAKE messages. None turned up when I searched marc.theaimsgroup.com's archives, either. I guess I'll have to update my copy of CVS and double-check. Thanks. --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Wed Jul 24 22:26:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6P5QkRw023416 for ; Wed, 24 Jul 2002 22:26:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6P5QkrC023415 for linux-xfs-outgoing; Wed, 24 Jul 2002 22:26:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from foundoor.com ([218.1.114.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6P5QbRx023381 for ; Wed, 24 Jul 2002 22:26:39 -0700 Message-Id: <200207250526.g6P5QbRx023381@oss.sgi.com> From: "sales" Subject: power cables To: linux-xfs@oss.sgi.com Content-Type: text/plain;charset="GB2312" Reply-To: sales@foundoor.com Date: Thu, 25 Jul 2002 13:30:21 +0800 X-Priority: 3 X-Mailer: FoxMail 3.11 Release [cn] X-Spam-Status: No, hits=-0.9 required=5.0 tests=DEAR_SOMEBODY,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear Sir or Madam, It's an honor to know your company through the website. We are a large manufacturer of which specialize in manufacturing and exporting all kinds of power cords, plugs, cordsets, extension cords, sockets, and so on. Now we are planning to incorporate our business activities in your market, and we will be much obliged for your introduction to a most reliable importer handling this field. We've exported a large quantity of power cords to many countries, and enjoying a high reputation through excellent quality and price. We believe you have a great demand of power cords, please don't hesitate to contact us if you are interested in. Please advise us the following: 1) Cable specification: VDE approved H05VV-F, H03VV-F, H03VVH2-F, H05RN-F,¡­UL approved SJT, SJTW, HPN 18AWG, 16AWG, with USA plug. 2) Length, Color, requirement of the end. 3) Which types about plug? 4) Quantity per order? Please send us the drawings for these items so that we can quote you the best offer immediately. Please transfer this letter to Purchasing Department of your company when you received it. Your kind attention to this matter will be much appreciated. With thanks and best regards, Shanghai Foundoor Electrical Co., Ltd. Steven Xu Contact information: Shanghai Foundoor Electrical Co., Ltd. Office Address: RM 204, No. 54, Lane 250, Zhenjin Road, Shanghai, China 200333 Tel: 86-21-56348070 Fax: 86-21-56348069 E-mail: sales@foundoor.com http://www.foundoor.com From owner-linux-xfs@oss.sgi.com Thu Jul 25 00:26:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6P7QnRw025994 for ; Thu, 25 Jul 2002 00:26:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6P7QnAC025993 for linux-xfs-outgoing; Thu, 25 Jul 2002 00:26:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bradsea_data.bradsontech.com (www.bradsontech.com [63.231.16.36]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6P7QcRw025959 for ; Thu, 25 Jul 2002 00:26:38 -0700 Received: by bradsea_data.bradsontech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 00:27:41 -0700 Message-ID: <21A48681B6FFD511BE0E0008C79FE5900DA25D@bradsea_data.bradsontech.com> From: John Fabello To: "'sales '" , "'linux-xfs@oss.sgi.com '" Subject: RE: power cables Date: Thu, 25 Jul 2002 00:27:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6P7QcRw025960 X-Spam-Status: No, hits=-0.5 required=5.0 tests=DEAR_SOMEBODY version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk a strong dos sounds about right -----Original Message----- From: sales To: linux-xfs@oss.sgi.com Sent: 7/24/2002 10:30 PM Subject: power cables Dear Sir or Madam, It's an honor to know your company through the website. We are a large manufacturer of which specialize in manufacturing and exporting all kinds of power cords, plugs, cordsets, extension cords, sockets, and so on. Now we are planning to incorporate our business activities in your market, and we will be much obliged for your introduction to a most reliable importer handling this field. We've exported a large quantity of power cords to many countries, and enjoying a high reputation through excellent quality and price. We believe you have a great demand of power cords, please don't hesitate to contact us if you are interested in. Please advise us the following: 1) Cable specification: VDE approved H05VV-F, H03VV-F, H03VVH2-F, H05RN-F,¡­UL approved SJT, SJTW, HPN 18AWG, 16AWG, with USA plug. 2) Length, Color, requirement of the end. 3) Which types about plug? 4) Quantity per order? Please send us the drawings for these items so that we can quote you the best offer immediately. Please transfer this letter to Purchasing Department of your company when you received it. Your kind attention to this matter will be much appreciated. With thanks and best regards, Shanghai Foundoor Electrical Co., Ltd. Steven Xu Contact information: Shanghai Foundoor Electrical Co., Ltd. Office Address: RM 204, No. 54, Lane 250, Zhenjin Road, Shanghai, China 200333 Tel: 86-21-56348070 Fax: 86-21-56348069 E-mail: sales@foundoor.com http://www.foundoor.com From owner-linux-xfs@oss.sgi.com Thu Jul 25 00:36:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6P7atRw026479 for ; Thu, 25 Jul 2002 00:36:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6P7at5u026478 for linux-xfs-outgoing; Thu, 25 Jul 2002 00:36:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6P7alRw026448 for ; Thu, 25 Jul 2002 00:36:48 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g6P7cLq16996; Thu, 25 Jul 2002 09:38:21 +0200 Date: Thu, 25 Jul 2002 09:38:21 +0200 (CEST) From: Matteo Centonza To: Seth Mos cc: Skylar Thompson , Subject: Re: NFS In-Reply-To: <20020724230655.O27801-100000@xs1.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Seth, > > Is XFS still unstable when accessed over NFS? I know that was an issue for > > a while, and I myself had near-instant hangs on my server whenever NFS > > requests went to an XFS filesystem. I am thinking of moving over to XFS due > > to better quota support, but I need to be able to use NFS as well. > > Lot's of people are using it on this list including me and it works for > them. I do know of issues with simultaneous local and nfs access of files. > (xfsdump backup and used of NFS) hopefully this issue has been solved: http://marc.theaimsgroup.com/?l=linux-xfs&m=102036006319547&w=2 Fortunately, I've never seen that oops again since then ;) Ciao, -m From owner-linux-xfs@oss.sgi.com Thu Jul 25 03:30:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PAUQRw031734 for ; Thu, 25 Jul 2002 03:30:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PAUQ0f031733 for linux-xfs-outgoing; Thu, 25 Jul 2002 03:30:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PAU2Rw031673 for ; Thu, 25 Jul 2002 03:30:05 -0700 Received: from starfleet.thompson.us (slip-32-100-182-65.wi.us.prserv.net[32.100.182.65]) by prserv.net (out2) with ESMTP id <2002072510310520204laa8ve>; Thu, 25 Jul 2002 10:31:05 +0000 Received: from thangorodrim.thompson.us ([192.168.0.254]) by starfleet.thompson.us (8.11.6/8.11.6) with ESMTP id g6P6c3Y12851 for ; Thu, 25 Jul 2002 01:38:44 -0500 Received: by thangorodrim.thompson.us (Postfix, from userid 502) id A1E8B35D0380; Thu, 25 Jul 2002 01:37:33 -0500 (CDT) Date: Thu, 25 Jul 2002 01:37:33 -0500 From: Skylar Thompson To: "linux-xfs@oss.sgi.com" Subject: Re: NFS Message-ID: <20020725063733.GB3940@thangorodrim.thompson.us> Reply-To: Skylar Thompson Mail-Followup-To: "linux-xfs@oss.sgi.com" References: <20020724230655.O27801-100000@xs1.xs4all.nl> <1027550034.21591.13.camel@two.nks.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline In-Reply-To: <1027550034.21591.13.camel@two.nks.net> User-Agent: Mutt/1.4i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: smtp1.thompson.us X-System: Dual 450MHz Xeons with 256MB PC100 ECC-SDRAM X-Machine: IBM Intellistation Z Pro 6865-22U X-Operating-System: Red Hat Linux 7.2 with kernel 2.4.18-grsec Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 26 2002 21:28:16) X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,KNOWN_BAD_DIALUPS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2002 at 06:33:54PM -0400, Derek Glidden wrote: > At some point, I saw something on this list that prompted me to put the > "wsync" flag on all the XFS mounts that I would be sharing over NFS.=20 > Honestly, it was because someone here who understood what it meant said > to do it rather than my understanding what it does. Nonetheless, I've > been doing NFS on XFS at home for quite some time with no problems and > our main file server here at work (about a dozen users, ofttimes very > heavy activity) is all XFS shared over NFS and samba. >=20 > Is 'wsync' still applicable for NFS shared XFS volumes? I don't know. It's not mentioned in the man page for /etc/exports, and doing an "apropos wsync" only turns up curses commands. --=20 -- Skylar Thompson (skylar@attglobal.net) --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9P5ytYyzijMrwBxERAnbnAJwO+tznQjv+pHLtxTvH7FaSf1g6BwCfZ5MJ vKPZFwe1tGiG+h2IVdih42M= =KUak -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI-- From owner-linux-xfs@oss.sgi.com Thu Jul 25 03:30:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PAUSRw031739 for ; Thu, 25 Jul 2002 03:30:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PAUSoc031738 for linux-xfs-outgoing; Thu, 25 Jul 2002 03:30:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PAU2Rx031673 for ; Thu, 25 Jul 2002 03:30:06 -0700 Received: from starfleet.thompson.us (slip-32-100-182-65.wi.us.prserv.net[32.100.182.65]) by prserv.net (out2) with ESMTP id <2002072510310720204laa90e>; Thu, 25 Jul 2002 10:31:07 +0000 Received: from thangorodrim.thompson.us ([192.168.0.254]) by starfleet.thompson.us (8.11.6/8.11.6) with ESMTP id g6P5k9Y12144 for ; Thu, 25 Jul 2002 00:46:49 -0500 Received: by thangorodrim.thompson.us (Postfix, from userid 502) id 3A9D535D0380; Thu, 25 Jul 2002 00:45:39 -0500 (CDT) Date: Thu, 25 Jul 2002 00:45:39 -0500 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: NFS Message-ID: <20020725054538.GA3940@thangorodrim.thompson.us> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020723145840.GB2018@thangorodrim.thompson.us> <20020724015709.GA3324@thangorodrim.thompson.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20020724015709.GA3324@thangorodrim.thompson.us> User-Agent: Mutt/1.4i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: smtp1.thompson.us X-System: Dual 450MHz Xeons with 256MB PC100 ECC-SDRAM X-Machine: IBM Intellistation Z Pro 6865-22U X-Operating-System: Red Hat Linux 7.2 with kernel 2.4.18-grsec Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 26 2002 21:28:16) X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,KNOWN_BAD_DIALUPS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2002 at 08:57:09PM -0500, Skylar Thompson wrote: >=20 > OK. I'll report back on the results once I finish the transition tonight. I have successfully completed the transition from Ext3 to XFS, and all seems to be working fine. I have put the server under heavy load by dd'ing stuff over NFS from many client machines at once, and everything stays together, so I think I'll be fine. I kept a backup ext3 / filesystem just in case something goes wrong and I have to recover from non-XFS rescue disks. --=20 -- Skylar Thompson (skylar@attglobal.net) --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9P5CCYyzijMrwBxERAuQ/AJ9xh0kJCGRP6dfUr4q+66pZrftUcACfQNEJ yxitPLZMFWdVgsjXH+UDfN4= =nMeO -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-linux-xfs@oss.sgi.com Thu Jul 25 04:13:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PBDTRw000800 for ; Thu, 25 Jul 2002 04:13:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PBDTIj000799 for linux-xfs-outgoing; Thu, 25 Jul 2002 04:13:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PBDMRw000767 for ; Thu, 25 Jul 2002 04:13:23 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g6PBELK27650 for ; Thu, 25 Jul 2002 20:14:21 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g6PBEKs27302 for ; Thu, 25 Jul 2002 20:14:20 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g6PBEKo19865 for ; Thu, 25 Jul 2002 20:14:20 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA442 for ; Thu, 25 Jul 2002 20:14:18 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Thu Jul 25 20:14:17 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g6PBEIA81425 for ; Thu, 25 Jul 2002 20:14:18 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g6PBEIY21206 for ; Thu, 25 Jul 2002 20:14:18 +0900 To: linux-xfs@oss.sgi.com Subject: procfs on ia64 X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Honest Recruiter) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020725201418S.masano@tnes.nec.co.jp> Date: Thu, 25 Jul 2002 20:14:18 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 23 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, On 64bit linux system, "/proc/sys/vm/pagebuf/*" interface is a little broken. I cannot get the parameters. linux/fs/xfs/pagebuf/page_buf.c: static ctl_table pagebuf_table[] = { {PB_FLUSH_INT, "flush_int", &pb_params.data[0], sizeof(int), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, &sysctl_intvec, NULL, &pagebuf_min[0], &pagebuf_max[0]}, {PB_FLUSH_AGE, "flush_age", &pb_params.data[1], sizeof(int), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, &sysctl_intvec, NULL, &pagebuf_min[1], &pagebuf_max[1]}, {PB_STATS_CLEAR, "stats_clear", &pb_params.data[3], sizeof(int), 0644, NULL, &pb_stats_clear_handler, &sysctl_intvec, NULL, &pagebuf_min[3], &pagebuf_max[3]}, "sizeof(int)" must be "sizeof(ulong)" :). And "/proc/sys/fs/xfs/*" is likewise. -- Masano From owner-linux-xfs@oss.sgi.com Thu Jul 25 06:14:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PDEPRw003039 for ; Thu, 25 Jul 2002 06:14:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PDEFjd003038 for linux-xfs-outgoing; Thu, 25 Jul 2002 06:14:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from extrly.fac.com (extrly.fac.com [64.239.86.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PDCSRw003001; Thu, 25 Jul 2002 06:12:45 -0700 Received: from albexsvr.fac.com (albexsvr.fac.com [12.152.246.67]) by extrly.fac.com (8.11.6/8.11.6) with ESMTP id g6PDDCq28064; Thu, 25 Jul 2002 09:13:12 -0400 Received: from albcm01.fac.com (albcm01.fac.com [10.2.5.60]) by albexsvr.fac.com (8.12.2/8.12.1) with ESMTP id g6PD0FgE002393; Thu, 25 Jul 2002 09:00:15 -0400 Received: from remus.fac.com (remus.fac.com [10.2.6.4]) by albcm01.fac.com (Switch-2.1.1/Switch-2.1.1) with ESMTP id U6PD00EB25164; Thu, 25 Jul 2002 09:00:14 -0400 Received: from albsmtp01.fac.com (albsmtp01 [10.2.5.41]) by remus.fac.com (8.11.3/8.11.3) with ESMTP id g6PD0Es29180; Thu, 25 Jul 2002 09:00:14 -0400 (EDT) Subject: Re: NFS To: Skylar Thompson Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jameel Akari" Date: Thu, 25 Jul 2002 09:00:12 -0400 X-MIMETrack: Serialize by Router on ALBSMTP01/First Albany(Release 5.0.8 |June 18, 2001) at 07/25/2002 08:58:05 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=85256C010046913D8f9e8a93df938690918c85256C010046913D" Content-Disposition: inline X-MailScanner: Found to be clean X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --0__=85256C010046913D8f9e8a93df938690918c85256C010046913D Content-type: text/plain; charset=us-ascii FWIW, the Linuxcare Bootable Toolbox CD 2.0 ( http://lbt.linuxcare.com/index.epl ) makes a pretty decent XFS-aware rescue disc. You can burn it on a 3" or business card CD and carry it with you. The "mount host partitions" option in the little menu doesn't work quite right, but all is well if you go to the shell. Even though it's pretty old, it seemed to work fine on a XFS 1.1 machine. I don't know offhand if it has things like xfs_repair or xfs_check though.. didn't manage to break the thing badly enough to need them. -- Jameel Akari UNIX Admin First Albany Corp Skylar Thompson cc: Sent by: Subject: Re: NFS owner-linux-xfs@o ss.sgi.com 07/25/2002 01:45 AM Please respond to Skylar Thompson On Tue, Jul 23, 2002 at 08:57:09PM -0500, Skylar Thompson wrote: > > OK. I'll report back on the results once I finish the transition tonight. I have successfully completed the transition from Ext3 to XFS, and all seems to be working fine. I have put the server under heavy load by dd'ing stuff over NFS from many client machines at once, and everything stays together, so I think I'll be fine. I kept a backup ext3 / filesystem just in case something goes wrong and I have to recover from non-XFS rescue disks. -- -- Skylar Thompson (skylar@attglobal.net) (See attached file: att13m88.dat) --0__=85256C010046913D8f9e8a93df938690918c85256C010046913D Content-type: application/octet-stream; name="att13m88.dat" Content-Disposition: attachment; filename="att13m88.dat" Content-transfer-encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBH IHYxLjAuNiAoR05VL0xpbnV4KQ0KQ29tbWVudDogRm9yIGluZm8gc2VlIGh0 dHA6Ly93d3cuZ251cGcub3JnDQoNCmlEOERCUUU5UDVDQ1l5emlqTXJ3QnhF UkF1US9BSjl4aDBrSkNHUlA2ZGZVcjRxKzY2cFpyZnRVY0FDZlFORUoNCnl4 aXRQTFpNRldkVmdzalhIK1VEZk40PQ0KPW5NZU8NCi0tLS0tRU5EIFBHUCBT SUdOQVRVUkUtLS0tLQ0K --0__=85256C010046913D8f9e8a93df938690918c85256C010046913D-- From owner-linux-xfs@oss.sgi.com Thu Jul 25 08:06:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PF6IRw009206 for ; Thu, 25 Jul 2002 08:06:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PF6Ih1009205 for linux-xfs-outgoing; Thu, 25 Jul 2002 08:06:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PF61Rw009174; Thu, 25 Jul 2002 08:06:01 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6PF6vlH084066; Thu, 25 Jul 2002 17:07:01 +0200 (CEST) Message-Id: <4.3.2.7.2.20020725170303.03906f38@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jul 2002 17:05:22 +0200 To: "Jameel Akari" , Skylar Thompson From: Seth Mos Subject: Re: NFS Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:00 25-7-2002 -0400, Jameel Akari wrote: >The "mount host partitions" option in the little menu doesn't work quite >right, but all is well if you go to the shell. Even though it's pretty >old, it seemed to work fine on a XFS 1.1 machine. I don't know offhand if >it has things like xfs_repair or xfs_check though.. didn't manage to break >the thing badly enough to need them. All xfsprogs utilities are available, dump, restore, repair and even check. The could use a good refresher though to support the newer log formats. The on disk structure is the same but the log has a newer variant out there which was not available at the time. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jul 25 08:14:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PFEuRw009414 for ; Thu, 25 Jul 2002 08:14:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PFEuDd009413 for linux-xfs-outgoing; Thu, 25 Jul 2002 08:14:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PFEmRw009385 for ; Thu, 25 Jul 2002 08:14:49 -0700 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id LAA10454 for ; Thu, 25 Jul 2002 11:15:48 -0400 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA27133 for ; Thu, 25 Jul 2002 11:15:48 -0400 Subject: Re: NFS From: Derek Glidden To: "linux-xfs@oss.sgi.com" In-Reply-To: <20020725063733.GB3940@thangorodrim.thompson.us> References: <20020724230655.O27801-100000@xs1.xs4all.nl> <1027550034.21591.13.camel@two.nks.net> <20020725063733.GB3940@thangorodrim.thompson.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Jul 2002 11:15:47 -0400 Message-Id: <1027610148.23272.5.camel@two.nks.net> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-07-25 at 02:37, Skylar Thompson wrote: > On Wed, Jul 24, 2002 at 06:33:54PM -0400, Derek Glidden wrote: > > At some point, I saw something on this list that prompted me to put the > > "wsync" flag on all the XFS mounts that I would be sharing over NFS. > > Honestly, it was because someone here who understood what it meant said > > to do it rather than my understanding what it does. Nonetheless, I've > > been doing NFS on XFS at home for quite some time with no problems and > > our main file server here at work (about a dozen users, ofttimes very > > heavy activity) is all XFS shared over NFS and samba. > > > > Is 'wsync' still applicable for NFS shared XFS volumes? > > I don't know. It's not mentioned in the man page for /etc/exports, and > doing an "apropos wsync" only turns up curses commands. It's an option to mounting an XFS filesystem - not /etc/exports. Presumably it means something like "writesync" but I'm not sure if it's still relevant to making NFS work reliably. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Thu Jul 25 08:31:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PFVDRw010636 for ; Thu, 25 Jul 2002 08:31:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PFVD45010635 for linux-xfs-outgoing; Thu, 25 Jul 2002 08:31:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PFV6Rw010601 for ; Thu, 25 Jul 2002 08:31:07 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA14346 for ; Thu, 25 Jul 2002 10:32:06 -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 KAA50121 for ; Thu, 25 Jul 2002 10:32:06 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6PFTcW06678; Thu, 25 Jul 2002 10:29:38 -0500 Message-Id: <200207251529.g6PFTcW06678@stout.americas.sgi.com> Date: Thu, 25 Jul 2002 10:29:38 -0500 Subject: TAKE - clean up buffer.c (cosmetic) X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk clean up the XFS changes to fs/buffer.c a bit (cosmetic): * make the coding style match the other functions in the file * mark the functions inline explicitly - they're used only once clean up buffer.c Date: Thu Jul 25 08:31:36 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123680a linux/fs/buffer.c - 1.109 From owner-linux-xfs@oss.sgi.com Thu Jul 25 08:37:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PFbpRw011572 for ; Thu, 25 Jul 2002 08:37:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PFbpWL011571 for linux-xfs-outgoing; Thu, 25 Jul 2002 08:37:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PFbkRw011543 for ; Thu, 25 Jul 2002 08:37:46 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA14548 for ; Thu, 25 Jul 2002 10:38:46 -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 KAA09620 for ; Thu, 25 Jul 2002 10:38:46 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6PFaIP06815; Thu, 25 Jul 2002 10:36:18 -0500 Message-Id: <200207251536.g6PFaIP06815@stout.americas.sgi.com> Date: Thu, 25 Jul 2002 10:36:18 -0500 Subject: TAKE - remove unessecary ifdefs in sysctl.h X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk declaring enum values depending on CONFIG_ options is evil. No sensible person (except of Keith) does this. remove ifdefs in sysctl.h Date: Thu Jul 25 08:37:47 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123682a linux/include/linux/sysctl.h - 1.49 From owner-linux-xfs@oss.sgi.com Thu Jul 25 08:39:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PFdSRw011743 for ; Thu, 25 Jul 2002 08:39:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PFdSRU011742 for linux-xfs-outgoing; Thu, 25 Jul 2002 08:39:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PFdNRw011713 for ; Thu, 25 Jul 2002 08:39:23 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA90943 for ; Thu, 25 Jul 2002 10:40:23 -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 KAA91108 for ; Thu, 25 Jul 2002 10:40:23 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6PFbuJ06889; Thu, 25 Jul 2002 10:37:56 -0500 Message-Id: <200207251537.g6PFbuJ06889@stout.americas.sgi.com> Date: Thu, 25 Jul 2002 10:37:56 -0500 Subject: TAKE - don't set CONFIG_QUOTACTL in 2.4 X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph again: don't set CONFIG_QUOTACTL in 2.4 it's a 2.5ism.. Date: Thu Jul 25 08:39:58 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123683a linux/fs/Config.in - 1.85 From owner-linux-xfs@oss.sgi.com Thu Jul 25 09:08:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PG8MRw012590 for ; Thu, 25 Jul 2002 09:08:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PG8LMu012589 for linux-xfs-outgoing; Thu, 25 Jul 2002 09:08:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PG8ERw012561 for ; Thu, 25 Jul 2002 09:08:14 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA15461; Thu, 25 Jul 2002 11:09:14 -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 LAA74681; Thu, 25 Jul 2002 11:09:12 -0500 (CDT) Subject: Re: procfs on ia64 From: Eric Sandeen To: ASANO Masahiro Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020725201418S.masano@tnes.nec.co.jp> References: <20020725201418S.masano@tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 25 Jul 2002 11:06:44 -0500 Message-Id: <1027613206.23229.92.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks, I guess /proc/sys/fs/xfs/ is broken in the same way. I'll get these fixed up. -Eric On Thu, 2002-07-25 at 06:14, ASANO Masahiro wrote: > Hi, > > On 64bit linux system, "/proc/sys/vm/pagebuf/*" interface is a > little broken. I cannot get the parameters. > > linux/fs/xfs/pagebuf/page_buf.c: > static ctl_table pagebuf_table[] = { > {PB_FLUSH_INT, "flush_int", &pb_params.data[0], > sizeof(int), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, > &sysctl_intvec, NULL, &pagebuf_min[0], &pagebuf_max[0]}, > > {PB_FLUSH_AGE, "flush_age", &pb_params.data[1], > sizeof(int), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, > &sysctl_intvec, NULL, &pagebuf_min[1], &pagebuf_max[1]}, > > {PB_STATS_CLEAR, "stats_clear", &pb_params.data[3], > sizeof(int), 0644, NULL, &pb_stats_clear_handler, > &sysctl_intvec, NULL, &pagebuf_min[3], &pagebuf_max[3]}, > > "sizeof(int)" must be "sizeof(ulong)" :). > And "/proc/sys/fs/xfs/*" is likewise. > -- > Masano -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Jul 25 09:20:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PGKoRw015486 for ; Thu, 25 Jul 2002 09:20:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PGKogb015485 for linux-xfs-outgoing; Thu, 25 Jul 2002 09:20:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PGKiRw015428 for ; Thu, 25 Jul 2002 09:20:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA06860 for ; Thu, 25 Jul 2002 11:21:44 -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 LAA75430 for ; Thu, 25 Jul 2002 11:21:44 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6PGJGU08003; Thu, 25 Jul 2002 11:19:16 -0500 Message-Id: <200207251619.g6PGJGU08003@stout.americas.sgi.com> Date: Thu, 25 Jul 2002 11:19:16 -0500 Subject: TAKE - remove extra MAX_BUF_PER_PAGE definition X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We had this in page_buf_io.c, but it showd up in fs.h in 2.4.19-pre9. remove extra MAX_BUF_PER_PAGE defn Date: Thu Jul 25 09:19:56 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123687a linux/fs/xfs/pagebuf/page_buf_io.c - 1.52 From owner-linux-xfs@oss.sgi.com Thu Jul 25 09:25:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PGPfRw019231 for ; Thu, 25 Jul 2002 09:25:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PGPfPB019230 for linux-xfs-outgoing; Thu, 25 Jul 2002 09:25:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PGPZRw019200 for ; Thu, 25 Jul 2002 09:25:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA19080 for ; Thu, 25 Jul 2002 11:26:36 -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 LAA02035 for ; Thu, 25 Jul 2002 11:26:35 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6PGO7l08098; Thu, 25 Jul 2002 11:24:07 -0500 Message-Id: <200207251624.g6PGO7l08098@stout.americas.sgi.com> Date: Thu, 25 Jul 2002 11:24:07 -0500 Subject: TAKE - kill buftarg.bd_targ X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk this one is used only in mount/umount code, else we use the one in buftarg.pb_targ. Reorganize the mount/umount time code to do the blkdev_get/blkdev_put on that one as well. Once I get some input from Steve on naming/placement this code will get another surgery. kill buftarg.bd_targ Date: Thu Jul 25 09:26:01 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123688a linux/fs/xfs/xfs_buf.h - 1.92 linux/fs/xfs/linux/xfs_super.c - 1.199 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.22 linux/fs/xfs/pagebuf/page_buf.h - 1.29 From owner-linux-xfs@oss.sgi.com Thu Jul 25 09:40:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PGe4Rw020169 for ; Thu, 25 Jul 2002 09:40:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PGe4bY020168 for linux-xfs-outgoing; Thu, 25 Jul 2002 09:40:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PGdtRw020134 for ; Thu, 25 Jul 2002 09:39:56 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g6PGeks00871 for linux-xfs@oss.sgi.com; Thu, 25 Jul 2002 11:40:46 -0500 Date: Thu, 25 Jul 2002 11:40:46 -0500 From: Dean Roehrich Message-Id: <200207251640.g6PGeks00871@rope.americas> Subject: TAKE - make core dmapi code independent of dmapi headers X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From Chris Hellwig: This one removes make the XFS filesystem code independent of the dmapi headers (include/linux/dmapi.h & include/linux/dmapi_kern.h). Details: * include and in xfs_dmapi.h if CONFIG_XFS_DMAPI is set instead of unconditionally in xfs.h * make most of the current contents of xfs_dmapi.h depent on CONFIG_XFS_DMAPI * provide stubs for the dmapi functionality in xfs_dmapi.h otherwise * kill xfs_dmistubs.c Date: Thu Jul 25 09:40:28 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/2.4.x-xfs-b The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123689a linux/fs/xfs/xfs_dmapi.h - 1.30 linux/fs/xfs/linux/xfs_dmistubs.c - 1.21 linux/fs/xfs/linux/Makefile - 1.56 linux/fs/xfs/xfs.h - 1.28 linux/fs/xfs/linux/Makefile.in - 1.11 - No Message Supplied From owner-linux-xfs@oss.sgi.com Thu Jul 25 10:50:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PHouRw021502 for ; Thu, 25 Jul 2002 10:50:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PHou2Q021501 for linux-xfs-outgoing; Thu, 25 Jul 2002 10:50:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PHopRw021473 for ; Thu, 25 Jul 2002 10:50:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA14254 for ; Thu, 25 Jul 2002 12:51:52 -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 MAA71835 for ; Thu, 25 Jul 2002 12:51:52 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6PHnNf08774; Thu, 25 Jul 2002 12:49:23 -0500 Message-Id: <200207251749.g6PHnNf08774@stout.americas.sgi.com> Date: Thu, 25 Jul 2002 12:49:23 -0500 Subject: TAKE - Fix sysctls on 64-bit machines X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks to ASANO Masahiro for finding this one. Date: Thu Jul 25 10:51:14 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123706a linux/fs/xfs/linux/xfs_sysctl.c - 1.6 linux/fs/xfs/pagebuf/page_buf.c - 1.45 - Use correct value for maxlen in sysctl (var is ulong, not int) This happened to work on 32 bit machines; broke in ia64. From owner-linux-xfs@oss.sgi.com Thu Jul 25 11:50:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PIocRw022512 for ; Thu, 25 Jul 2002 11:50:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PIocZl022511 for linux-xfs-outgoing; Thu, 25 Jul 2002 11:50:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PIoHRw022482 for ; Thu, 25 Jul 2002 11:50:17 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA15514 for ; Thu, 25 Jul 2002 13:51:17 -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 NAA48403 for ; Thu, 25 Jul 2002 13:51:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6PImmH12284; Thu, 25 Jul 2002 13:48:48 -0500 Message-Id: <200207251848.g6PImmH12284@stout.americas.sgi.com> Date: Thu, 25 Jul 2002 13:48:48 -0500 Subject: TAKE - Merge dmapi changes to 2.5 X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jul 25 11:50:28 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea Merged by: sandeen Merged mods: 2.4.x-xfs:slinx:123567a,2.4.x-xfs:slinx:123689a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:123711a linux/fs/Makefile - 1.62 linux/fs/Config.in - 1.95 - Merge of 2.4.x-xfs:slinx:123567a originally by roehrich on 07/23/02 From Chris Hellwig: * CONFIG_XFS_DMAPI is now a dep_mbool on CONFIG_XFS_FS, fs/xfs_dmapi/ is entered based on CONFIG_XFS_FS if CONFIG_XFS_DMAPI is set to keep the old behaviour. * CONFIG_HAVE_XFS_DMAPI is gone, as CONFIG_XFS_DMAPI has the same meaning now. * we refuse to mount with dmapi/xdsm options now if we can't support it. * this way the dmapi_mount vfs method can't be called without dmapi support anymore. declare the two dmapi-related vfs methods only if we build with dmapi support. * fs/xfs/xfsdmapistubs.c is gone, all stubs for XFS-own dmapi-related functions are inlines in xfs_dmapi.h now. * xfs_dmapi_mmap_event is renamed to xfs_dm_send_mmap_event to match the other xfs_dm_send_* functions No Message Supplied linux/fs/xfs/xfs_dmapi.h - 1.29 - Merge of 2.4.x-xfs:slinx:123567a originally by roehrich on 07/23/02 From Chris Hellwig: * CONFIG_XFS_DMAPI is now a dep_mbool on CONFIG_XFS_FS, fs/xfs_dmapi/ is entered based on CONFIG_XFS_FS if CONFIG_XFS_DMAPI is set to keep the old behaviour. * CONFIG_HAVE_XFS_DMAPI is gone, as CONFIG_XFS_DMAPI has the same meaning now. * we refuse to mount with dmapi/xdsm options now if we can't support it. * this way the dmapi_mount vfs method can't be called without dmapi support anymore. declare the two dmapi-related vfs methods only if we build with dmapi support. * fs/xfs/xfsdmapistubs.c is gone, all stubs for XFS-own dmapi-related functions are inlines in xfs_dmapi.h now. * xfs_dmapi_mmap_event is renamed to xfs_dm_send_mmap_event to match the other xfs_dm_send_* functions No Message Supplied Merge of 2.4.x-xfs:slinx:123689a originally by roehrich on 07/25/02 From Chris Hellwig: This one removes make the XFS filesystem code independent of the dmapi headers (include/linux/dmapi.h & include/linux/dmapi_kern.h). Details: * include and in xfs_dmapi.h if CONFIG_XFS_DMAPI is set instead of unconditionally in xfs.h * make most of the current contents of xfs_dmapi.h depent on CONFIG_XFS_DMAPI * provide stubs for the dmapi functionality in xfs_dmapi.h otherwise * kill xfs_dmistubs.c No Message Supplied linux/fs/xfs/xfs_dmapi.c - 1.79 linux/fs/xfs/Makefile - 1.151 linux/fs/xfs/xfs_vfsops.c - 1.362 linux/fs/xfs/xfsdmapistubs.c - 1.13 - Merge of 2.4.x-xfs:slinx:123567a originally by roehrich on 07/23/02 From Chris Hellwig: * CONFIG_XFS_DMAPI is now a dep_mbool on CONFIG_XFS_FS, fs/xfs_dmapi/ is entered based on CONFIG_XFS_FS if CONFIG_XFS_DMAPI is set to keep the old behaviour. * CONFIG_HAVE_XFS_DMAPI is gone, as CONFIG_XFS_DMAPI has the same meaning now. * we refuse to mount with dmapi/xdsm options now if we can't support it. * this way the dmapi_mount vfs method can't be called without dmapi support anymore. declare the two dmapi-related vfs methods only if we build with dmapi support. * fs/xfs/xfsdmapistubs.c is gone, all stubs for XFS-own dmapi-related functions are inlines in xfs_dmapi.h now. * xfs_dmapi_mmap_event is renamed to xfs_dm_send_mmap_event to match the other xfs_dm_send_* functions No Message Supplied linux/fs/xfs/linux/xfs_dmistubs.c - 1.20 - Merge of 2.4.x-xfs:slinx:123567a originally by roehrich on 07/23/02 From Chris Hellwig: * CONFIG_XFS_DMAPI is now a dep_mbool on CONFIG_XFS_FS, fs/xfs_dmapi/ is entered based on CONFIG_XFS_FS if CONFIG_XFS_DMAPI is set to keep the old behaviour. * CONFIG_HAVE_XFS_DMAPI is gone, as CONFIG_XFS_DMAPI has the same meaning now. * we refuse to mount with dmapi/xdsm options now if we can't support it. * this way the dmapi_mount vfs method can't be called without dmapi support anymore. declare the two dmapi-related vfs methods only if we build with dmapi support. * fs/xfs/xfsdmapistubs.c is gone, all stubs for XFS-own dmapi-related functions are inlines in xfs_dmapi.h now. * xfs_dmapi_mmap_event is renamed to xfs_dm_send_mmap_event to match the other xfs_dm_send_* functions No Message Supplied Merge of 2.4.x-xfs:slinx:123689a originally by roehrich on 07/25/02 From Chris Hellwig: This one removes make the XFS filesystem code independent of the dmapi headers (include/linux/dmapi.h & include/linux/dmapi_kern.h). Details: * include and in xfs_dmapi.h if CONFIG_XFS_DMAPI is set instead of unconditionally in xfs.h * make most of the current contents of xfs_dmapi.h depent on CONFIG_XFS_DMAPI * provide stubs for the dmapi functionality in xfs_dmapi.h otherwise * kill xfs_dmistubs.c No Message Supplied linux/fs/xfs/linux/xfs_file.c - 1.76 linux/fs/xfs/linux/xfs_super.h - 1.26 linux/fs/xfs/linux/xfs_super.c - 1.212 - Merge of 2.4.x-xfs:slinx:123567a originally by roehrich on 07/23/02 From Chris Hellwig: * CONFIG_XFS_DMAPI is now a dep_mbool on CONFIG_XFS_FS, fs/xfs_dmapi/ is entered based on CONFIG_XFS_FS if CONFIG_XFS_DMAPI is set to keep the old behaviour. * CONFIG_HAVE_XFS_DMAPI is gone, as CONFIG_XFS_DMAPI has the same meaning now. * we refuse to mount with dmapi/xdsm options now if we can't support it. * this way the dmapi_mount vfs method can't be called without dmapi support anymore. declare the two dmapi-related vfs methods only if we build with dmapi support. * fs/xfs/xfsdmapistubs.c is gone, all stubs for XFS-own dmapi-related functions are inlines in xfs_dmapi.h now. * xfs_dmapi_mmap_event is renamed to xfs_dm_send_mmap_event to match the other xfs_dm_send_* functions No Message Supplied linux/fs/xfs/xfs.h - 1.28 - Merge of 2.4.x-xfs:slinx:123689a originally by roehrich on 07/25/02 From Chris Hellwig: This one removes make the XFS filesystem code independent of the dmapi headers (include/linux/dmapi.h & include/linux/dmapi_kern.h). Details: * include and in xfs_dmapi.h if CONFIG_XFS_DMAPI is set instead of unconditionally in xfs.h * make most of the current contents of xfs_dmapi.h depent on CONFIG_XFS_DMAPI * provide stubs for the dmapi functionality in xfs_dmapi.h otherwise * kill xfs_dmistubs.c No Message Supplied linux/fs/Config.help - 1.17 From owner-linux-xfs@oss.sgi.com Thu Jul 25 12:30:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PJULRw029418 for ; Thu, 25 Jul 2002 12:30:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PJULtd029417 for linux-xfs-outgoing; Thu, 25 Jul 2002 12:30:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PJUGRw029389 for ; Thu, 25 Jul 2002 12:30:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA14826 for ; Thu, 25 Jul 2002 14:31:17 -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 OAA77410 for ; Thu, 25 Jul 2002 14:31:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6PJSlY13673; Thu, 25 Jul 2002 14:28:47 -0500 Message-Id: <200207251928.g6PJSlY13673@stout.americas.sgi.com> Date: Thu, 25 Jul 2002 14:28:47 -0500 Subject: TAKE - make xfs_info/growfs report v2 log data X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This makes the xfs_info output look like mkfs output, i.e. report new v2 log information. make xfs_info/growfs report v2 log data Date: Thu Jul 25 12:30:25 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-v2log The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:123720a cmd/xfsprogs/growfs/xfs_growfs.c - 1.13 From owner-linux-xfs@oss.sgi.com Thu Jul 25 16:07:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6PN71Rw000748 for ; Thu, 25 Jul 2002 16:07:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6PN71ni000747 for linux-xfs-outgoing; Thu, 25 Jul 2002 16:07:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6PN6tRw000718 for ; Thu, 25 Jul 2002 16:06:55 -0700 Received: from medon.insight.att.com ([135.43.91.152]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g6PN7tYr002937 for ; Thu, 25 Jul 2002 19:07:56 -0400 (EDT) Received: (from bcc@localhost) by medon.insight.att.com (8.10.2+Sun/8.9.3/Insight.Master) id g6PN7tX08299; Thu, 25 Jul 2002 19:07:55 -0400 (EDT) Date: Thu, 25 Jul 2002 19:07:55 -0400 (EDT) Message-Id: <200207252307.g6PN7tX08299@medon.insight.att.com> From: bcc@insight.att.com To: linux-xfs@oss.sgi.com Subject: Question on XFS - somewhat newbie Cc: bcc@medon.insight.att.com, nelson24@medon.insight.att.com X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've installed the XFS 2.4.18 kernel and 2.0.6-0 xfs utilities on a Redhat 7.2 machine (was patched all the way as per Redhat's errata) following the instructions on the SGI website.. The machine runs the Enterprise kernel (large memory support), so I used the generic one from the download page to upgrade. The machine booted fine and runs well, but the only way I can get a large file on the new xfs partition is to use the xfs_mkfile command. I've tried ftp, rcp, and even local scripts on the machine to copy/create a file bigger than 2gb, and all options keep failing. Any advice/ suggestions to resolve/work around this are greatly appreciated. Thanx. Brian From owner-linux-xfs@oss.sgi.com Thu Jul 25 20:03:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6Q33QRw003244 for ; Thu, 25 Jul 2002 20:03:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6Q33QsV003243 for linux-xfs-outgoing; Thu, 25 Jul 2002 20:03:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6Q33DRw003213 for ; Thu, 25 Jul 2002 20:03:15 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g6Q34Ke16887 for ; Fri, 26 Jul 2002 12:04:20 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g6Q34JZ09836 for ; Fri, 26 Jul 2002 12:04:19 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g6Q34Io02585 for ; Fri, 26 Jul 2002 12:04:18 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA536 for ; Fri, 26 Jul 2002 12:04:18 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Fri Jul 26 12:04:17 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g6Q34HA27331 for ; Fri, 26 Jul 2002 12:04:17 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g6Q34HY09491 for ; Fri, 26 Jul 2002 12:04:17 +0900 To: linux-xfs@oss.sgi.com Subject: maximum file size on ia64 X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Honest Recruiter) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020726120417A.masano@tnes.nec.co.jp> Date: Fri, 26 Jul 2002 12:04:17 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 47 X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Linux-XFS file size is currently restricted to 2^(31+PAGE_SHIFT)-1 bytes. On 64bit linux, I expect we are 9000PB ready for the size of sparse file, because the data type of page cache indices is "unsigned long" and it has 64bits. What do you think about it? 8<------8<------8<------8<------8<------8<------8<------ --- linux/fs/xfs/xfs_inode.h 12 Jul 2002 16:42:01 -0000 1.164 +++ linux/fs/xfs/xfs_inode.h 26 Jul 2002 02:41:40 -0000 @@ -442,7 +442,11 @@ * signed variable to index cache data, so 2^31 * PAGE_SIZE is as big as * you can go. */ +#if BITS_PER_LONG == 64 +#define XFS_MAX_FILE_OFFSET ((long long)((1ULL<<63)-1ULL)) +#else #define XFS_MAX_FILE_OFFSET ((long long)((1ULL<<(31+PAGE_SHIFT))-1ULL)) +#endif #if XFS_WANT_FUNCS || (XFS_WANT_SPACE && XFSSO_XFS_ITOV) struct vnode *xfs_itov(xfs_inode_t *ip); 8<------8<------8<------8<------8<------8<------8<------ BTW xfs_repair removes a file whose length is 2^63-n (0= fs_max_file_offset) { + if (o > fs_max_file_offset) { do_warn( "inode %llu - extent offset too large - start %llu, count %llu, offset %llu\n", ino, s, c, o); 8<------8<------8<------8<------8<------8<------8<------ -- Masano From owner-linux-xfs@oss.sgi.com Thu Jul 25 23:34:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6Q6YlRw008004 for ; Thu, 25 Jul 2002 23:34:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6Q6YlN2008003 for linux-xfs-outgoing; Thu, 25 Jul 2002 23:34:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6Q6YbRw007959 for ; Thu, 25 Jul 2002 23:34:37 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.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 XAA08630 for ; Thu, 25 Jul 2002 23:35:44 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g6Q6YfQR15228368; Thu, 25 Jul 2002 23:34:42 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 613E63000BA; Fri, 26 Jul 2002 16:34:39 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id E37E194; Fri, 26 Jul 2002 16:34:39 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Federico Sevilla III Cc: Linux-XFS Mailing List Subject: Re: 2.4.19-rc3 In-reply-to: Your message of "Thu, 25 Jul 2002 12:15:37 +0800." <20020725041537.GF1325@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Jul 2002 16:34:34 +1000 Message-ID: <9867.1027665274@kao2.melbourne.sgi.com> X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 25 Jul 2002 12:15:37 +0800, Federico Sevilla III wrote: >On Wed, Jul 24, 2002 at 10:48:51PM -0400, John M Trostel wrote: >> The CVS was up to -rc3 by 7/22... ;-> > >Hrmm... I didn't seem to get any notice about that via the usual TAKE >messages. None turned up when I searched marc.theaimsgroup.com's >archives, either. I guess I'll have to update my copy of CVS and >double-check. My fault, I sent the TAKE message to the internal XFS list instead of the external one. Upgrade to 2.4.19-rc3 Date: Sun Jul 21 18:40:51 PDT 2002 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:123432a linux/net/rose/af_rose.c - 1.23 linux/include/linux/personality.h - 1.11 linux/drivers/sound/cs4232.c - 1.12 linux/drivers/scsi/megaraid.c - 1.33 linux/drivers/scsi/atp870u.c - 1.19 linux/drivers/scsi/aha152x.c - 1.27 linux/drivers/pci/quirks.c - 1.30 linux/arch/i386/kernel/traps.c - 1.45 linux/arch/i386/kernel/apm.c - 1.40 linux/Makefile - 1.175 linux/drivers/pci/names.c - 1.11 linux/drivers/sound/maestro.c - 1.27 linux/include/linux/pci_ids.h - 1.60 linux/include/linux/agp_backend.h - 1.17 linux/drivers/char/agp/agpgart_be.c - 1.34 linux/drivers/char/agp/agp.h - 1.23 linux/drivers/scsi/scsi_scan.c - 1.25 linux/drivers/ide/ide-pci.c - 1.22 linux/drivers/ide/ide-features.c - 1.11 linux/scripts/kernel-doc - 1.14 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.13 linux/arch/i386/kernel/pci-irq.c - 1.22 linux/drivers/media/radio/radio-zoltrix.c - 1.8 linux/mm/shmem.c - 1.32 linux/drivers/net/wireless/orinoco_plx.c - 1.6 linux/drivers/usb/rtl8150.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jul 26 03:05:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6QA5KRw011982 for ; Fri, 26 Jul 2002 03:05:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6QA5Kjj011981 for linux-xfs-outgoing; Fri, 26 Jul 2002 03:05:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lorien.slab.de (argonath.slab.de [193.197.0.146]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6Q9uKRw011851 for ; Fri, 26 Jul 2002 02:56:21 -0700 Received: from slab.de (feanor.slab.de [192.168.124.100]) by lorien.slab.de (Postfix) with ESMTP id 85BFAA045; Fri, 26 Jul 2002 11:57:25 +0200 (CEST) Message-ID: <3D411D05.9020301@slab.de> Date: Fri, 26 Jul 2002 11:57:25 +0200 From: Lars Soltau Reply-To: lars.soltau@slab.de Organization: sLAB oHG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: de-de, en MIME-Version: 1.0 To: Tim Shimmin Cc: linux-xfs@oss.sgi.com Subject: Re: problems with restore References: <20020723114554.J2935839@boing.melbourne.sgi.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020503080208080107080601" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms020503080208080107080601 Content-Type: multipart/mixed; boundary="------------020001030404080908020804" This is a multi-part message in MIME format. --------------020001030404080908020804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Shimmin wrote: > > 1. I don't believe that xfsdump/restore is too complicated to use. > It has an awful lot of options (I agree) but there are examples > on what ones are needed to get a basic dump and restore happening: > check out the examples sections in: > - cmd/xfsdump/doc/README.xfsdump > - xfsdump(8) and xfsrestore(8) man pages True, my real peeve was getting xfsrestore to read a tape backup from disk. > > 2. [...] So one is not supposed to copy a dump from tape onto a disk file and > then restore it. [...] Well, that's not very helpful. :-) I had some old tapes and borrowed a matching streamer to restore them. After the restore directly from tape failed with an assertion failure (see blow), I copied the files to disk because I had to return the streamer before I had a chance to do a full examination of the assertion failure. I ended up patching drive_minrmt.c to forget about all SCSI commands and open consecutively numbered files on hard disk instead. It would be a nice feature for xfsrestore to be able to open a tape backup from disk, wouldn't it? > > 3. I don't know why xfsrestore is aborting with an assertion failure for you. I do, now. I single-stepped into the assertion and found out that one 64bit offset in each record header, the first_mark_offset, had been written highendian instead of littleendian. All the other offsets, for example file_offset that is located directly before first_mark_offset, had been written correctly. The backup has been written by a version of xfsdump compiled with egcs on Linux. Personally, I suspect egcs's 64bit arithmetic. Anyway, I patched the source to correct the offset on the fly and the problem vanished. In case anyone is interested I have attached the patched drive_minrmt.c file from xfsdump-2.0.1. Greetings Lars Soltau --------------020001030404080908020804 Content-Type: text/plain; name="drive_minrmt.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="drive_minrmt.c" /* * Copyright (c) 2000 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as * published by the Free Software Foundation. * * This program is distributed in the hope that it would be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * Further, this software is distributed without any warranty that it is * free of the rightful claim of any third person regarding infringement * or the like. Any license provided herein, whether implied or * otherwise, applies only to this software file. Patent licenses, if * any, provided herein do not apply to combinations of this program with * other software, or any other product whatsoever. * * You should have received a copy of the GNU General Public License along * with this program; if not, write the Free Software Foundation, Inc., 59 * Temple Place - Suite 330, Boston MA 02111-1307, USA. * * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, * Mountain View, CA 94043, or: * * http://www.sgi.com * * For further information regarding this notice, see: * * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "types.h" #include "util.h" #include "qlock.h" #include "cldmgr.h" #include "mlog.h" #include "dlog.h" #include "global.h" #include "drive.h" #include "media.h" #include "getopt.h" #include "stream.h" #include "ring.h" #include "rec_hdr.h" #include "arch_xlate.h" /* drive_minrmt.c - drive strategy for non-SGI rmt tape devices * This strategy is derived from the scsitape strategy. It is designed * so that tapes written using this strategy can be read with the * scsitape strategy and vice versa. */ int lgs_fileno; char lgs_filename[256]; char lgs_filebase[256]; char *lgs_old_pathname; /* structure definitions used locally ****************************************/ /* remote tape protocol debug */ #ifdef OPENMASKED static intgen_t open_masked_signals( char *path, int oflags ); #else /* OPENMASKED */ #define open_masked_signals(p,f) open(p,f) #endif /* OPENMASKED */ #ifdef RMT #ifdef RMTDBG #define open(p,f) dbgrmtopen(p,f) #define close(fd) dbgrmtclose(fd) #define ioctl(fd,op,arg) dbgrmtioctl(fd,op,arg) #define read(fd,p,sz) dbgrmtread(fd,p,sz) #define write(fd,p,sz) dbgrmtwrite(fd,p,sz) #else /* RMTDBG */ #define open rmtopen #define close rmtclose #define ioctl rmtioctl #define read rmtread #define write rmtwrite #endif /* RMTDBG */ #endif /* RMT */ /* if the media file header structure changes, this number must be * bumped, and STAPE_VERSION_1 must be defined and recognized. */ #define STAPE_VERSION 1 /* a bizarre number to help reduce the odds of mistaking random data * for a media file or record header */ #define STAPE_MAGIC 0x13579bdf02468acell /* this much of each record is reserved for header info: the user * data always begins at this offset from the beginning of each * record. be sure global_hdr_t fits. */ #define STAPE_HDR_SZ PGSZ /* maximum tape record size. this is the max size of I/O buffers sent to drive. * note that for variable block devices this determines the block size as well. */ #define STAPE_MAX_RECSZ 0x200000 /* 2M */ /* this is the smallest maximum block size for any tape device * supported by xfsdump/xfsrestore. we use this when it is not possible * to ask the driver for block size info. */ #define STAPE_MIN_MAX_BLKSZ 0x3c000 /* 240K, 245760 */ /* QIC tapes always use 512 byte blocks */ #define QIC_BLKSZ 512 /* number of record buffers in the I/O ring */ #define RINGLEN_MIN 1 #define RINGLEN_MAX 10 #define RINGLEN_DEFAULT 3 /* tape i/o request retry limit */ #define MTOP_TRIES_MAX 10 /* operational mode. can be reading or writing, but not both */ typedef enum { OM_NONE, OM_READ, OM_WRITE } om_t; /* drive_context - control state * * NOTE: ring used only if not singlethreaded */ struct drive_context { om_t dc_mode; /* current mode of operation (READ or WRITE) */ size_t dc_ringlen; /* number of tape_recsz buffers in ring. only used * for displaying ring info */ bool_t dc_ringpinnedpr; /* are the ring buffers pinned down */ ring_t *dc_ringp; /* handle to ring */ ring_msg_t *dc_msgp; /* currently held ring message */ char *dc_bufp; /* pre-allocated record buffer (only if ring not used) */ char *dc_recp; /* pointer to current record buffer. once the current * record is completely read or written by client, * set to NULL. */ char *dc_recendp; /* always set to point to just off the end of the * current record buffer pointed to by dc_recp. valid * only when dc_recp non-NULL. */ char *dc_dataendp; /* same as dc_recendp, except for first and last * records in media file. the first record is all * pads after the header page. the last record may * have been padded (as indicated by the rec_used * field of the record header). in either case * dc_dataendp points to first padding byte. */ char *dc_ownedp; /* first byte in current buffer owned by caller. * given to caller by do_read or do_get_write_buf * set to null by do_return_read_buf or do_write. */ char *dc_nextp; /* next byte available in current buffer to give * to do_get_write_buf for writing or do_read for * reading. */ off64_t dc_reccnt; /* count of the number of records completely read or * written by client, and therefore not represented * by current dc_recp. valid initially and after * each call to do_return_read_buf or do_write. * NOT valid after a call to do_read or * do_get_write_buf. always bumped regardless of * read or write error status. */ off64_t dc_iocnt; /* count of the number of records read or written * to media without error. includes media file header * record. this is incremented when the actual I/O is * done. dc_reccnt is different, indicating what has * been seen by client. slave may have read ahead / * written behind. */ int dc_fd; /* drive file descriptor. -1 when not open */ bool_t dc_isQICpr; /* fixed 512 byte block size device. */ bool_t dc_canfsrpr; /* can seek forward records at a time */ size_t dc_blksz; /* actual tape blksize selected */ size_t dc_recsz; /* actual tape record size selected */ off64_t dc_lostrecmax; /* maximum number of records written without error * which may be lost due to a near end-of-tape * experience. a function of drive type and * compression */ bool_t dc_singlethreadedpr; /* single-threaded operation (no slave) */ bool_t dc_errorpr; /* TRUE if error encountered during reading or writing. * used to detect attempts to read or write after * error reported. */ bool_t dc_recchksumpr; /* TRUE if records should be checksumed */ bool_t dc_unloadokpr; /* ok to issue unload command when do_eject invoked. */ bool_t dc_overwritepr; /* overwrite tape without checking whats on it */ bool_t dc_singlemfilepr; /* use only one media file */ off64_t dc_filesz; /* media file size given as argument */ }; typedef struct drive_context drive_context_t; /* macros for shortcut references to context. assumes a local variable named * 'contextp'. */ #define tape_recsz ( contextp->dc_recsz ) #define tape_blksz ( contextp->dc_blksz ) /* declarations of externally defined global variables ***********************/ extern void usage( void ); #ifdef DUMP #ifdef SIZEEST extern u_int64_t min_recmfilesz; extern u_int64_t hdr_mfilesz; #endif /* SIZEEST */ #endif /* DUMP */ /* remote tape protocol declarations (should be a system header file) */ #ifdef RMT extern int rmtopen( char *, int, ... ); extern int rmtclose( int ); extern int rmtfstat( int, struct stat * ); extern int rmtioctl( int, int, ... ); extern int rmtread( int, void*, uint); extern int rmtwrite( int, const void *, uint); #endif /* RMT */ /* forward declarations of locally defined static functions ******************/ /* strategy functions */ static intgen_t ds_match( int, char *[], drive_t *, bool_t ); static intgen_t ds_instantiate( int, char *[], drive_t *, bool_t ); /* manager operations */ static bool_t do_init( drive_t * ); static bool_t do_sync( drive_t * ); static intgen_t do_begin_read( drive_t * ); static char *do_read( drive_t *, size_t , size_t *, intgen_t * ); static void do_return_read_buf( drive_t *, char *, size_t ); static void do_get_mark( drive_t *, drive_mark_t * ); static intgen_t do_seek_mark( drive_t *, drive_mark_t * ); static intgen_t do_next_mark( drive_t * ); static void do_get_mark( drive_t *, drive_mark_t * ); static void do_end_read( drive_t * ); static intgen_t do_begin_write( drive_t * ); static void do_set_mark( drive_t *, drive_mcbfp_t, void *, drive_markrec_t * ); static char * do_get_write_buf( drive_t *, size_t , size_t * ); static intgen_t do_write( drive_t *, char *, size_t ); static size_t do_get_align_cnt( drive_t * ); static intgen_t do_end_write( drive_t *, off64_t * ); static intgen_t do_fsf( drive_t *, intgen_t , intgen_t *); static intgen_t do_bsf( drive_t *, intgen_t , intgen_t *); static intgen_t do_rewind( drive_t * ); static intgen_t do_erase( drive_t * ); static intgen_t do_eject_media( drive_t * ); static intgen_t do_get_device_class( drive_t * ); static void do_display_metrics( drive_t *drivep ); static void do_quit( drive_t * ); /* misc. local utility funcs */ static intgen_t mt_op(intgen_t , intgen_t , intgen_t ); static intgen_t determine_write_error( int, int ); static intgen_t read_label( drive_t *); static bool_t tape_rec_checksum_check( drive_context_t *, char * ); static void set_recommended_sizes( drive_t *, int ); static void display_access_failed_message( drive_t *); static bool_t get_tpcaps( drive_t * ); static intgen_t prepare_drive( drive_t *drivep ); static bool_t Open( drive_t *drivep ); static void Close( drive_t *drivep ); static intgen_t Read( drive_t *drivep, char *bufp, size_t cnt, intgen_t *errnop ); static intgen_t Write( drive_t *drivep, char *bufp, size_t cnt, intgen_t *saved_errnop ); static intgen_t record_hdr_validate( drive_t *drivep, char *bufp, bool_t chkoffpr ); static void ring_thread( void *clientctxp, int ( * entryp )( void *ringctxp ), void *ringctxp ); static int ring_read( void *clientctxp, char *bufp ); static int ring_write( void *clientctxp, char *bufp ); static double percent64( off64_t num, off64_t denom ); static intgen_t getrec( drive_t *drivep ); static intgen_t write_record( drive_t *drivep, char *bufp, bool_t chksumpr, bool_t xlatepr ); static ring_msg_t * Ring_get( ring_t *ringp ); static void Ring_reset( ring_t *ringp, ring_msg_t *msgp ); static void Ring_put( ring_t *ringp, ring_msg_t *msgp ); static intgen_t validate_media_file_hdr( drive_t *drivep ); static void calc_max_lost( drive_t *drivep ); static void display_ring_metrics( drive_t *drivep, intgen_t mlog_flags ); #ifdef CLRMTAUD static u_int32_t rewind_and_verify( drive_t *drivep ); static u_int32_t erase_and_verify( drive_t *drivep ); static u_int32_t bsf_and_verify( drive_t *drivep ); static u_int32_t fsf_and_verify( drive_t *drivep ); #else /* CLRMTAUD */ static short rewind_and_verify( drive_t *drivep ); static short erase_and_verify( drive_t *drivep ); static short bsf_and_verify( drive_t *drivep ); static short fsf_and_verify( drive_t *drivep ); #endif /* CLRMTAUD */ static bool_t set_best_blk_and_rec_sz( drive_t *drivep ); static bool_t isefsdump( drive_t *drivep ); static bool_t isxfsdumperasetape( drive_t *drivep ); /* RMT trace stubs */ #ifdef RMT #ifdef RMTDBG static int dbgrmtopen( char *, int ); static int dbgrmtclose( int ); static int dbgrmtioctl( int, int, void * ); static int dbgrmtread( int, void *, uint); static int dbgrmtwrite( int, void *, uint); #endif /* RMTDBG */ #endif /* RMT */ #define ERASE_MAGIC "$^*@++! This tape was quick erased by SGI xfsdump $^*@++!" /* definition of locally defined global variables ****************************/ /* rmt drive strategy. referenced by drive.c */ drive_strategy_t drive_strategy_rmt = { DRIVE_STRATEGY_RMT, /* ds_id */ "minimum scsi tape (drive_minrmt)", /* ds_description */ ds_match, /* ds_match */ ds_instantiate, /* ds_instantiate */ 0x1000000ll, /* ds_recmarksep 16 MB */ 0x10000000ll, /* ds_recmfilesz 256 MB */ }; /* definition of locally defined static variables *****************************/ /* drive operators */ static drive_ops_t drive_ops = { do_init, /* do_init */ do_sync, /* do_sync */ do_begin_read, /* do_begin_read */ do_read, /* do_read */ do_return_read_buf, /* do_return_read_buf */ do_get_mark, /* do_get_mark */ do_seek_mark, /* do_seek_mark */ do_next_mark, /* do_next_mark */ do_end_read, /* do_end_read */ do_begin_write, /* do_begin_write */ do_set_mark, /* do_set_mark */ do_get_write_buf, /* do_get_write_buf */ do_write, /* do_write */ do_get_align_cnt, /* do_get_align_cnt */ do_end_write, /* do_end_write */ do_fsf, /* do_fsf */ do_bsf, /* do_bsf */ do_rewind, /* do_rewind */ do_erase, /* do_erase */ do_eject_media, /* do_eject_media */ do_get_device_class, /* do_get_device_class */ do_display_metrics, /* do_display_metrics */ do_quit, /* do_quit */ }; static u_int32_t cmdlineblksize = 0; /* definition of locally defined global functions ****************************/ /* definition of locally defined static functions ****************************/ /* strategy match - determines if this is the right strategy */ /* ARGSUSED */ static intgen_t ds_match( int argc, char *argv[], drive_t *drivep, bool_t singlethreaded ) { intgen_t fd; intgen_t c; bool_t minrmt = BOOL_FALSE; /* heuristics to determine if this is a drive. */ if ( ! strcmp( drivep->d_pathname, "stdio" )) { return -10; } /* Check if the min rmt flag and block size have * been specified. * If so , this is a non-SGI drive and this is the right * strategy. */ { optind = 1; opterr = 0; while ( ( c = getopt( argc, argv, GETOPT_CMDSTRING )) != EOF ) { switch (c) { case GETOPT_BLOCKSIZE: if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "-%c argument missing\n", optopt ); return -10; } cmdlineblksize = ( u_int32_t )atoi( optarg ); errno = 0; fd = open_masked_signals( drivep->d_pathname, O_RDONLY ); if ( fd < 0 ) return -10; close( fd ); break; case GETOPT_MINRMT: minrmt = BOOL_TRUE; break; } } if (minrmt == BOOL_TRUE) { if (cmdlineblksize != 0) return 20; else mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "Minimal rmt cannot be used without specifying blocksize. Use -%c\n", GETOPT_BLOCKSIZE ); } } /* catch all */ return -10; } /* strategy instantiate - initializes the pre-allocated drive descriptor */ /*ARGSUSED*/ static bool_t ds_instantiate( int argc, char *argv[], drive_t *drivep, bool_t singlethreaded ) { drive_context_t *contextp; intgen_t c; /* opportunity for sanity checking */ ASSERT( sizeof( global_hdr_t ) <= STAPE_HDR_SZ ); ASSERT( sizeof( rec_hdr_t ) == sizeofmember( drive_hdr_t, dh_specific )); ASSERT( ! ( STAPE_MAX_RECSZ % PGSZ )); /* hook up the drive ops */ drivep->d_opsp = &drive_ops; /* allocate context for the drive manager */ contextp = ( drive_context_t * )calloc( 1, sizeof( drive_context_t )); ASSERT( contextp ); memset( ( void * )contextp, 0, sizeof( *contextp )); /* transfer indication of singlethreadedness to context */ contextp->dc_singlethreadedpr = singlethreaded; /* scan the command line for the I/O buffer ring length * and record checksum request */ contextp->dc_ringlen = RINGLEN_DEFAULT; contextp->dc_ringpinnedpr = BOOL_FALSE; contextp->dc_recchksumpr = BOOL_FALSE; contextp->dc_unloadokpr = BOOL_FALSE; contextp->dc_singlemfilepr = BOOL_FALSE; contextp->dc_filesz = 0; contextp->dc_isQICpr = BOOL_FALSE; optind = 1; opterr = 0; while ( ( c = getopt( argc, argv, GETOPT_CMDSTRING )) != EOF ) { switch ( c ) { case GETOPT_RINGLEN: if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "-%c argument missing\n", optopt ); return BOOL_FALSE; } contextp->dc_ringlen = ( size_t )atoi( optarg ); if ( contextp->dc_ringlen < RINGLEN_MIN || contextp->dc_ringlen > RINGLEN_MAX ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, "-%c argument must be " "between %u and %u: ignoring %u\n", optopt, RINGLEN_MIN, RINGLEN_MAX, contextp->dc_ringlen ); return BOOL_FALSE; } break; case GETOPT_RINGPIN: contextp->dc_ringpinnedpr = BOOL_TRUE; break; case GETOPT_RECCHKSUM: contextp->dc_recchksumpr = BOOL_TRUE; break; case GETOPT_UNLOAD: contextp->dc_unloadokpr = BOOL_TRUE; break; case GETOPT_QIC: contextp->dc_isQICpr = BOOL_TRUE; break; #ifdef DUMP case GETOPT_OVERWRITE: contextp->dc_overwritepr = BOOL_TRUE; mlog( MLOG_DEBUG | MLOG_DRIVE, "Overwrite command line option \n" ); break; case GETOPT_SINGLEMFILE: if (contextp->dc_filesz > 0) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "-%c and -%c options cannot be used together\n", optopt, GETOPT_FILESZ ); return BOOL_FALSE; } contextp->dc_singlemfilepr = BOOL_TRUE; mlog( MLOG_DEBUG | MLOG_DRIVE, "Single media file command line option \n" ); break; case GETOPT_FILESZ: if (contextp->dc_singlemfilepr == BOOL_TRUE) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "-%c and -%c options cannot be used together\n", optopt, GETOPT_SINGLEMFILE ); return BOOL_FALSE; } if ( ! optarg || optarg [ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "-%c argument missing\n", optopt ); return BOOL_FALSE; } contextp->dc_filesz = (off64_t)atoi( optarg ) * 1024 * 1024; if (contextp->dc_filesz <= 0) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "-%c argument must be a " "positive number (MB): ignoring %u\n", optopt, contextp->dc_filesz ); return BOOL_FALSE; } break; #endif } } /* set drive file descriptor to null value */ contextp->dc_fd = -1; /* record location of context descriptor in drive descriptor */ drivep->d_contextp = (void *)contextp; /* indicate neither capacity nor rate estimates available */ drivep->d_cap_est = -1; drivep->d_rate_est = -1; /* if sproc not allowed, allocate a record buffer. otherwise * create a ring, from which buffers will be taken. */ if ( singlethreaded ) { contextp->dc_bufp = ( char * )memalign( PGSZ, STAPE_MAX_RECSZ ); ASSERT( contextp->dc_bufp ); } else { intgen_t rval; mlog( (MLOG_NITTY + 1) | MLOG_DRIVE, "ring op: create: ringlen == %u\n", contextp->dc_ringlen ); contextp->dc_ringp = ring_create( contextp->dc_ringlen, STAPE_MAX_RECSZ, contextp->dc_ringpinnedpr, ring_thread, ring_read, ring_write, ( void * )drivep, &rval ); if ( ! contextp->dc_ringp ) { if ( rval == ENOMEM ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, "unable to allocate memory " "for I/O buffer ring\n" ); } else if ( rval == E2BIG ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, "not enough physical memory " "to pin down I/O buffer ring\n" ); } else if ( rval == EPERM ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, "not allowed " "to pin down I/O buffer ring\n" ); } else { ASSERT( 0 ); } return BOOL_FALSE; } } /* several of contextp predicates cannot yet be determined. * mark them as unknown for now. however, if this is an RMT * access, we know immediately some capabilities are missing. */ /* specify that we are currently neither reading nor writing */ contextp->dc_mode = OM_NONE; /* set the capabilities flags advertised in the drive_t d_capabilities * field that we know a priori to be true. later additional flags * may be set */ drivep->d_capabilities = 0 | DRIVE_CAP_BSF | DRIVE_CAP_FSF | DRIVE_CAP_REWIND | DRIVE_CAP_FILES | DRIVE_CAP_NEXTMARK | DRIVE_CAP_READ | DRIVE_CAP_REMOVABLE | DRIVE_CAP_ERASE | DRIVE_CAP_EJECT ; return BOOL_TRUE; } /* drive op init - do more time-consuming init/checking here. read and * write headers are available now. * * NOTE: * When using a RMT device, the MTIOCGETBLKINFO, MTCAPABILITY and * MTSPECOP ioctl calls are not supported. This means that we have * to assume that the drive does not support the MTCAN_APPEND capability. */ /* ARGSUSED */ static bool_t do_init( drive_t *drivep ) { #ifdef DUMP drive_hdr_t *dwhdrp = drivep->d_writehdrp; media_hdr_t *mwhdrp = ( media_hdr_t * )dwhdrp->dh_upper; #endif /* DUMP */ mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: init\n" ); sscanf(drivep->d_pathname + (strlen(drivep->d_pathname) - 3), "%d", &lgs_fileno); mlog(MLOG_DEBUG | MLOG_DRIVE, "rmt drive: fileno initialised to %03d\n", lgs_fileno); #ifdef DUMP /* fill in media strategy id: artifact of first version of xfsdump */ mwhdrp->mh_strategyid = MEDIA_STRATEGY_RMVTAPE; #endif /* DUMP */ return BOOL_TRUE; } /* wait here for slave to complete initialization. * set drive capabilities flags. NOTE: currently don't make use of this * feature: drive initialization done whenever block/record sizes unknown. */ /* ARGSUSED */ static bool_t do_sync( drive_t *drivep ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: sync\n" ); return BOOL_TRUE; } /* begin_read * Set up the tape device and read the media file header. * if allowed, begin read-ahead. * * RETURNS: * 0 on success * DRIVE_ERROR_* on failure * */ static intgen_t do_begin_read( drive_t *drivep ) { drive_context_t *contextp; intgen_t rval; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: begin read\n" ); /* get drive context */ contextp = ( drive_context_t * )drivep->d_contextp; /* verify protocol being followed */ ASSERT( drivep->d_capabilities & DRIVE_CAP_READ ); ASSERT( contextp->dc_mode == OM_NONE ); ASSERT( ! contextp->dc_recp ); /* get a record buffer to use during initialization. */ if ( contextp->dc_singlethreadedpr ) { contextp->dc_recp = contextp->dc_bufp; } else { ASSERT( contextp->dc_ringp ); contextp->dc_msgp = Ring_get( contextp->dc_ringp ); ASSERT( contextp->dc_msgp->rm_stat == RING_STAT_INIT ); contextp->dc_recp = contextp->dc_msgp->rm_bufp; } /* if the tape is not open, open, determine the record size, and * read the first record. otherwise read a record using the record * size previously determined. */ contextp->dc_iocnt = 0; if ( contextp->dc_fd < 0 ) { ASSERT( contextp->dc_fd == -1 ); rval = prepare_drive( drivep ); if ( rval ) { if ( ! contextp->dc_singlethreadedpr ) { Ring_reset( contextp->dc_ringp, contextp->dc_msgp ); } contextp->dc_msgp = 0; contextp->dc_recp = 0; return rval; } } else { rval = read_label( drivep ) ; if ( rval ) { if ( ! contextp->dc_singlethreadedpr ) { Ring_reset( contextp->dc_ringp, contextp->dc_msgp ); } contextp->dc_msgp = 0; contextp->dc_recp = 0; return rval; } } ASSERT( contextp->dc_iocnt == 1 ); /* set by prepare_drive or read_label */ /* all is well. adjust context. don't kick off read-aheads just yet; * the client may not want this media file. */ if ( ! contextp->dc_singlethreadedpr ) { contextp->dc_msgp->rm_op = RING_OP_NOP; contextp->dc_msgp->rm_user = 0; /* do diff. use in do_seek */ Ring_put( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; } contextp->dc_recp = 0; contextp->dc_recendp = 0; contextp->dc_dataendp = 0; contextp->dc_ownedp = 0; contextp->dc_nextp = 0; contextp->dc_reccnt = 1; /* used to detect attempt to read after an error was reported */ contextp->dc_errorpr = BOOL_FALSE; /* successfully entered read mode. must do end_read to get out. */ contextp->dc_mode = OM_READ; return 0; } /* do_read * Supply the caller with all or a portion of the current buffer, * filled with data from a record. * * RETURNS: * a pointer to a buffer containing "*actual_bufszp" bytes of data * or 0 on failure with "*rvalp" containing the error (DRIVE_ERROR_...) * */ static char * do_read( drive_t *drivep, size_t wantedcnt, size_t *actualcntp, intgen_t *rvalp ) { drive_context_t *contextp; size_t availcnt; size_t actualcnt; intgen_t rval; #if 0 mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: read: wanted %u (0x%x)\n", wantedcnt, wantedcnt ); #endif /* get context ptrs */ contextp = ( drive_context_t * )drivep->d_contextp; /* assert protocol being followed */ ASSERT( contextp->dc_mode == OM_READ ); ASSERT( ! contextp->dc_errorpr ); ASSERT( ! contextp->dc_ownedp ); ASSERT( wantedcnt > 0 ); /* clear the return status field */ *rvalp = 0; /* read a new record if necessary */ rval = getrec( drivep ); if ( rval ) { mlog( MLOG_NITTY | MLOG_DRIVE, "rmt drive op read returning error rval=%d\n", rval ); *rvalp = rval; return 0; } /* figure how much data is available, and how much should be supplied */ availcnt = ( size_t )( contextp->dc_dataendp - contextp->dc_nextp ); actualcnt = min( wantedcnt, availcnt ); /* adjust the context */ contextp->dc_ownedp = contextp->dc_nextp; contextp->dc_nextp += actualcnt; ASSERT( contextp->dc_nextp <= contextp->dc_dataendp ); mlog( MLOG_NITTY | MLOG_DRIVE, "rmt drive op read actual == %d (0x%x)\n", actualcnt, actualcnt ); *actualcntp = actualcnt; return contextp->dc_ownedp; } /* do_return_read_buf - * Lets the caller give back the buffer portion obtained from the preceding * call to do_read(). * * RETURNS: * void */ /* ARGSUSED */ static void do_return_read_buf( drive_t *drivep, char *bufp, size_t retcnt ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; /* REFERENCED */ size_t ownedcnt; #if 0 mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: return read buf: sz %d (0x%x)\n", retcnt, retcnt ); #endif /* assert protocol being followed */ ASSERT( contextp->dc_mode == OM_READ ); ASSERT( ! contextp->dc_errorpr ); ASSERT( contextp->dc_ownedp ); ASSERT( bufp == contextp->dc_ownedp ); /* calculate how much the caller owns */ ASSERT( contextp->dc_nextp >= contextp->dc_ownedp ); ownedcnt = ( size_t )( contextp->dc_nextp - contextp->dc_ownedp ); ASSERT( ownedcnt == retcnt ); /* take possession of buffer portion */ contextp->dc_ownedp = 0; /* if caller is done with this record, take the buffer back * and (if ring in use) give buffer to ring for read-ahead. */ if ( contextp->dc_nextp >= contextp->dc_dataendp ) { ASSERT( contextp->dc_nextp == contextp->dc_dataendp ); if ( ! contextp->dc_singlethreadedpr ) { contextp->dc_msgp->rm_op = RING_OP_READ; Ring_put( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; } contextp->dc_recp = 0; contextp->dc_recendp = 0; contextp->dc_dataendp = 0; contextp->dc_nextp = 0; contextp->dc_reccnt++; } } /* do_get_mark * Get the current read tape location. * * RETURNS: * void */ static void do_get_mark( drive_t *drivep, drive_mark_t *markp ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; off64_t offset; mlog( MLOG_NITTY | MLOG_DRIVE, "rmt drive op: get mark\n" ); /* assert protocol being followed */ ASSERT( contextp->dc_mode == OM_READ ); ASSERT( ! contextp->dc_errorpr ); ASSERT( ! contextp->dc_ownedp ); /* the mark is simply the offset into the media file of the * next byte to be read. */ offset = contextp->dc_reccnt * ( off64_t )tape_recsz; if ( contextp->dc_recp ) { offset += ( off64_t )( contextp->dc_nextp - contextp->dc_recp ); } *markp = ( drive_mark_t )offset; return; } typedef enum { SEEKMODE_BUF, SEEKMODE_RAW } seekmode_t; /* do_seek_mark * Advance the tape to the given mark. does dummy reads to * advance tape, as well as FSR if supported. * * RETURNS: * 0 on success * DRIVE_ERROR_* on failure * */ static intgen_t do_seek_mark( drive_t *drivep, drive_mark_t *markp ) { drive_context_t *contextp; off64_t wantedoffset; off64_t currentoffset; /* get the drive context */ contextp = (drive_context_t *)drivep->d_contextp; /* assert protocol being followed */ ASSERT( contextp->dc_mode == OM_READ ); ASSERT( ! contextp->dc_errorpr ); ASSERT( ! contextp->dc_ownedp ); /* the desired mark is passed by reference, and is really just an * offset into the raw (incl rec hdrs) read stream */ wantedoffset = *( off64_t * )markp; mlog( MLOG_DEBUG | MLOG_DRIVE, "drive op: seek mark: %lld (0x%llx)\n", wantedoffset, wantedoffset ); /* determine the current offset. assert that the wanted offset is * not less than the current offset. */ currentoffset = contextp->dc_reccnt * ( off64_t )tape_recsz; if ( contextp->dc_recp ) { u_int32_t recoff; #ifdef DEBUG rec_hdr_t *rechdrp = ( rec_hdr_t * )contextp->dc_recp; #endif ASSERT( contextp->dc_nextp >= contextp->dc_recp ); recoff = ( u_int32_t )( contextp->dc_nextp - contextp->dc_recp ); ASSERT( recoff <= tape_recsz ); ASSERT( rechdrp->rec_used <= tape_recsz ); ASSERT( recoff >= STAPE_HDR_SZ ); ASSERT( rechdrp->rec_used >= STAPE_HDR_SZ ); ASSERT( recoff <= rechdrp->rec_used ); currentoffset += ( off64_t )recoff; } ASSERT( wantedoffset >= currentoffset ); /* if we are currently holding a record and the desired offset * is not within the current record, eat the current record. */ if ( contextp->dc_recp ) { off64_t nextrecoffset; rec_hdr_t *rechdrp = ( rec_hdr_t * )contextp->dc_recp; nextrecoffset = contextp->dc_reccnt * ( off64_t )tape_recsz + ( off64_t )rechdrp->rec_used; if ( wantedoffset >= nextrecoffset ) { u_int32_t recoff; size_t wantedcnt; char *dummybufp; size_t actualcnt; intgen_t rval; /* if this is the last record, the wanted offset * must be just after it. */ if ( rechdrp->rec_used < tape_recsz ) { ASSERT( wantedoffset == nextrecoffset ); } /* figure how much to ask for */ ASSERT( contextp->dc_nextp >= contextp->dc_recp ); recoff = ( u_int32_t )( contextp->dc_nextp - contextp->dc_recp ); wantedcnt = ( size_t )( rechdrp->rec_used - recoff ); /* eat that much tape */ rval = 0; dummybufp = do_read( drivep, wantedcnt, &actualcnt, &rval ); if ( rval ) { return rval; } ASSERT( actualcnt == wantedcnt ); do_return_read_buf( drivep, dummybufp, actualcnt ); currentoffset += ( off64_t )actualcnt; ASSERT( currentoffset == nextrecoffset ); ASSERT( wantedoffset >= currentoffset ); ASSERT( ! contextp->dc_recp ); ASSERT( currentoffset == contextp->dc_reccnt * ( off64_t )tape_recsz ); } } /* if FSR is supported, while the desired offset is more than a record * away, eat records. this is tricky. if read-ahead has already read * to the desired point, no need to FSR: fall through to next code block * where we get there by eating excess records. if read-ahead has not * made it there, suspend read-ahead, eat those readahead records, * FSR the remaining, and resume readahead. */ if ( contextp->dc_canfsrpr && wantedoffset - currentoffset >= ( off64_t )tape_recsz ) { off64_t wantedreccnt; seekmode_t seekmode; ASSERT( ! contextp->dc_recp ); wantedreccnt = wantedoffset / ( off64_t )tape_recsz; if ( contextp->dc_singlethreadedpr ) { seekmode = SEEKMODE_RAW; } else { seekmode = SEEKMODE_BUF; } ASSERT( wantedreccnt != 0 ); /* so NOP below can be * distinguished from use * in do_begin_read */ while ( contextp->dc_reccnt < wantedreccnt ) { off64_t recskipcnt64; off64_t recskipcnt64remaining; if ( seekmode == SEEKMODE_BUF ) { ring_stat_t rs; ASSERT( ! contextp->dc_msgp ); contextp->dc_msgp = Ring_get( contextp->dc_ringp ); rs = contextp->dc_msgp->rm_stat; if ( rs == RING_STAT_ERROR ) { contextp->dc_errorpr = BOOL_TRUE; return contextp->dc_msgp->rm_rval; } if ( rs != RING_STAT_OK && rs != RING_STAT_INIT && rs != RING_STAT_NOPACK ) { ASSERT( 0 ); contextp->dc_errorpr = BOOL_TRUE; return DRIVE_ERROR_CORE; } if ( rs == RING_STAT_OK ) { contextp->dc_reccnt++; } if ( rs == RING_STAT_NOPACK && contextp->dc_msgp->rm_user == wantedreccnt ) { seekmode = SEEKMODE_RAW; } contextp->dc_msgp->rm_op = RING_OP_NOP; contextp->dc_msgp->rm_user = wantedreccnt; Ring_put( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; continue; } ASSERT( contextp->dc_reccnt == contextp->dc_iocnt ); ASSERT( wantedreccnt > contextp->dc_reccnt ); recskipcnt64 = wantedreccnt - contextp->dc_reccnt; recskipcnt64remaining = recskipcnt64; while ( recskipcnt64remaining ) { intgen_t recskipcnt; intgen_t saved_errno; intgen_t rval; ASSERT( recskipcnt64remaining > 0 ); if ( recskipcnt64remaining > INTGENMAX ) { recskipcnt = INTGENMAX; } else { recskipcnt = ( intgen_t ) recskipcnt64remaining; } ASSERT( recskipcnt > 0 ); rval = mt_op( contextp->dc_fd, MTFSR, recskipcnt ); saved_errno = errno; if ( rval ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "could not forward space %d " "tape blocks: " "rval == %d, errno == %d (%s)\n", rval, saved_errno, strerror( saved_errno )); return DRIVE_ERROR_MEDIA; } recskipcnt64remaining -= ( off64_t )recskipcnt; } contextp->dc_reccnt += recskipcnt64; contextp->dc_iocnt += recskipcnt64; currentoffset = contextp->dc_reccnt * ( off64_t )tape_recsz; ASSERT( wantedoffset >= currentoffset ); ASSERT( wantedoffset - currentoffset < ( off64_t )tape_recsz ); } } /* remove excess records by eating them. won't be any if * FSR supported */ while ( wantedoffset - currentoffset >= ( off64_t )tape_recsz ) { size_t wantedcnt; char *dummybufp; size_t actualcnt; intgen_t rval; ASSERT( ! contextp->dc_recp ); /* figure how much to ask for. to eat an entire record, * ask for a record sans the header. do_read will eat * the header, we eat the rest. */ wantedcnt = ( size_t )( tape_recsz - STAPE_HDR_SZ ); /* eat that much tape */ rval = 0; dummybufp = do_read( drivep, wantedcnt, &actualcnt, &rval ); if ( rval ) { return rval; } ASSERT( actualcnt == wantedcnt ); do_return_read_buf( drivep, dummybufp, actualcnt ); ASSERT( ! contextp->dc_recp ); currentoffset += ( off64_t )tape_recsz; ASSERT( currentoffset == contextp->dc_reccnt * ( off64_t )tape_recsz ); } /* eat that portion of the next record leading up to the * desired offset. */ if ( wantedoffset != currentoffset ) { size_t wantedcnt; char *dummybufp; size_t actualcnt; ASSERT( wantedoffset > currentoffset ); ASSERT( wantedoffset - currentoffset < ( off64_t )tape_recsz ); wantedcnt = ( size_t )( wantedoffset - currentoffset ); if ( contextp->dc_recp ) { u_int32_t recoff; #ifdef DEBUG rec_hdr_t *rechdrp = ( rec_hdr_t * )contextp->dc_recp; #endif recoff = ( u_int32_t )( contextp->dc_nextp - contextp->dc_recp ); ASSERT( recoff <= tape_recsz ); ASSERT( rechdrp->rec_used <= tape_recsz ); ASSERT( recoff >= STAPE_HDR_SZ ); ASSERT( rechdrp->rec_used >= STAPE_HDR_SZ ); ASSERT( recoff <= rechdrp->rec_used ); ASSERT( recoff + wantedcnt <= rechdrp->rec_used ); } else { ASSERT( wantedcnt >= STAPE_HDR_SZ ); wantedcnt -= STAPE_HDR_SZ; } /* eat that much tape */ if ( wantedcnt > 0 ) { intgen_t rval; rval = 0; dummybufp = do_read( drivep, wantedcnt, &actualcnt, &rval ); if ( rval ) { return rval; } ASSERT( actualcnt == wantedcnt ); do_return_read_buf( drivep, dummybufp, actualcnt ); } } /* as a sanity check, refigure the current offset and make sure * it is equal to the wanted offset */ currentoffset = contextp->dc_reccnt * ( off64_t )tape_recsz; if ( contextp->dc_recp ) { u_int32_t recoff; #ifdef DEBUG rec_hdr_t *rechdrp = ( rec_hdr_t * )contextp->dc_recp; #endif ASSERT( contextp->dc_nextp >= contextp->dc_recp ); recoff = ( u_int32_t )( contextp->dc_nextp - contextp->dc_recp ); ASSERT( recoff <= tape_recsz ); ASSERT( rechdrp->rec_used <= tape_recsz ); ASSERT( recoff >= STAPE_HDR_SZ ); ASSERT( rechdrp->rec_used >= STAPE_HDR_SZ ); ASSERT( recoff <= rechdrp->rec_used ); currentoffset += ( off64_t )recoff; } ASSERT( wantedoffset == currentoffset ); return 0; } /* do_next_mark * Advance the tape position to the next valid mark. if in * error mode, first attempt to move past error by re-reading. if * that fails, try to FSR. also deals with QIC possibility of * reading a block not at a record boundary. * * RETURNS: * 0 on success * DRIVE_ERROR_* on failure */ static intgen_t do_next_mark( drive_t *drivep ) { drive_context_t *contextp = (drive_context_t *)drivep->d_contextp; rec_hdr_t *rechdrp; char *p; ix_t trycnt; const ix_t maxtrycnt = 5; intgen_t nread; off64_t markoff; intgen_t saved_errno; size_t tailsz; intgen_t rval; /* assert protocol being followed. */ ASSERT( contextp->dc_mode == OM_READ ); ASSERT( ! contextp->dc_errorpr ); ASSERT( ! contextp->dc_ownedp ); mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: next mark\n" ); trycnt = 0; if ( contextp->dc_errorpr ) { goto resetring; } else { goto noerrorsearch; } noerrorsearch: for ( ; ; ) { rval = getrec( drivep ); if ( rval == DRIVE_ERROR_CORRUPTION ) { goto resetring; } else if ( rval ) { return rval; } rechdrp = ( rec_hdr_t * )contextp->dc_recp; ASSERT( rechdrp->first_mark_offset != 0 ); if ( rechdrp->first_mark_offset != -1 ) { off64_t markoff = rechdrp->first_mark_offset - rechdrp->file_offset; off64_t curoff = ( off64_t )( contextp->dc_nextp - contextp->dc_recp ); if (markoff > (off64_t) tape_recsz) { char *p = (char *) &rechdrp->first_mark_offset; char c; c = p[0]; p[0] = p[7]; p[7] = c; c = p[1]; p[1] = p[6]; p[6] = c; c = p[2]; p[2] = p[5]; p[5] = c; c = p[3]; p[3] = p[4]; p[4] = c; markoff = rechdrp->first_mark_offset - rechdrp->file_offset; } ASSERT( markoff > 0 ); ASSERT( curoff > 0 ); if ( markoff >= curoff ) { break; } } if ( ! contextp->dc_singlethreadedpr ) { Ring_put( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; } contextp->dc_recp = 0; contextp->dc_reccnt++; } ASSERT( rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )tape_recsz ); contextp->dc_nextp = contextp->dc_recp + ( size_t )( rechdrp->first_mark_offset - rechdrp->file_offset ); ASSERT( contextp->dc_nextp <= contextp->dc_dataendp ); ASSERT( contextp->dc_nextp >= contextp->dc_recp + STAPE_HDR_SZ ); if ( contextp->dc_nextp == contextp->dc_dataendp ) { if ( ! contextp->dc_singlethreadedpr ) { Ring_put( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; } contextp->dc_recp = 0; contextp->dc_reccnt++; } return 0; resetring: if ( ! contextp->dc_singlethreadedpr ) { Ring_reset( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; } contextp->dc_recp = 0; /* get a record buffer and cast a record header pointer */ if ( contextp->dc_singlethreadedpr ) { contextp->dc_recp = contextp->dc_bufp; } else { contextp->dc_msgp = Ring_get( contextp->dc_ringp ); ASSERT( contextp->dc_msgp->rm_stat == RING_STAT_INIT ); contextp->dc_recp = contextp->dc_msgp->rm_bufp; } rechdrp = ( rec_hdr_t * )contextp->dc_recp; goto readrecord; readrecord: trycnt++; if ( trycnt > maxtrycnt ) { mlog( MLOG_NORMAL | MLOG_DRIVE, "unable to locate next mark in media file\n" ); return DRIVE_ERROR_MEDIA; } nread = Read( drivep, contextp->dc_recp, tape_recsz, &saved_errno ); goto validateread; validateread: if ( nread == ( intgen_t )tape_recsz ) { goto validatehdr; } if ( nread >= 0 ) { ASSERT( ( size_t )nread <= tape_recsz ); mlog( MLOG_DEBUG | MLOG_DRIVE, "short read (nread == %d, record size == %d)\n", nread, tape_recsz ); goto getbeyonderror; } /* some other error */ mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, "unexpected error attempting to read record: " "read returns %d, errno %s (%s)\n", nread, errno, strerror( errno )); goto getbeyonderror; validatehdr: rval = record_hdr_validate( drivep, contextp->dc_recp, BOOL_FALSE ); if ( rval && ( contextp->dc_isQICpr == BOOL_TRUE || contextp->dc_isQICpr == BOOL_UNKNOWN )) { goto huntQIC; } if ( rval ) { goto readrecord; } contextp->dc_reccnt = rechdrp->file_offset / ( off64_t )tape_recsz; contextp->dc_iocnt = contextp->dc_reccnt + 1; if ( rechdrp->first_mark_offset < 0 ) { mlog( MLOG_NORMAL | MLOG_DRIVE, "valid record %lld but no mark\n", contextp->dc_iocnt - 1 ); goto readrecord; } ASSERT( ! ( rechdrp->file_offset % ( off64_t )tape_recsz )); markoff = rechdrp->first_mark_offset - rechdrp->file_offset; ASSERT( markoff >= ( off64_t )STAPE_HDR_SZ ); ASSERT( markoff < ( off64_t )tape_recsz ); ASSERT( rechdrp->rec_used > STAPE_HDR_SZ ); ASSERT( rechdrp->rec_used < tape_recsz ); goto alliswell; alliswell: contextp->dc_nextp = contextp->dc_recp + ( size_t )markoff; ASSERT( ! ( rechdrp->file_offset % ( off64_t )tape_recsz )); contextp->dc_reccnt = rechdrp->file_offset / ( off64_t )tape_recsz; contextp->dc_iocnt = contextp->dc_reccnt + 1; contextp->dc_recendp = contextp->dc_recp + tape_recsz; contextp->dc_dataendp = contextp->dc_recp + rechdrp->rec_used; ASSERT( contextp->dc_dataendp <= contextp->dc_recendp ); ASSERT( contextp->dc_nextp < contextp->dc_dataendp ); contextp->dc_errorpr = BOOL_FALSE; mlog( MLOG_NORMAL | MLOG_DRIVE, "resynchronized at record %lld " "offset %u\n", contextp->dc_iocnt - 1, contextp->dc_nextp - contextp->dc_recp ); return 0; getbeyonderror: rval = mt_op( contextp->dc_fd, MTFSR, 1 ); saved_errno = errno; if ( rval ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "could not forward space one tape block beyond " "read error: rval == %d, errno == %d (%s)\n", rval, saved_errno, strerror( saved_errno )); return DRIVE_ERROR_MEDIA; } goto readrecord; huntQIC: /* we have a full tape_recsz record. look for the magic number at the * beginning of each 512 byte block. If we find one, shift that and * the following blocks to the head of the record buffer, and try * to read the remaining blocks in the record. */ for ( p = contextp->dc_recp + QIC_BLKSZ ; p < contextp->dc_recendp ; p += QIC_BLKSZ ) { if ( *( u_int64_t * )p == STAPE_MAGIC ) { goto adjustQIC; } } goto readrecord; adjustQIC: tailsz = ( size_t )( contextp->dc_recendp - p ); memcpy( ( void * )contextp->dc_recp, ( void * )p, tailsz ); nread = Read( drivep, contextp->dc_recp + tailsz, tape_recsz - tailsz, &saved_errno ); goto validateread; } /* do_end_read * Discard any buffered reads. * Tell the reader/writer process to wait. * * RETURNS: * void */ static void do_end_read( drive_t *drivep ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: end read\n" ); /* assert protocol being followed */ ASSERT( contextp->dc_mode == OM_READ ); ASSERT( ! contextp->dc_ownedp ); /* In the scsi version, read_label() does a status command to the * drive to then decide if doing a 'fsf' is appropriate. For minrmt, * we don't have the status command so we need to space forward at * the moment we know we need to go forward... which is here. */ ( void )fsf_and_verify( drivep ); if ( ! contextp->dc_singlethreadedpr ) { Ring_reset( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; } contextp->dc_recp = 0; contextp->dc_mode = OM_NONE; } /* do_begin_write * prepare drive for writing. set up drive context. write a header record. * * RETURNS: * 0 on success * DRIVE_ERROR_... on failure */ static intgen_t do_begin_write( drive_t *drivep ) { drive_context_t *contextp; drive_hdr_t *dwhdrp; global_hdr_t *gwhdrp; rec_hdr_t *tpwhdrp; rec_hdr_t *rechdrp; intgen_t rval; media_hdr_t *mwhdrp; content_hdr_t *ch; content_inode_hdr_t *cih; global_hdr_t *tmpgh; drive_hdr_t *tmpdh; media_hdr_t *tmpmh; rec_hdr_t *tmprh; content_hdr_t *tmpch; content_inode_hdr_t *tmpcih; /* get drive context */ contextp = ( drive_context_t * )drivep->d_contextp; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: begin write\n" ); /* verify protocol being followed */ ASSERT( contextp->dc_mode == OM_NONE ); ASSERT( ! drivep->d_markrecheadp ); ASSERT( ! contextp->dc_recp ); /* get pointers into global write header */ gwhdrp = drivep->d_gwritehdrp; dwhdrp = drivep->d_writehdrp; tpwhdrp = ( rec_hdr_t * )dwhdrp->dh_specific; /* must already be open. The only way to open is to do a begin_read. * so all interaction with tape requires reading first. */ ASSERT( contextp->dc_fd != -1 ); /* fill in write header's drive specific info */ tpwhdrp->magic = STAPE_MAGIC; tpwhdrp->version = STAPE_VERSION; tpwhdrp->blksize = ( int32_t )tape_blksz; tpwhdrp->recsize = ( int32_t )tape_recsz; tpwhdrp->rec_used = 0; tpwhdrp->file_offset = 0; tpwhdrp->first_mark_offset= 0; tpwhdrp->capability = drivep->d_capabilities; /* get a record buffer. will be used for the media file header, * and is needed to "prime the pump" for first call to do_write. */ ASSERT( ! contextp->dc_recp ); if ( contextp->dc_singlethreadedpr ) { ASSERT( contextp->dc_bufp ); contextp->dc_recp = contextp->dc_bufp; } else { ASSERT( contextp->dc_ringp ); ASSERT( ! contextp->dc_msgp ); contextp->dc_msgp = Ring_get( contextp->dc_ringp ); ASSERT( contextp->dc_msgp->rm_stat == RING_STAT_INIT ); contextp->dc_recp = contextp->dc_msgp->rm_bufp; } /* write the record. be sure to prevent a record checksum from * being produced! */ contextp->dc_iocnt = 0; memset( ( void * )contextp->dc_recp, 0, tape_recsz ); tmpgh = (global_hdr_t *)contextp->dc_recp; tmpdh = (drive_hdr_t *)tmpgh->gh_upper; tmpmh = (media_hdr_t *)tmpdh->dh_upper; tmprh = (rec_hdr_t *)tmpdh->dh_specific; tmpch = (content_hdr_t *)tmpmh->mh_upper; tmpcih = (content_inode_hdr_t *)tmpch->ch_specific; mwhdrp = (media_hdr_t *)dwhdrp->dh_upper; ch = (content_hdr_t *)mwhdrp->mh_upper; cih = (content_inode_hdr_t *)ch->ch_specific; xlate_global_hdr(gwhdrp, tmpgh, 1); xlate_drive_hdr(dwhdrp, tmpdh, 1); xlate_media_hdr(mwhdrp, tmpmh, 1); xlate_content_hdr(ch, tmpch, 1); xlate_content_inode_hdr(cih, tmpcih, 1); xlate_rec_hdr(tpwhdrp, tmprh, 1); /* checksum the global header */ global_hdr_checksum_set( tmpgh ); rval = write_record( drivep, contextp->dc_recp, BOOL_TRUE, BOOL_FALSE ); if ( rval ) { if ( ! contextp->dc_singlethreadedpr ) { Ring_reset( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; } contextp->dc_recp = 0; return rval; } /* prepare the drive context. must have a record buffer ready to * go, header initialized. */ ASSERT( ! contextp->dc_ownedp ); contextp->dc_reccnt = 1; /* count the header record */ contextp->dc_recendp = contextp->dc_recp + tape_recsz; contextp->dc_nextp = contextp->dc_recp + STAPE_HDR_SZ; /* intialize header in new record */ rechdrp = (rec_hdr_t*)contextp->dc_recp; rechdrp->magic = STAPE_MAGIC; rechdrp->version = STAPE_VERSION; rechdrp->file_offset = contextp->dc_reccnt * ( off64_t )tape_recsz; rechdrp->blksize = ( int32_t )tape_blksz; rechdrp->recsize = ( int32_t )tape_recsz; rechdrp->capability = drivep->d_capabilities; rechdrp->first_mark_offset = -1LL; uuid_copy( rechdrp->dump_uuid, gwhdrp->gh_dumpid ); /* set mode now so operators will work */ contextp->dc_mode = OM_WRITE; contextp->dc_errorpr = BOOL_FALSE; return 0; } /* do_set_mark - queue a mark request. if first mark set in record, record * in record. */ static void do_set_mark( drive_t *drivep, drive_mcbfp_t cbfuncp, void *cbcontextp, drive_markrec_t *markrecp ) { drive_context_t *contextp; off64_t nextoff; rec_hdr_t *rechdrp; /* get drive context */ contextp = ( drive_context_t * )drivep->d_contextp; /* verify protocol being followed */ ASSERT( contextp->dc_mode == OM_WRITE ); ASSERT( ! contextp->dc_errorpr ); ASSERT( ! contextp->dc_ownedp ); ASSERT( contextp->dc_recp ); ASSERT( contextp->dc_nextp ); /* calculate and fill in the mark record offset */ ASSERT( contextp->dc_recp ); nextoff = contextp->dc_reccnt * ( off64_t )tape_recsz + ( off64_t )( contextp->dc_nextp - contextp->dc_recp ); markrecp->dm_log = ( drive_mark_t )nextoff; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: set mark: %lld (0x%llx)\n", nextoff, nextoff ); /* note the location of the first mark in this tape record. */ rechdrp = ( rec_hdr_t * )contextp->dc_recp; if ( rechdrp->first_mark_offset == -1LL ) { ASSERT( nextoff != -1LL ); rechdrp->first_mark_offset = nextoff; } /* put the mark on the tail of the queue. */ markrecp->dm_cbfuncp = cbfuncp; markrecp->dm_cbcontextp = cbcontextp; markrecp->dm_nextp = 0; if ( drivep->d_markrecheadp == 0 ) { drivep->d_markrecheadp = markrecp; drivep->d_markrectailp = markrecp; } else { ASSERT( drivep->d_markrectailp ); drivep->d_markrectailp->dm_nextp = markrecp; drivep->d_markrectailp = markrecp; } } /* do_get_write_buf - supply the caller with some or all of the current record * buffer. the supplied buffer must be fully returned (via a single call to * do_write) prior to the next call to do_get_write_buf. * * RETURNS: * the address of a buffer * "actual_bufszp" points to the size of the buffer */ static char * do_get_write_buf( drive_t *drivep, size_t wantedcnt, size_t *actualcntp ) { drive_context_t *contextp; size_t remainingcnt; size_t actualcnt; /* get drive context */ contextp = ( drive_context_t * )drivep->d_contextp; /* verify protocol being followed */ ASSERT( contextp->dc_mode == OM_WRITE ); ASSERT( ! contextp->dc_errorpr ); ASSERT( ! contextp->dc_ownedp ); ASSERT( contextp->dc_recp ); ASSERT( contextp->dc_nextp ); ASSERT( contextp->dc_nextp < contextp->dc_recendp ); /* figure how much is available; supply the min of what is * available and what is wanted. */ remainingcnt = ( size_t )( contextp->dc_recendp - contextp->dc_nextp ); actualcnt = min( remainingcnt, wantedcnt ); *actualcntp = actualcnt; contextp->dc_ownedp = contextp->dc_nextp; contextp->dc_nextp += actualcnt; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: get write buf: wanted %u (0x%x) actual %u (0x%x)\n", wantedcnt, wantedcnt, actualcnt, actualcnt ); return contextp->dc_ownedp; } /* do_write - accept ownership of the portion of the current record buffer * being returned by the caller. if returned portion includes end of record * buffer, write the buffer and get and prepare a new one in anticipation of * the next call to do_get_write_buf. also, process any queued marks which * are guaranteed to be committed to media. NOTE: the caller must return * everything obtained with the preceeding call to do_get_write_buf. * * RETURNS: * 0 on success * non 0 on error */ /* ARGSUSED */ static intgen_t do_write( drive_t *drivep, char *bufp, size_t retcnt ) { drive_context_t *contextp; rec_hdr_t *rechdrp; global_hdr_t *gwhdrp; size_t heldcnt; off64_t last_rec_wrtn_wo_err; /* zero-based index */ intgen_t rval; /* get drive context and pointer to global write hdr */ contextp = ( drive_context_t * )drivep->d_contextp; gwhdrp = drivep->d_gwritehdrp; /* calculate how many bytes we believe caller is holding */ heldcnt = ( size_t )( contextp->dc_nextp - contextp->dc_ownedp ); mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: write: retcnt %u (0x%x) heldcnt %u (0x%x)\n", retcnt, retcnt, heldcnt, heldcnt ); /* verify protocol being followed */ ASSERT( contextp->dc_mode == OM_WRITE ); ASSERT( ! contextp->dc_errorpr ); ASSERT( contextp->dc_ownedp ); ASSERT( contextp->dc_recp ); ASSERT( contextp->dc_nextp ); ASSERT( contextp->dc_nextp <= contextp->dc_recendp ); /* verify the caller is returning exactly what is held */ ASSERT( bufp == contextp->dc_ownedp ); ASSERT( retcnt == heldcnt ); /* take it back */ contextp->dc_ownedp = 0; /* if some portion of the record buffer has not yet been * held by the client, just return. */ if ( contextp->dc_nextp < contextp->dc_recendp ) { return 0; } /* record in record header that entire record is used */ rechdrp = ( rec_hdr_t * )contextp->dc_recp; rechdrp->rec_used = tape_recsz; /* write out the record buffer and get a new one. */ if ( contextp->dc_singlethreadedpr ) { rval = write_record( drivep, contextp->dc_recp, BOOL_TRUE, BOOL_TRUE ); last_rec_wrtn_wo_err = contextp->dc_reccnt; /* conv cnt to ix */ } else { contextp->dc_msgp->rm_op = RING_OP_WRITE; contextp->dc_msgp->rm_user = contextp->dc_reccnt; Ring_put( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; contextp->dc_msgp = Ring_get( contextp->dc_ringp ); contextp->dc_recp = contextp->dc_msgp->rm_bufp; last_rec_wrtn_wo_err = contextp->dc_msgp->rm_user; switch( contextp->dc_msgp->rm_stat ) { case RING_STAT_OK: case RING_STAT_INIT: rval = 0; break; case RING_STAT_ERROR: rval = contextp->dc_msgp->rm_rval; break; default: ASSERT( 0 ); return DRIVE_ERROR_CORE; } } /* check for errors. if none, commit all marks before a safety margin * before the no error offset. */ if ( rval ) { contextp->dc_errorpr = BOOL_TRUE; } else { off64_t recs_wrtn_wo_err; off64_t recs_committed; off64_t bytes_committed; recs_wrtn_wo_err = last_rec_wrtn_wo_err + 1; recs_committed = recs_wrtn_wo_err - contextp->dc_lostrecmax; bytes_committed = recs_committed * ( off64_t )tape_recsz; drive_mark_commit( drivep, bytes_committed ); } /* adjust context */ contextp->dc_reccnt++; contextp->dc_recendp = contextp->dc_recp + tape_recsz; contextp->dc_nextp = contextp->dc_recp + STAPE_HDR_SZ; /* intialize header in new record */ rechdrp = ( rec_hdr_t * )contextp->dc_recp; rechdrp->magic = STAPE_MAGIC; rechdrp->version = STAPE_VERSION; rechdrp->file_offset = contextp->dc_reccnt * ( off64_t )tape_recsz; rechdrp->blksize = ( int32_t )tape_blksz; rechdrp->recsize = ( int32_t )tape_recsz; rechdrp->capability = drivep->d_capabilities; rechdrp->first_mark_offset = -1LL; uuid_copy( rechdrp->dump_uuid, gwhdrp->gh_dumpid ); return rval; } /* do_get_align_cnt - * Returns the number of bytes which must be written to * cause the next call to get_write_buf() to be page-aligned. * * RETURNS: * the number of bytes to next alignment */ static size_t do_get_align_cnt( drive_t * drivep ) { char *next_alignment_point; __psint_t next_alignment_off; drive_context_t *contextp; contextp = ( drive_context_t * )drivep->d_contextp; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: get align cnt\n" ); /* verify protocol being followed */ ASSERT( contextp->dc_mode == OM_WRITE ); ASSERT( ! contextp->dc_errorpr ); ASSERT( ! contextp->dc_ownedp ); ASSERT( contextp->dc_recp ); ASSERT( contextp->dc_nextp ); ASSERT( contextp->dc_nextp < contextp->dc_recendp ); /* calculate the next alignment point at or beyond the current nextp. * the following algorithm works because all buffers are page-aligned * and a multiple of PGSZ. */ next_alignment_off = ( __psint_t )contextp->dc_nextp; next_alignment_off += PGMASK; next_alignment_off &= ~PGMASK; next_alignment_point = ( char * )next_alignment_off; ASSERT( next_alignment_point <= contextp->dc_recendp ); /* return the number of bytes to the next alignment offset */ ASSERT( next_alignment_point >= contextp->dc_nextp ); return ( size_t )( next_alignment_point - contextp->dc_nextp ); } /* do_end_write - pad and write pending record if any client data in it. * flush all pending writes. write a file mark. figure how many records are * guaranteed to be on media, and commit/discard marks accordingly. * RETURNS: * 0 on success * DRIVE_ERROR_* on failure */ static intgen_t do_end_write( drive_t *drivep, off64_t *ncommittedp ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; off64_t first_rec_w_err; /* zero-based index */ off64_t recs_wtn_wo_err; off64_t recs_guaranteed; off64_t bytes_committed; intgen_t rval; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: end write\n" ); /* verify protocol being followed */ ASSERT( contextp->dc_mode == OM_WRITE ); ASSERT( ! contextp->dc_ownedp ); ASSERT( contextp->dc_recp ); ASSERT( contextp->dc_nextp ); ASSERT( contextp->dc_nextp >= contextp->dc_recp + STAPE_HDR_SZ ); ASSERT( contextp->dc_nextp < contextp->dc_recendp ); /* pre-initialize return of count of bytes committed to media */ *ncommittedp = 0; /* if in error mode, a write error occured earlier. don't bother * to do anymore writes, just cleanup and return 0. don't need to * do commits, already done when error occured. */ if ( contextp->dc_errorpr ) { if ( ! contextp->dc_singlethreadedpr ) { Ring_reset( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; } contextp->dc_mode = OM_NONE; drive_mark_discard( drivep ); *ncommittedp = ( contextp->dc_iocnt - contextp->dc_lostrecmax ) * ( off64_t )tape_recsz; contextp->dc_recp = 0; return 0; } /* if any user data in current record buffer, send it out. */ if ( contextp->dc_nextp > contextp->dc_recp + STAPE_HDR_SZ ) { rec_hdr_t *rechdrp; size_t bufusedcnt; rechdrp = ( rec_hdr_t * )contextp->dc_recp; bufusedcnt = ( size_t )( contextp->dc_nextp - contextp->dc_recp ); rechdrp->rec_used = bufusedcnt; mlog( MLOG_DEBUG | MLOG_DRIVE, "writing padded last record\n" ); if ( contextp->dc_singlethreadedpr ) { rval = write_record( drivep, contextp->dc_recp, BOOL_TRUE, BOOL_TRUE ); } else { ASSERT( contextp->dc_msgp ); contextp->dc_msgp->rm_op = RING_OP_WRITE; contextp->dc_msgp->rm_user = contextp->dc_reccnt; Ring_put( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; contextp->dc_msgp = Ring_get( contextp->dc_ringp ); switch( contextp->dc_msgp->rm_stat ) { case RING_STAT_OK: case RING_STAT_INIT: rval = 0; break; case RING_STAT_ERROR: rval = contextp->dc_msgp->rm_rval; break; default: ASSERT( 0 ); contextp->dc_recp = 0; return DRIVE_ERROR_CORE; } } contextp->dc_reccnt++; } else { rval = 0; } /* now flush the ring until error or tracer bullet seen. * note the record index in the first msg received with * an error indication. this will be used to calculate * the number of records guaranteed to have made it onto * media, and that will be used to select which marks * to commit and which to discard. */ if ( rval ) { first_rec_w_err = contextp->dc_iocnt; /* because dc_iocnt bumped by write_record * only if no error */ } else { first_rec_w_err = -1L; } if ( ! contextp->dc_singlethreadedpr ) { while ( ! rval ) { ASSERT( contextp->dc_msgp ); contextp->dc_msgp->rm_op = RING_OP_TRACE; Ring_put( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; contextp->dc_msgp = Ring_get( contextp->dc_ringp ); if ( contextp->dc_msgp->rm_op == RING_OP_TRACE ) { break; } switch( contextp->dc_msgp->rm_stat ) { case RING_STAT_OK: case RING_STAT_INIT: ASSERT( rval == 0 ); break; case RING_STAT_ERROR: rval = contextp->dc_msgp->rm_rval; first_rec_w_err = contextp->dc_msgp->rm_user; break; default: ASSERT( 0 ); contextp->dc_recp = 0; return DRIVE_ERROR_CORE; } } } /* the ring is now flushed. reset */ if ( ! contextp->dc_singlethreadedpr ) { Ring_reset( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; } contextp->dc_recp = 0; /* if no error so far, write a file mark. this will have the * side-effect of flushing the driver/drive of pending writes, * exposing any write errors. */ if ( ! rval ) { intgen_t weofrval; weofrval = mt_op( contextp->dc_fd, MTWEOF, 1 ); if ( weofrval ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "MTWEOF returned %d: errno == %d (%s)\n", weofrval, errno, strerror( errno )); rval = DRIVE_ERROR_EOM; } } /* if an error occured, first_rec_w_err now contains * the count of records written without error, all of which * were full records. subtract from this dc_lostrecmax, * and we have the number of records guaranteed to have made * it to media. * * if no errors have occured, all I/O has been committed. * we can use dc_iocnt, which is the count of records actually * written without error. * * commit marks contained in committed records, discard the rest, * and return rval. return by reference the number of bytes committed * to tape. */ if ( rval ) { ASSERT( first_rec_w_err >= 0 ); recs_wtn_wo_err = first_rec_w_err; recs_guaranteed = recs_wtn_wo_err - contextp->dc_lostrecmax; } else { ASSERT( first_rec_w_err == -1 ); recs_wtn_wo_err = contextp->dc_iocnt; recs_guaranteed = recs_wtn_wo_err; } bytes_committed = recs_guaranteed * ( off64_t )tape_recsz; drive_mark_commit( drivep, bytes_committed ); drive_mark_discard( drivep ); contextp->dc_mode = OM_NONE; *ncommittedp = bytes_committed; return rval; } /* do_fsf * Advance the tape by count files. * * RETURNS: * number of media files skipped * *statp set to zero or DRIVE_ERROR_... */ static intgen_t do_fsf( drive_t *drivep, intgen_t count, intgen_t *statp ) { int i, done, op_failed, opcount; drive_context_t *contextp; /* get drive context */ contextp = ( drive_context_t * )drivep->d_contextp; /* verify protocol being followed */ ASSERT( contextp->dc_mode == OM_NONE ); mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: fsf: count %d\n", count ); ASSERT( count ); ASSERT( contextp->dc_mode == OM_NONE ); for ( i = 0 ; i < count; i++ ) { done = 0; opcount = 2; /* the tape may encounter errors will trying to * reach the next file. */ while ( !done ) { /* advance the tape to the next file mark * NOTE: * ignore return code */ mlog( MLOG_VERBOSE | MLOG_DRIVE, "advancing tape to next media file\n"); op_failed = 0; ASSERT( contextp->dc_fd >= 0 ); if ( mt_op( contextp->dc_fd, MTFSF, 1 ) ) { op_failed = 1; } /* Check for a file mark to * determine if the fsf command worked. */ if (!op_failed) { done = 1; } /* If the FSF command has been issued multiple * times, and a file mark has not been reached, * return an error. */ if ( --opcount < 0 ) { mlog( MLOG_VERBOSE | MLOG_DRIVE, "FSF tape command failed\n"); *statp = DRIVE_ERROR_DEVICE; return i; } } } return count; } /* do_bsf * Backup the tape by count files. zero means just back up to the beginning * of the last media file read or written. * * RETURNS: * number of media files skipped * *statp set to zero or DRIVE_ERROR_... */ static intgen_t do_bsf( drive_t *drivep, intgen_t count, intgen_t *statp ) { #ifdef DEBUG drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; #endif intgen_t skipped; intgen_t rval; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: bsf: count %d\n", count ); ASSERT( contextp->dc_mode == OM_NONE ); *statp = 0; /* back space - places us to left of previous file mark * if we hit BOT, return */ ASSERT( drivep->d_capabilities & DRIVE_CAP_BSF ); rval = bsf_and_verify( drivep ); if (rval) { if (errno == ENOSPC/*IRIX*/ || errno == EIO/*Linux*/) { if ( count ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: bsf reached BOT " "unexpectedly (%d files to go)\n", count); /* set statp - BOT is unexpected */ } else { mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: bsf reached BOT\n"); /* don't set statp, BOT is fine */ return 0; } } *statp = DRIVE_ERROR_DEVICE; return 0; } /* now loop, skipping media files */ for ( skipped = 0 ; skipped < count ; skipped++ ) { /* move to the left of the next file mark on the left. * check for BOT. */ rval = bsf_and_verify( drivep ); if (rval) { if (errno == ENOSPC/*IRIX*/ || errno == EIO/*Linux*/) { if ( count - skipped - 1 ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: bsf reached BOT " "unexpectedly (%d files to go)\n", count - skipped - 1); /* set statp - BOT is unexpected */ *statp = DRIVE_ERROR_DEVICE; return skipped + 1; } else { mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: bsf reached BOT\n"); /* don't set statp - BOT is fine */ return skipped + 1; } *statp = DRIVE_ERROR_DEVICE; return skipped; } } } /* we're not at BOT, so we need to move to the right side of * the file mark */ ( void )fsf_and_verify( drivep ); /* indicate the number of media files skipped */ return skipped; } /* do_rewind * Position the tape at the beginning of the recorded media. * * RETURNS: * 0 on sucess * DRIVE_ERROR_* on failure */ static intgen_t do_rewind( drive_t *drivep ) { #ifdef DEBUG drive_context_t *contextp = (drive_context_t *)drivep->d_contextp; #endif mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: rewind\n" ); ASSERT( contextp->dc_mode == OM_NONE ); ASSERT( contextp->dc_fd >= 0 ); /* use validating tape rewind util func */ ( void )rewind_and_verify( drivep ); return 0; } /* do_erase * erase media from beginning * * RETURNS: * 0 on sucess * DRIVE_ERROR_* on failure */ static intgen_t do_erase( drive_t *drivep ) { #ifdef DEBUG drive_context_t *contextp = (drive_context_t *)drivep->d_contextp; #endif mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: erase\n" ); ASSERT( contextp->dc_mode == OM_NONE ); ASSERT( contextp->dc_fd >= 0 ); /* use validating tape rewind util func */ (void )rewind_and_verify( drivep ); /* use validating tape erase util func */ ( void )erase_and_verify( drivep ); /* rewind again */ ( void )rewind_and_verify( drivep ); /* close the drive so we start from scratch */ Close( drivep ); return 0; } /* do_eject * pop the tape out - may be a nop on some drives * * RETURNS: * 0 on sucess * DRIVE_ERROR_DEVICE on failure */ static intgen_t do_eject_media( drive_t *drivep ) { drive_context_t *contextp = (drive_context_t *)drivep->d_contextp; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: eject media\n" ); /* drive must be open */ ASSERT( contextp->dc_fd >= 0 ); ASSERT( contextp->dc_mode == OM_NONE ); #if 0 /* issue tape unload */ if ( contextp->dc_unloadokpr ) { ( void )mt_op( contextp->dc_fd, MTUNLOAD, 0 ); } #endif /* close the device driver */ Close( drivep ); return 0; } /* do_get_device_class * Return the device class * * RETURNS: * always returns DEVICE_TAPE_REMOVABLE */ /* ARGSUSED */ static intgen_t do_get_device_class( drive_t *drivep) { mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: get device class\n" ); return DEVICE_TAPE_REMOVABLE; } /* do_display_metrics - print ring stats if using I/O ring */ static void do_display_metrics( drive_t *drivep ) { drive_context_t *contextp = (drive_context_t *)drivep->d_contextp; ring_t *ringp = contextp->dc_ringp; if ( ringp ) { if ( drivecnt > 1 ) { mlog( MLOG_NORMAL | MLOG_BARE | MLOG_NOLOCK | MLOG_DRIVE, "drive %u ", drivep->d_index ); } display_ring_metrics( drivep, MLOG_NORMAL | MLOG_BARE | MLOG_NOLOCK ); } } /* do_quit */ static void do_quit( drive_t *drivep ) { drive_context_t *contextp = (drive_context_t *)drivep->d_contextp; ring_t *ringp = contextp->dc_ringp; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op: quit\n" ); /* print the ring metrics and kill the ring */ if ( ringp ) { display_ring_metrics( drivep, MLOG_VERBOSE ); /* tell slave to die */ mlog( (MLOG_NITTY + 1) | MLOG_DRIVE, "ring op: destroy\n" ); ring_destroy( ringp ); } Close(drivep); mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt drive op quit complete\n" ); } static double percent64( off64_t num, off64_t denom ) { return ( double )( num * 100 ) / ( double )denom; } /* read_label * responsible for reading and validating the first record from a * media file. can assume that prepare_drive has already been run * on this tape. if read fails due to an encounter with a file mark, * end of media, or end of data, position the media to allow an * append. * * RETURNS: * 0 on success * DRIVE_ERROR_* on failure */ static intgen_t read_label( drive_t *drivep ) { drive_context_t *contextp; intgen_t nread; intgen_t saved_errno; intgen_t rval; /* initialize context ptr */ contextp = ( drive_context_t * )drivep->d_contextp; /* read the first record of the media file directly */ nread = Read( drivep, contextp->dc_recp, tape_recsz, &saved_errno ); /* if a read error, get status */ if ( nread != ( intgen_t )tape_recsz ) { ASSERT( nread < ( intgen_t )tape_recsz ); } /* check for an unexpected errno */ if ( nread < 0 && saved_errno != ENOSPC ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "could not read from drive: %s (%d)\n", strerror( errno ), errno ); return DRIVE_ERROR_DEVICE; } /* check for a blank tape/EOD. */ if (( nread == 0 ) /* takes care of sun */ || /* now handle SGI */ (nread < 0 && saved_errno == ENOSPC )) { mlog( MLOG_NORMAL | MLOG_DRIVE, "encountered EOD : " #ifdef DUMP "assuming blank media\n" ); #endif #ifdef RESTORE "end of data\n" ); #endif ( void )rewind_and_verify( drivep ); #ifdef DUMP return DRIVE_ERROR_BLANK; #endif #ifdef RESTORE return DRIVE_ERROR_EOD; #endif } /* dc_iocnt is count of number of records read without error */ contextp->dc_iocnt = 1; rval = validate_media_file_hdr( drivep ); return rval; } static intgen_t validate_media_file_hdr( drive_t *drivep ) { global_hdr_t *grhdrp = drivep->d_greadhdrp; drive_hdr_t *drhdrp = drivep->d_readhdrp; rec_hdr_t *tprhdrp = (rec_hdr_t *)drhdrp->dh_specific; media_hdr_t *mrhdrp = (media_hdr_t *)drhdrp->dh_upper; content_hdr_t *ch = (content_hdr_t *)mrhdrp->mh_upper; content_inode_hdr_t *cih = (content_inode_hdr_t *)ch->ch_specific; drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; char tmpbuf[GLOBAL_HDR_SZ]; global_hdr_t *tmpgh = (global_hdr_t *)&tmpbuf[0]; drive_hdr_t *tmpdh = (drive_hdr_t *)tmpgh->gh_upper; media_hdr_t *tmpmh = (media_hdr_t *)tmpdh->dh_upper; rec_hdr_t *tmprh = (rec_hdr_t *)tmpdh->dh_specific; content_hdr_t *tmpch = (content_hdr_t *)tmpmh->mh_upper; content_inode_hdr_t *tmpcih = (content_inode_hdr_t *)tmpch->ch_specific; mlog( MLOG_DEBUG | MLOG_DRIVE, "validating media file header\n" ); memcpy( tmpbuf, contextp->dc_recp, GLOBAL_HDR_SZ ); /* check the checksum */ if ( ! global_hdr_checksum_check( tmpgh )) { mlog( MLOG_DEBUG | MLOG_DRIVE, "bad media file header checksum\n"); return DRIVE_ERROR_CORRUPTION; } if ( ! tape_rec_checksum_check( contextp, contextp->dc_recp )) { mlog( MLOG_NORMAL | MLOG_DRIVE, "tape record checksum error\n"); return DRIVE_ERROR_CORRUPTION; } xlate_global_hdr(tmpgh, grhdrp, 1); xlate_drive_hdr(tmpdh, drhdrp, 1); xlate_media_hdr(tmpmh, mrhdrp, 1); xlate_content_hdr(tmpch, ch, 1); xlate_content_inode_hdr(tmpcih, cih, 1); xlate_rec_hdr(tmprh, tprhdrp, 1); memcpy( contextp->dc_recp, grhdrp, GLOBAL_HDR_SZ ); /* check the magic number */ if ( strncmp( grhdrp->gh_magic, GLOBAL_HDR_MAGIC,GLOBAL_HDR_MAGIC_SZ)) { mlog( MLOG_DEBUG | MLOG_DRIVE, "missing magic number in tape label\n"); return DRIVE_ERROR_FORMAT; } /* check the version */ if ( global_version_check( grhdrp->gh_version ) != BOOL_TRUE ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "invalid version number (%d) in tape label\n", grhdrp->gh_version ); return DRIVE_ERROR_VERSION; } /* check the strategy id */ if ( drhdrp->dh_strategyid != drivep->d_strategyp->ds_id ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "unrecognized drive strategy ID (%d)\n", drivep->d_readhdrp->dh_strategyid ); return DRIVE_ERROR_FORMAT; } /* check the record magic number */ if ( tprhdrp->magic != STAPE_MAGIC ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "invalid record magic number in tape label\n"); return DRIVE_ERROR_FORMAT; } /* check the record version number */ if ( tprhdrp->version != STAPE_VERSION ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "invalid record version number in tape label\n"); return DRIVE_ERROR_VERSION; } mlog( MLOG_DEBUG | MLOG_DRIVE, "media file header valid: " "media file ix %d\n", mrhdrp->mh_mediafileix ); return 0; } /* get_tpcaps * Get the specific tape drive capabilities. Set the * d_capabilities field of the driver structure. * set the blksz limits and tape type in the context structure. * * RETURNS: * TRUE on success * FALSE on error */ static bool_t get_tpcaps( drive_t *drivep ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; ASSERT( contextp->dc_fd >= 0 ); /* can't ask about blksz, can't set blksz, can't ask about * drive types/caps. assume a drive which can overwrite. * assume NOT QIC, since fixed blksz devices not supported * via RMT. */ drivep->d_capabilities |= DRIVE_CAP_OVERWRITE; drivep->d_capabilities |= DRIVE_CAP_BSF; set_recommended_sizes( drivep, contextp->dc_isQICpr); return BOOL_TRUE; } /* set_recommended_sizes * Determine the recommended tape file size and mark separation * based on tape device type. * * RETURNS: * void */ static void set_recommended_sizes( drive_t *drivep, int isQICpr ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; off64_t fsize = drive_strategy_rmt.ds_recmfilesz; off64_t marksep = drive_strategy_rmt.ds_recmarksep; if (isQICpr == BOOL_TRUE) { fsize = 0x3200000ll; /* 50 MB */ } if ( contextp->dc_singlemfilepr ) /* use only one media file */ { fsize = OFF64MAX; /* hence set fsize to max */ mlog( MLOG_DEBUG | MLOG_DRIVE, "Single media file specified. " "Set media file size to 0x%llx bytes\n", OFF64MAX ); } else if (contextp->dc_filesz > 0) { fsize = contextp->dc_filesz; #ifdef DUMP #ifdef SIZEEST if ( hdr_mfilesz > fsize ) { mlog( MLOG_WARNING, "recomended media file size of %llu Mb less than " "estimated file header size %llu Mb for %s\n", fsize / ( 1024 * 1024 ), hdr_mfilesz / ( 1024 * 1024 ), drivep->d_pathname ); } #endif /* SIZEEST */ #endif /* DUMP */ } #ifdef DUMP #ifdef SIZEEST else { /* override with minimum recommended file size */ if ( min_recmfilesz > fsize ) { mlog( MLOG_NOTE, "recommended media file size adjusted from " "%llu Mb to %llu Mb for %s", min_recmfilesz / ( 1024 * 1024 ), fsize / ( 1024 * 1024 ), drivep->d_pathname ); fsize = min_recmfilesz; } } mlog( MLOG_NITTY, "hdr_mfilesz %lluMb, min_recmfilesize %lluMb, " "fsize %lluMb, marksep %lluMb\n", hdr_mfilesz / ( 1024 * 1024 ), min_recmfilesz / ( 1024 * 1024 ), fsize / ( 1024 * 1024 ), marksep / ( 1024 * 1024 )); #endif /* SIZEEST */ #endif /* DUMP */ mlog( MLOG_DEBUG | MLOG_DRIVE, "recommended tape media file size set to 0x%llx bytes\n", fsize ); mlog( MLOG_DEBUG | MLOG_DRIVE, "recommended tape media mark separation set to 0x%llx bytes\n", marksep ); drivep->d_recmfilesz = fsize; drivep->d_recmarksep = marksep; return; } /* mt_op * Issue MTIOCTOP ioctl operation to the tape device. * * RETURNS: * 0 on sucess * -1 on failure */ static intgen_t mt_op(intgen_t fd, intgen_t sub_op, intgen_t param ) { struct mtop mop; char *printstr; intgen_t rval; mop.mt_op = (short )sub_op; mop.mt_count = param; ASSERT( fd >= 0 ); switch ( sub_op ) { case MTSEEK: printstr = "seek"; break; case MTBSF: /* 2 */ printstr = "back space file"; break; case MTWEOF: /* 0 */ printstr = "write file mark"; break; case MTFSF: /* 1 */ printstr = "forward space file"; break; case MTREW: /* 5 */ printstr = "rewind"; break; case MTUNLOAD: printstr = "unload"; break; case MTEOM: printstr = "advance to EOD"; break; case MTFSR: /* 3 */ printstr = "forward space block"; break; case MTERASE: printstr = "erase"; break; #ifdef CLRMTAUD #ifdef MTAUD case MTAUD: printstr = "audio"; break; #endif /* MTAUD */ #endif /* CLRMTAUD */ default: printstr = "???"; break; } mlog( MLOG_DEBUG | MLOG_DRIVE, "tape op: %s %d\n", printstr, param ); rval = ioctl( fd, MTIOCTOP, &mop ); if ( rval < 0 ) { /* failure */ mlog( MLOG_DEBUG | MLOG_DRIVE, "tape op %s %d returns %d: errno == %d (%s)\n", printstr, param, rval, errno, strerror( errno )); return -1; } /* success */ return 0; } /* determine_write_error() * Using the errno and the tape status information, determine the * type of tape write error that has occured. * * RETURNS: * DRIVE_ERROR_* */ static intgen_t determine_write_error( int nwritten, int saved_errno ) { intgen_t ret = 0; if ( saved_errno == EACCES ) { mlog(MLOG_NORMAL, "tape is write protected\n"); ret = DRIVE_ERROR_DEVICE; } else if ( ( saved_errno == ENOSPC ) || ( saved_errno == EIO ) || (( saved_errno == 0 ) && ( nwritten >= 0 )) /* short write indicates EOM */ ) { mlog(MLOG_NORMAL, "tape media error on write operation\n"); mlog(MLOG_NORMAL, "no more data can be written to this tape\n"); ret = DRIVE_ERROR_EOM; } else if ( saved_errno != 0 ) { ret = DRIVE_ERROR_CORE; mlog( MLOG_DEBUG | MLOG_DRIVE, "tape unknown error on write operation: " "%d, %d\n", nwritten, saved_errno); } mlog( MLOG_NITTY | MLOG_DRIVE, "tape write operation nwritten %d, errno %d\n", nwritten, saved_errno); return ( ret ); } static void tape_rec_checksum_set( drive_context_t *contextp, char *bufp ) { rec_hdr_t *rechdrp = ( rec_hdr_t * )bufp; u_int32_t *beginp = ( u_int32_t * )bufp; u_int32_t *endp = ( u_int32_t * )( bufp + tape_recsz ); u_int32_t *p; u_int32_t accum; if ( ! contextp->dc_recchksumpr ) { return; } INT_SET(rechdrp->ischecksum, ARCH_CONVERT, 1); rechdrp->checksum = 0; accum = 0; for ( p = beginp ; p < endp ; p++ ) { accum += INT_GET(*p, ARCH_CONVERT); } INT_SET(rechdrp->checksum, ARCH_CONVERT, ( int32_t )( ~accum + 1 )); } static bool_t tape_rec_checksum_check( drive_context_t *contextp, char *bufp ) { rec_hdr_t *rechdrp = ( rec_hdr_t * )bufp; u_int32_t *beginp = ( u_int32_t * )bufp; u_int32_t *endp = ( u_int32_t * )( bufp + tape_recsz ); u_int32_t *p; u_int32_t accum; if ( contextp->dc_recchksumpr && INT_GET(rechdrp->ischecksum, ARCH_CONVERT) ) { accum = 0; for ( p = beginp ; p < endp ; p++ ) { accum += INT_GET(*p, ARCH_CONVERT); } return accum == 0 ? BOOL_TRUE : BOOL_FALSE; } else { return BOOL_TRUE; } } /* to trace rmt operations */ #ifdef RMT #ifdef RMTDBG static int dbgrmtopen( char *path, int flags ) { int rval; rval = rmtopen( path, flags ); mlog( MLOG_NORMAL | MLOG_DRIVE, "RMTOPEN( %s, %d ) returns %d: errno=%d (%s)\n", path, flags, rval, errno, strerror( errno )); return rval; } static int dbgrmtclose( int fd ) { int rval; rval = rmtclose( fd ); mlog( MLOG_NORMAL | MLOG_DRIVE, "RMTCLOSE( %d ) returns %d: errno=%d (%s)\n", fd, rval, errno, strerror( errno )); return rval; } static int dbgrmtioctl( int fd, int op, void *arg ) { int rval; rval = rmtioctl( fd, op, arg ); mlog( MLOG_NORMAL | MLOG_DRIVE, "RMTIOCTL( %d, %d, 0x%x ) returns %d: errno=%d (%s)\n", fd, op, arg, rval, errno, strerror( errno )); return rval; } static int dbgrmtread( int fd, void *p, uint sz ) { int rval; rval = rmtread( fd, p, sz ); mlog( MLOG_NORMAL | MLOG_DRIVE, "RMTREAD( %d, 0x%x, %u ) returns %d: errno=%d (%s)\n", fd, p, sz, rval, errno, strerror( errno )); return rval; } static int dbgrmtwrite( int fd, void *p, uint sz ) { int rval; rval = rmtwrite( fd, p, sz ); mlog( MLOG_NORMAL | MLOG_DRIVE, "RMTWRITE( %d, 0x%x, %u ) returns %d: errno=%d (%s)\n", fd, p, sz, rval, errno, strerror( errno )); return rval; } #endif /* RMTDBG */ #endif /* RMT */ /* display_access_failed_message() * Print tape device open/access failed message. * * RETURNS: * void */ static void display_access_failed_message( drive_t *drivep ) { mlog( MLOG_NORMAL | MLOG_DRIVE, "attempt to access/open remote " "tape drive %s failed: %d (%s)\n", drivep->d_pathname, errno, strerror( errno )); return; } /* prepare_drive - called by begin_read if drive device not open. * determines record size and sets block size if fixed block device. * determines other drive attributes. determines if any previous * xfsdumps on media. */ static intgen_t prepare_drive( drive_t *drivep ) { drive_context_t *contextp; bool_t ok; ix_t try; ix_t maxtries; bool_t changedblkszpr; intgen_t rval; /* get pointer to drive context */ contextp = ( drive_context_t * )drivep->d_contextp; /* retry: */ if ( cldmgr_stop_requested( )) { return DRIVE_ERROR_STOP; } /* shouldn't be here if drive is open */ ASSERT( contextp->dc_fd == -1 ); mlog( MLOG_VERBOSE | MLOG_DRIVE, "preparing drive\n" ); /* determine if tape is present or write protected. try several times. * if not present or write-protected during dump, return. */ maxtries = 15; for ( try = 1 ; ; sleep( 10 ), try++ ) { if ( cldmgr_stop_requested( )) { return DRIVE_ERROR_STOP; } /* open the drive */ ok = Open( drivep ); if ( ! ok ) { if ( errno != EBUSY ) { display_access_failed_message( drivep ); return DRIVE_ERROR_DEVICE; } else { mlog( MLOG_DEBUG | MLOG_DRIVE, "open drive returns EBUSY\n" ); if ( try >= maxtries ) { mlog( MLOG_TRACE | MLOG_DRIVE, "giving up waiting for drive " "to indicate online\n" ); return DRIVE_ERROR_MEDIA; } Close( drivep ); continue; } } else break; } /* determine tape capabilities. this will set the drivep->d_capabilities * and contextp->dc_{...}blksz and dc_isQICpr, as well as recommended * mark separation and media file size. */ ok = get_tpcaps( drivep ); if ( ! ok ) { return DRIVE_ERROR_DEVICE; } /* establish the initial block and record sizes we will try. * if unable to ask drive about fixed block sizes, we will * guess. */ tape_blksz = cmdlineblksize; if ( tape_blksz > STAPE_MAX_RECSZ ) { tape_blksz = STAPE_MAX_RECSZ; } if ( contextp->dc_isQICpr == BOOL_TRUE ) tape_recsz = STAPE_MIN_MAX_BLKSZ; else tape_recsz = tape_blksz; /* if the overwrite option was specified , return. */ if ( contextp->dc_overwritepr ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "Overwrite option specified.\n" ); return DRIVE_ERROR_OVERWRITE; } /* loop trying to read a record. begin with the record size * calculated above. if it appears we have selected the wrong * block size and if we are able to alter the fixed block size, * and the record size we tried initially was not less than * the minmax block size, change the block size to minmax and * try to read a one block record again. */ maxtries = 5; changedblkszpr = BOOL_FALSE; for ( try = 1 ; ; try++ ) { intgen_t nread; intgen_t saved_errno; if ( cldmgr_stop_requested( )) { return DRIVE_ERROR_STOP; } /* bail out if we've tried too many times */ if ( try > maxtries ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "giving up attempt to determining " "tape record size\n" ); return DRIVE_ERROR_MEDIA; } mlog( MLOG_DEBUG | MLOG_DRIVE, "determining tape record size: trying %d (0x%x) bytes\n", tape_recsz, tape_recsz ); /* read a record. use the first ring buffer */ saved_errno = 0; nread = Read( drivep, contextp->dc_recp, tape_recsz, &saved_errno ); ASSERT( saved_errno == 0 || nread < 0 ); /* RMT can require a retry */ if ( saved_errno == EAGAIN ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "read returned EAGAIN: retrying\n" ); continue; } /* block size is bigger than buffer; should never happen */ if ( saved_errno == EINVAL ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "read returned EINVAL: " "trying new record size\n" ); goto largersize; } /* block size is bigger than buffer; should never happen */ if ( saved_errno == ENOMEM ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "read returned ENOMEM: " "trying new record size\n" ); goto largersize; } /* I/O error */ if ( saved_errno == EIO ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "read returned EIO: will reopen, " "and try again\n" ); Close( drivep ); ok = Open( drivep ); if ( ! ok ) { display_access_failed_message( drivep ); return DRIVE_ERROR_DEVICE; } #ifdef RESTORE continue; #endif #ifdef DUMP if (3 == try) return DRIVE_ERROR_BLANK; /* sun rmt returns EIO for blank media */ else continue; #endif } /* ENOSPC */ if ( saved_errno == ENOSPC ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "read returned ENOSPC: will reopen, " "and try again\n" ); Close( drivep ); ok = Open( drivep ); if ( ! ok ) { display_access_failed_message( drivep ); return DRIVE_ERROR_DEVICE; } #ifdef RESTORE continue; #endif #ifdef DUMP if (3 == try) /* IRIX rmt returns ENOSPC for blank media */ /* It reads to the EOD */ return DRIVE_ERROR_BLANK; else continue; #endif } if ( nread == ( intgen_t )tape_recsz ) { mlog( MLOG_DEBUG | MLOG_DRIVE, "nread == selected blocksize " "indicates correct blocksize found\n" ); goto checkhdr; } /* short read */ if (( saved_errno == 0 ) && ( nread < (intgen_t)tape_recsz)) { mlog( MLOG_DEBUG | MLOG_DRIVE, "nread < selected blocksize " "indicates incorrect blocksize found " "or foreign media\n" ); return DRIVE_ERROR_FOREIGN; } /* if we fell through the seive, code is wrong. * display useful info and abort */ mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, "unexpected tape error: " "errno %d " "nread %d " "blksz %d " "recsz %d " "\n", saved_errno, nread, tape_blksz, tape_recsz, 0 ); /*return DRIVE_ERROR_CORE; */ return DRIVE_ERROR_MEDIA; checkhdr: rval = validate_media_file_hdr( drivep ); if ( rval ) { if ( rval == DRIVE_ERROR_VERSION ) { global_hdr_t *grhdrp = drivep->d_greadhdrp; mlog( MLOG_NORMAL | MLOG_DRIVE, "media file header version (%d) " "invalid: advancing\n", grhdrp->gh_version ); continue; } else { if ( isefsdump( drivep )) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "may be an EFS dump at BOT\n" ); } else /* Check if the tape was erased by us */ if ( isxfsdumperasetape( drivep )) { mlog( MLOG_NORMAL | MLOG_DRIVE, "This tape was erased earlier " "by xfsdump.\n" ); ( void )rewind_and_verify( drivep ); return DRIVE_ERROR_BLANK; } else { mlog( MLOG_NORMAL | MLOG_DRIVE, "bad media file header at BOT " "indicates foreign or " "corrupted tape\n" ); } ( void )rewind_and_verify( drivep ); ok = set_best_blk_and_rec_sz( drivep ); if ( ! ok ) { return DRIVE_ERROR_DEVICE; } return DRIVE_ERROR_FOREIGN; } } else { drive_hdr_t *drhdrp; rec_hdr_t *tprhdrp; drhdrp = drivep->d_readhdrp; tprhdrp = ( rec_hdr_t * )drhdrp->dh_specific; ASSERT( tprhdrp->recsize >= 0 ); tape_recsz = ( size_t )tprhdrp->recsize; break; } largersize: /* we end up here if we want to try a new larger record size * because the last one was not big enough for the tape block */ if ( changedblkszpr ) { mlog( MLOG_NORMAL | MLOG_DRIVE, "cannot determine tape block size " "after two tries\n" ); mlog( MLOG_NORMAL | MLOG_DRIVE, "assuming media is corrupt " "or contains non-xfsdump data\n" ); ok = set_best_blk_and_rec_sz( drivep ); if ( ! ok ) { return DRIVE_ERROR_DEVICE; } return DRIVE_ERROR_FOREIGN; } /* Make it as large as we can go */ if ( tape_recsz != STAPE_MAX_RECSZ ) { tape_recsz = STAPE_MAX_RECSZ; if ( ! contextp->dc_isQICpr ) { tape_blksz = tape_recsz;; } changedblkszpr = BOOL_TRUE; } else { mlog( MLOG_NORMAL | MLOG_DRIVE, "cannot determine tape block size\n" ); return DRIVE_ERROR_MEDIA; } continue; } mlog( MLOG_DEBUG | MLOG_DRIVE, "read first record of first media file encountered on media: " "recsz == %u\n", tape_recsz ); /* calculate maximum bytes lost without error at end of tape */ calc_max_lost( drivep ); contextp->dc_iocnt = 1; return 0; } /* if BOOL_FALSE returned, errno is valid */ static bool_t Open( drive_t *drivep ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; intgen_t oflags; #ifdef DUMP oflags = O_RDWR; #endif /* DUMP */ #ifdef RESTORE oflags = O_RDONLY; #endif /* RESTORE */ mlog( MLOG_DEBUG | MLOG_DRIVE, "tape op: opening drive '%s'\n", drivep->d_pathname); ASSERT( contextp->dc_fd == -1 ); errno = 0; contextp->dc_fd = open_masked_signals( drivep->d_pathname, oflags ); if ( contextp->dc_fd <= 0 ) { return BOOL_FALSE; } return BOOL_TRUE; } static void Close( drive_t *drivep ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; mlog( MLOG_DEBUG | MLOG_DRIVE, "tape op: closing drive\n" ); ASSERT( contextp->dc_fd >= 0 ); ( void )close( contextp->dc_fd ); contextp->dc_fd = -1; } static intgen_t Read( drive_t *drivep, char *bufp, size_t cnt, intgen_t *errnop ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; intgen_t nread; #if 0 mlog( MLOG_DEBUG | MLOG_DRIVE, "tape op: reading %u bytes\n", cnt ); #endif ASSERT( contextp->dc_fd >= 0 ); ASSERT( bufp ); *errnop = 0; errno = 0; nread = read( contextp->dc_fd, ( void * )bufp, cnt ); if ( nread < 0 ) { *errnop = errno; mlog( MLOG_NITTY | MLOG_DRIVE, "tape op read of %u bytes failed: errno == %d (%s)\n", cnt, errno, strerror( errno )); } else if ( nread != ( intgen_t )cnt ) { mlog( MLOG_NITTY | MLOG_DRIVE, "tape op read of %u bytes short: nread == %d\n", cnt, nread ); } else { mlog( MLOG_NITTY | MLOG_DRIVE, "tape op read of %u bytes successful\n", cnt ); } return nread; } static intgen_t Write( drive_t *drivep, char *bufp, size_t cnt, intgen_t *errnop ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; intgen_t nwritten; mlog( MLOG_DEBUG | MLOG_DRIVE, "tape op: writing %u bytes\n", cnt ); ASSERT( contextp->dc_fd >= 0 ); ASSERT( bufp ); *errnop = 0; errno = 0; nwritten = write( contextp->dc_fd, ( void * )bufp, cnt ); if ( nwritten < 0 ) { *errnop = errno; mlog( MLOG_NITTY | MLOG_DRIVE, "tape op write of %u bytes failed: errno == %d (%s)\n", cnt, errno, strerror( errno )); } else if ( nwritten != ( intgen_t )cnt ) { mlog( MLOG_NITTY | MLOG_DRIVE, "tape op write of %u bytes short: nwritten == %d\n", cnt, nwritten ); } else { mlog( MLOG_NITTY | MLOG_DRIVE, "tape op write of %u bytes successful\n", cnt ); } return nwritten; } /* validate a record header, log any anomolies, and return appropriate * indication. */ static intgen_t record_hdr_validate( drive_t *drivep, char *bufp, bool_t chkoffpr ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; global_hdr_t *grhdrp = drivep->d_greadhdrp; rec_hdr_t rechdr; rec_hdr_t *rechdrp = &rechdr; rec_hdr_t *tmprh = ( rec_hdr_t * )bufp; if ( ! tape_rec_checksum_check( contextp, bufp )) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "record %lld corrupt: bad record checksum\n", contextp->dc_iocnt - 1 ); return DRIVE_ERROR_CORRUPTION; } xlate_rec_hdr(tmprh, rechdrp, 1); if ( rechdrp->magic != STAPE_MAGIC ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "record %lld corrupt: bad magic number\n", contextp->dc_iocnt - 1 ); return DRIVE_ERROR_CORRUPTION; } if ( uuid_is_null( rechdrp->dump_uuid )) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "record %lld corrupt: null dump id\n", contextp->dc_iocnt - 1 ); return DRIVE_ERROR_CORRUPTION; } if ( uuid_compare( grhdrp->gh_dumpid, rechdrp->dump_uuid ) != 0) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "record %lld corrupt: dump id mismatch\n", contextp->dc_iocnt - 1 ); return DRIVE_ERROR_CORRUPTION; } /* can't check size field of record header, since * 5.3 version of xfsdump did not set it properly. */ #ifdef RECSZCHK if ( ( size_t )rechdrp->recsize != tape_recsz ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "record %lld corrupt: incorrect record size in header\n", contextp->dc_iocnt - 1 ); return DRIVE_ERROR_CORRUPTION; } #else /* RECSZCHK */ mlog( (MLOG_NITTY + 1) | MLOG_NOTE | MLOG_DRIVE, "record %lld header record size %d (0x%x)\n", contextp->dc_iocnt - 1, rechdrp->recsize, rechdrp->recsize ); #endif /* RECSZCHK */ if ( rechdrp->file_offset % ( off64_t )tape_recsz ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "record %lld corrupt: record offset in header " "not a multiple of record size\n", contextp->dc_iocnt - 1 ); return DRIVE_ERROR_CORRUPTION; } if ( chkoffpr && rechdrp->file_offset != ( contextp->dc_iocnt - 1 ) * ( off64_t )tape_recsz ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "record %lld corrupt: " "incorrect record offset in header (0x%llx)\n", contextp->dc_iocnt - 1, rechdrp->file_offset ); return DRIVE_ERROR_CORRUPTION; } if ( rechdrp->rec_used > tape_recsz || rechdrp->rec_used < STAPE_HDR_SZ ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, "record %lld corrupt: " "incorrect record padding offset in header\n", contextp->dc_iocnt - 1 ); return DRIVE_ERROR_CORRUPTION; } memcpy(tmprh, rechdrp, sizeof(*rechdrp)); return 0; } /* do a read, determine DRIVE_ERROR_... if failure, and return failure code. * return 0 on success. */ static intgen_t read_record( drive_t *drivep, char *bufp ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; intgen_t nread; intgen_t saved_errno; intgen_t rval; nread = Read( drivep, bufp, tape_recsz, &saved_errno ); if ( nread == ( intgen_t )tape_recsz ) { contextp->dc_iocnt++; rval = record_hdr_validate( drivep, bufp, BOOL_TRUE ); return rval; } /* check for a blank tape/EOD. */ if (( nread == 0 ) /* takes care of sun */ || /* now handle SGI */ (nread < 0 && saved_errno == ENOSPC )) { mlog( MLOG_NORMAL | MLOG_DRIVE, "read_record encountered EOD : " #ifdef DUMP "assuming blank media\n" ); #endif #ifdef RESTORE "end of data\n" ); #endif #ifdef DUMP return DRIVE_ERROR_BLANK; #endif #ifdef RESTORE return DRIVE_ERROR_EOD; #endif } /* some other error */ if ( saved_errno == EIO ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, "unexpected EIO error attempting to read record \n"); #ifdef RESTORE return DRIVE_ERROR_EOM; #endif #ifdef DUMP return DRIVE_ERROR_CORRUPTION; #endif } /* short read */ if ( nread >= 0 ) { ASSERT( nread <= ( intgen_t )tape_recsz ); mlog( MLOG_DEBUG | MLOG_DRIVE, "short read record %lld (nread == %d)\n", contextp->dc_iocnt, nread ); return DRIVE_ERROR_CORRUPTION; } /* some other error */ mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, "unexpected error attempting to read record %lld: " "read returns %d, errno %d (%s)\n", contextp->dc_iocnt, nread, saved_errno, strerror( saved_errno )); return DRIVE_ERROR_CORRUPTION; } static int ring_read( void *clientctxp, char *bufp ) { return read_record( ( drive_t * )clientctxp, bufp ); } /* gets another record IF dc_recp is NULL */ static intgen_t getrec( drive_t *drivep ) { drive_context_t *contextp; contextp = ( drive_context_t * )drivep->d_contextp; while ( ! contextp->dc_recp ) { rec_hdr_t *rechdrp; if ( contextp->dc_singlethreadedpr ) { intgen_t rval; contextp->dc_recp = contextp->dc_bufp; rval = read_record( drivep, contextp->dc_recp ); if ( rval ) { contextp->dc_errorpr = BOOL_TRUE; return rval; } } else { contextp->dc_msgp = Ring_get( contextp->dc_ringp ); switch( contextp->dc_msgp->rm_stat ) { case RING_STAT_OK: contextp->dc_recp = contextp->dc_msgp->rm_bufp; break; case RING_STAT_INIT: case RING_STAT_NOPACK: case RING_STAT_IGNORE: contextp->dc_msgp->rm_op = RING_OP_READ; Ring_put( contextp->dc_ringp, contextp->dc_msgp ); contextp->dc_msgp = 0; continue; case RING_STAT_ERROR: contextp->dc_errorpr = BOOL_TRUE; return contextp->dc_msgp->rm_rval; default: ASSERT( 0 ); contextp->dc_errorpr = BOOL_TRUE; return DRIVE_ERROR_CORE; } } rechdrp = ( rec_hdr_t * )contextp->dc_recp; contextp->dc_recendp = contextp->dc_recp + tape_recsz; contextp->dc_dataendp = contextp->dc_recp + rechdrp->rec_used; contextp->dc_nextp = contextp->dc_recp + STAPE_HDR_SZ; ASSERT( contextp->dc_nextp <= contextp->dc_dataendp ); } return 0; } /* do a write, determine DRIVE_ERROR_... if failure, and return failure code. * return 0 on success. */ /*ARGSUSED*/ static intgen_t write_record( drive_t *drivep, char *bufp, bool_t chksumpr, bool_t xlatepr ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; intgen_t nwritten; intgen_t saved_errno; intgen_t rval; if ( xlatepr ) { rec_hdr_t rechdr; memcpy( &rechdr, bufp, sizeof(rechdr) ); xlate_rec_hdr( &rechdr, ( rec_hdr_t * )bufp, 1 ); } if ( chksumpr ) { tape_rec_checksum_set( contextp, bufp ); } nwritten = Write( drivep, bufp, tape_recsz, &saved_errno ); if ( nwritten == ( intgen_t )tape_recsz ) { contextp->dc_iocnt++; return 0; } rval = determine_write_error( nwritten, saved_errno ); ASSERT(rval); return rval; } static int ring_write( void *clientctxp, char *bufp ) { return write_record( ( drive_t * )clientctxp, bufp, BOOL_TRUE, BOOL_TRUE ); } static void ring_thread( void *clientctxp, int ( * entryp )( void *ringctxp ), void *ringctxp ) { drive_t *drivep = ( drive_t * )clientctxp; /* REFERENCED */ bool_t ok; ok = cldmgr_create( entryp, CLONE_VM, drivep->d_index, "slave", ringctxp ); ASSERT( ok ); } static ring_msg_t * Ring_get( ring_t *ringp ) { ring_msg_t *msgp; mlog( (MLOG_NITTY + 1) | MLOG_DRIVE, "ring op: get\n" ); msgp = ring_get( ringp ); return msgp; } static void Ring_put( ring_t *ringp, ring_msg_t *msgp ) { mlog( (MLOG_NITTY + 1) | MLOG_DRIVE, "ring op: put %d\n", msgp->rm_op ); ring_put( ringp, msgp ); } static void Ring_reset( ring_t *ringp, ring_msg_t *msgp ) { mlog( (MLOG_NITTY + 1) | MLOG_DRIVE, "ring op: reset\n" ); ASSERT( ringp ); ring_reset( ringp, msgp ); } /* a simple heuristic to calculate the maximum uncertainty * of how much data actually was written prior to encountering * end of media. */ static void calc_max_lost( drive_t *drivep ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; if ( contextp->dc_isQICpr ) { contextp->dc_lostrecmax = 1; } else { contextp->dc_lostrecmax = 2; } } static void display_ring_metrics( drive_t *drivep, intgen_t mlog_flags ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; ring_t *ringp = contextp->dc_ringp; char bufszbuf[ 16 ]; char *bufszsfxp; if ( tape_recsz == STAPE_MIN_MAX_BLKSZ ) { ASSERT( ! ( STAPE_MIN_MAX_BLKSZ % 0x400 )); sprintf( bufszbuf, "%u", STAPE_MIN_MAX_BLKSZ / 0x400 ); ASSERT( strlen( bufszbuf ) < sizeof( bufszbuf )); bufszsfxp = "KB"; } else if ( tape_recsz == STAPE_MAX_RECSZ ) { ASSERT( ! ( STAPE_MAX_RECSZ % 0x100000 )); sprintf( bufszbuf, "%u", STAPE_MAX_RECSZ / 0x100000 ); ASSERT( strlen( bufszbuf ) < sizeof( bufszbuf )); bufszsfxp = "MB"; } else { sprintf( bufszbuf, "%u", (unsigned int)(tape_recsz / 0x400) ); bufszsfxp = "KB"; } mlog( mlog_flags, "I/O metrics: " "%u by %s%s %sring; " "%lld/%lld (%.0lf%%) records streamed; " "%.0lfB/s\n", contextp->dc_ringlen, bufszbuf, bufszsfxp, contextp->dc_ringpinnedpr ? "pinned " : "", ringp->r_slave_msgcnt - ringp->r_slave_blkcnt, ringp->r_slave_msgcnt, percent64( ringp->r_slave_msgcnt - ringp->r_slave_blkcnt, ringp->r_slave_msgcnt ), ( double )( ringp->r_all_io_cnt ) * ( double )tape_recsz / ( double )( time( 0 ) - ringp->r_first_io_time )); } #ifdef CLRMTAUD static u_int32_t #else /* CLRMTAUD */ static short #endif /* CLRMTAUD */ rewind_and_verify( drive_t *drivep ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; ix_t try; intgen_t rval; #if 0 rval = mt_op( contextp->dc_fd, MTREW, 0 ); for ( try = 1 ; ; try++ ) { if ( rval ) { sleep( 1 ); rval = mt_op( contextp->dc_fd, MTREW, 0 ); } else return 0; if ( try >= MTOP_TRIES_MAX ) { return 0; } sleep( 1 ); } /* NOTREACHED */ #else #if 0 Close(drivep); ++lgs_fileno; sprintf(drivep->d_pathname + (strlen(drivep->d_pathname) - 3), "%03d", lgs_fileno); Open(drivep); #endif return 0; #endif } #ifdef CLRMTAUD static u_int32_t #else /* CLRMTAUD */ static short #endif /* CLRMTAUD */ erase_and_verify( drive_t *drivep ) { char *tempbufp; intgen_t saved_errno; drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; mlog( MLOG_DEBUG | MLOG_DRIVE, "rmt : erase_and_verify\n" ); #if 0 /* Erase is not standard rmt. So we cannot use the line below. ( void )mt_op( contextp->dc_fd, MTERASE, 0 ); * So write a record of zeros to fake erase . Poor man's erase! * We put the ERASE_MAGIC string at the beginning so we can * detect if we have erased the tape. */ tempbufp = (char *) calloc( 1 , ( size_t )tape_recsz ); strcpy( tempbufp, ERASE_MAGIC ); Write( drivep, tempbufp, tape_recsz, &saved_errno ); free(tempbufp); #endif return 0; } #ifdef CLRMTAUD static u_int32_t #else /* CLRMTAUD */ static short #endif /* CLRMTAUD */ bsf_and_verify( drive_t *drivep ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; #if 0 return mt_op( contextp->dc_fd, MTBSF, 1 ); #else Close(drivep); ASSERT(lgs_fileno > 0); --lgs_fileno; mlog(MLOG_DEBUG | MLOG_DRIVE, "drive op: bsf %03d\n", lgs_fileno); sprintf(drivep->d_pathname + (strlen(drivep->d_pathname) - 3), "%03d", lgs_fileno); Open(drivep); return 0; #endif } #ifdef CLRMTAUD static u_int32_t #else /* CLRMTAUD */ static short #endif /* CLRMTAUD */ fsf_and_verify( drive_t *drivep ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; #if 0 ( void )mt_op( contextp->dc_fd, MTFSF, 1 ); #else Close(drivep); ++lgs_fileno; mlog(MLOG_DEBUG | MLOG_DRIVE, "drive op: fsf %03d\n", lgs_fileno); sprintf(drivep->d_pathname + (strlen(drivep->d_pathname) - 3), "%03d", lgs_fileno); Open(drivep); #endif return 0; } static bool_t set_best_blk_and_rec_sz( drive_t *drivep ) { drive_context_t *contextp = ( drive_context_t * )drivep->d_contextp; if ( contextp->dc_isQICpr == BOOL_TRUE ) tape_recsz = STAPE_MIN_MAX_BLKSZ; else tape_recsz = cmdlineblksize; return BOOL_TRUE; } static bool_t isefsdump( drive_t *drivep ) { int32_t *efshdrp = ( int32_t * )drivep->d_greadhdrp; int32_t efsmagic = efshdrp[ 6 ]; if ( efsmagic == 60011 || efsmagic == 60012 ) { return BOOL_TRUE; } else { return BOOL_FALSE; } } static bool_t isxfsdumperasetape( drive_t *drivep ) { if ( !strcmp( ( char * )drivep->d_greadhdrp, ERASE_MAGIC ) ) return BOOL_TRUE; else return BOOL_FALSE; } #ifdef OPENMASKED static intgen_t open_masked_signals( char *pathname, int oflags ) { bool_t isrmtpr; SIG_PF sigalrm_save; SIG_PF sigint_save; SIG_PF sighup_save; SIG_PF sigquit_save; SIG_PF sigcld_save; intgen_t rval; intgen_t saved_errno; if ( strchr( pathname, ':') ) { isrmtpr = BOOL_TRUE; } else { isrmtpr = BOOL_FALSE; } if ( isrmtpr ) { sigalrm_save = sigset( SIGALRM, SIG_IGN ); sigint_save = sigset( SIGINT, SIG_IGN ); sighup_save = sigset( SIGHUP, SIG_IGN ); sigquit_save = sigset( SIGQUIT, SIG_IGN ); sigcld_save = sigset( SIGCLD, SIG_IGN ); } errno = 0; rval = open( pathname, oflags ); saved_errno = errno; if ( isrmtpr ) { ( void )sigset( SIGCLD, sigcld_save ); ( void )sigset( SIGQUIT, sigquit_save ); ( void )sigset( SIGHUP, sighup_save ); ( void )sigset( SIGINT, sigint_save ); ( void )sigset( SIGALRM, sigalrm_save ); } errno = saved_errno; return rval; } #endif /* OPENMASKED */ --------------020001030404080908020804-- --------------ms020503080208080107080601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdjCC AxkwggKCoAMCAQICAwbSXDANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDIyMjE0MDUwMFoXDTAzMDIyMjE0MDUwMFowWjEP MA0GA1UEBBMGU29sdGF1MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIFNvbHRhdTEi MCAGCSqGSIb3DQEJARYTbGFycy5zb2x0YXVAc2xhYi5kZTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMu00nDw7NZP0Oi9EurgstreDdZopcxe8410uz5FXVkiEJgZ/AJBL5XG Sgtce5jv1WfP7lcHjP5I9AFoPHnfT2GfuDisAS35BGWj2cCFyVzjP6SNzCz0eEGSCItzG0tR HItbyb7A/SlW76P/lAsA/AS4gTk6D0CxhZyHr8TxvEn85uzhE983k4xLIBG8YgtGbYwtStfh 1GpUFSOde3T3LqsRPRzAXgX5O34RZdLz14Ec6BgBFcP0axJf+R+jHqIITKNuzNyUvjikQ3Q/ h0hBgEtmXLbZcGLhhLrzTWpjX6pAoDM7D+nHQWqfD1iRDEsAFy2iC8K3goF8UG9X3vCrMysC AwEAAaMwMC4wHgYDVR0RBBcwFYETbGFycy5zb2x0YXVAc2xhYi5kZTAMBgNVHRMBAf8EAjAA MA0GCSqGSIb3DQEBBAUAA4GBAMyNt9/6QQ3m+2Sbjhn889rjco3g6mhfT12GE51pRt4OJtZR mIqQ9xVtIebOHV5SxWpWES0g+hC7IX6zsccFHLyvqAosG8U6UJMt8GfSH7Vv/n3UomV7Cf13 ZXu/0TQ1PDtTipm9+y02FLZa6lEdQDpBnYuE6FB4ZT7XbnYNmt/gMIIDGTCCAoKgAwIBAgID BtJcMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwHhcNMDIwMjIyMTQwNTAwWhcNMDMwMjIyMTQwNTAwWjBaMQ8wDQYDVQQEEwZTb2x0 YXUxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgU29sdGF1MSIwIAYJKoZIhvcNAQkB FhNsYXJzLnNvbHRhdUBzbGFiLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA y7TScPDs1k/Q6L0S6uCy2t4N1milzF7zjXS7PkVdWSIQmBn8AkEvlcZKC1x7mO/VZ8/uVweM /kj0AWg8ed9PYZ+4OKwBLfkEZaPZwIXJXOM/pI3MLPR4QZIIi3MbS1Eci1vJvsD9KVbvo/+U CwD8BLiBOToPQLGFnIevxPG8Sfzm7OET3zeTjEsgEbxiC0ZtjC1K1+HUalQVI517dPcuqxE9 HMBeBfk7fhFl0vPXgRzoGAEVw/RrEl/5H6MeoghMo27M3JS+OKRDdD+HSEGAS2ZcttlwYuGE uvNNamNfqkCgMzsP6cdBap8PWJEMSwAXLaILwreCgXxQb1fe8KszKwIDAQABozAwLjAeBgNV HREEFzAVgRNsYXJzLnNvbHRhdUBzbGFiLmRlMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEE BQADgYEAzI233/pBDeb7ZJuOGfzz2uNyjeDqaF9PXYYTnWlG3g4m1lGYipD3FW0h5s4dXlLF alYRLSD6ELshfrOxxwUcvK+oCiwbxTpQky3wZ9IftW/+fdSiZXsJ/Xdle7/RNDU8O1OKmb37 LTYUtlrqUR1AOkGdi4ToUHhlPtdudg2a3+AwggM4MIICoaADAgECAhBmRXK3zHT1z2N2RYTQ LpEBMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVt YWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8w DQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5 NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQ UYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8E BAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAMbFLR135AXHl9VNsXXnWPZjAJhNigSKnEvgilegb SbcnewQ5uvzm8iTrkfq97A0qOPdQVahs9w2tTBu8A/S166JHn2yiDFiNMUIJEWywGmnRKxKy QF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggMnMIIDIwIB ATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMG0lwwCQYF Kw4DAhoFAKCCAWEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDIwNzI2MDk1NzI1WjAjBgkqhkiG9w0BCQQxFgQU/UhMava4pLU5RmZ7B9kiufqnxcswUgYJ KoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwga0GCyqGSIb3DQEJEAILMYGdoIGaMIGSMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x DzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNV BAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwbSXDANBgkqhkiG9w0BAQEF AASCAQAT2/8V9Gt6XiYRRFEj7g6iDd3jGJgPNZVYOk6ASgLd/qowQMCTprJIk9A6BFASFSc5 G0JQhq034WWg+9Dth2BAaoQnFkAzohAghmxIIss5y6xKBjyT3d8gKj0MyXce25MwEgzDxQxv 6pVSAirvyFBWUYfawLxBXcU147wnKxE+SYf0AsqDXxGaEVcjg+cTQ66U3/8Dv6D9zTjXQQmp 1RAuVSgykWVtv5N8w3uvM4APmq6ymdGGV8dXAIYze7JvCGcoQRqGiD4hdeTAdn0tQlFM0beO Emp/+SLssK73N+IZugsVhxDyQWkUdfdVZJoSbGEHXDS+bEEruH/rsuVCQg78AAAAAAAA --------------ms020503080208080107080601-- From owner-linux-xfs@oss.sgi.com Fri Jul 26 13:17:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6QKHJRw020000 for ; Fri, 26 Jul 2002 13:17:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6QKHJwk019999 for linux-xfs-outgoing; Fri, 26 Jul 2002 13:17:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6QKHCRw019971 for ; Fri, 26 Jul 2002 13:17:13 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA26776; Fri, 26 Jul 2002 15:18:16 -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 PAA04146; Fri, 26 Jul 2002 15:18:16 -0500 (CDT) Subject: Fwd: Kernel not booting From: Eric Sandeen To: linux-xfs@oss.sgi.com Cc: bartimussuperbus@hotmail.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 26 Jul 2002 15:15:37 -0500 Message-Id: <1027714537.23229.212.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, please don't send HTML-only mail to the list, it will bounce. forwarding in case anyone can offer suggestions. -Eric -----Forwarded Message----- I installed Debian with a root XFS partition yesterday, but when I tried to compile a new kernel (to put in SMP support), the system wouldn't boot. It only got as far as "Uncompressing the kernel.... OK, booting Linux" then just hangs there. I then recompiled my kernel w/o any SMP support, and I still got the same message. Both the kernel that came on the disk and the one I'm trying to build for myself are 2.4.18 kernels. Any ideas on why my kernel should be hanging at start up? I've had the same machine for the last two years and have compiled at least a dozen kernels, so I know how to compile one with SMP support that boots fine. ------------------------------ -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Jul 26 14:05:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6QL52Rw020638 for ; Fri, 26 Jul 2002 14:05:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6QL52kO020637 for linux-xfs-outgoing; Fri, 26 Jul 2002 14:05:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bittersweet.intra.hegbloom.net (ns.hegbloom.net [63.105.27.231]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6QL4kRw020598 for ; Fri, 26 Jul 2002 14:04:47 -0700 Received: from bittersweet.intra.hegbloom.net (localhost.localnet [127.0.0.1]) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g6QL5scR009487 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 26 Jul 2002 14:05:55 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) id g6QL5sfF009484; Fri, 26 Jul 2002 14:05:54 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f To: Stephen Lord Cc: XFS Cc: EVMS Devel Subject: Re: "Invalid client ID" after system lockup and subsequent reset ? References: <1020201746.3216.27.camel@bittersweet> <3CCF122F.3030109@sgi.com> From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 26 Jul 2002 14:05:54 -0700 In-Reply-To: <3CCF122F.3030109@sgi.com> Message-ID: <873cu6p5cd.fsf@bittersweet.intra.hegbloom.net> Lines: 84 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephen Lord writes: > Karl M. Hegbloom wrote: > > >Several times I've had my SMP machine with EVMS and XFS filesystems lock > >up and need to be reset. After the reboot, sometimes filesystems won't > >mount (it tends to be the "/var" partition) and I must boot to single > >user mode. > > Note that the problem is a lockup that I suspect is SMP + EVMS + XFS(?) related. Since it only seems to happen when I am compiling software, thus, when there is a large amount of file system activity, I suspect there's a race condition someplace and a deadlock. When it happens, the "gkrellm" meter keeps running, and I can see there is some CPU activity. It seems like the system is running smoothly, quiescently, and all is fairly normal. The mouse pointer moves around, and I can still type in my editor. However, I cannot save the file I'm working on -- the editor blocks then. I cannot start another command in a terminal -- it blocks and never runs. I can use Alt-SysReq-F1 to snick down to a Linux VT, but cannot log in -- it blocks. The gnome desk guide that I keep in a panel drawer will display, but when I click on it, nothing seems to happen; it's blocked too. Tell me if I'm wrong, but it sounds like any file system activity is blocking someplace. That's why I suspect that there is a deadlock. I am running a Debian 2.4.18 kernel, with the EVMS and XFS patches supplied by Debian. I've upgraded those kernel-patch patches a few times, and the last build failed entirely due to the unaligned access bug. I don't have the version information for the patches in the currently running kernel, which runs fine unless I try to build software. (making it difficult to rebuild the kernel) Luckily it has never locked up like that during a Debian upgrade. > >When I attempt to mount the filesystem to cause the log replay, it > >refuses to do so, giving an error about an "invalid client id". I must > >then run "xfs_repair -L" on it to get the machine back online. > > > >What does that error mean, and is there a way to make it mount anyway > >and replay the log? > > > >How can I debug system lockups like that, so that I can give a > >meaningful and useful bug report? Will someone please work with me in > >private mail (or direct me to the relevant mailing list or > >documentation) and teach me how to debug the Linux kernel, to find > >lockups and such? > > ... and that I want to learn how I can DEBUG it -- can I set my system up so that if it happens, a debugger is run or at least I can cause a core dump? What do you folks do, as developers, to find out what's happening in cases like this? Will you please help me learn how to be of more assistance? I care about this more than about whether the darn thing locks up on me once in a while. > This sounds like a corrupted log, the question is, who is doing the > corruption here. Bad clientid means there was something in the log > which was not recognized. Since EVMS and XFS have not had a lot of > exposure with each other, I would suspect EVMS is not taking well to > the XFS log writes, they are variable in size, between 512 bytes and > 32K, and they can start on any 512 byte boundary. Not much else in > Linux does I/O like this, possibly EVMS is dropping part of the I/O. > > I would raise this on the evms mailing list as well as the xfs one, > we can then work out between us what is going on. > > Next time it happens, try xfs_logprint -t /dev/xxx before you mount > the filesystem. It might fail in a similar manner to the kernel > though. > > Steve -- As any limb well and duly exercised, grows stronger, the nerves of the body are corroborated thereby. --I. Watts. .''`. We are deB.ORG; You will be freed. : :' : `. `' From owner-linux-xfs@oss.sgi.com Fri Jul 26 15:34:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6QMYeRw021434 for ; Fri, 26 Jul 2002 15:34:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6QMYe4l021433 for linux-xfs-outgoing; Fri, 26 Jul 2002 15:34:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6QMYYRw021404 for ; Fri, 26 Jul 2002 15:34:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA24418 for ; Fri, 26 Jul 2002 17:35:40 -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 RAA83750 for ; Fri, 26 Jul 2002 17:35:40 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6QMX0631352; Fri, 26 Jul 2002 17:33:00 -0500 Message-Id: <200207262233.g6QMX0631352@stout.americas.sgi.com> Date: Fri, 26 Jul 2002 17:33:00 -0500 Subject: TAKE - 2.4 makefile cleanups X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk sync up with 2.5, remove unessecary exports makefile cleanups Date: Fri Jul 26 15:34:17 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123785a linux/fs/Makefile - 1.52 linux/fs/xfs/linux/Makefile - 1.57 linux/fs/xfs_dmapi/Makefile - 1.8 From owner-linux-xfs@oss.sgi.com Fri Jul 26 15:39:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6QMdZRw021633 for ; Fri, 26 Jul 2002 15:39:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6QMdZrQ021632 for linux-xfs-outgoing; Fri, 26 Jul 2002 15:39:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6QMdSRw021604 for ; Fri, 26 Jul 2002 15:39:28 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA29785 for ; Fri, 26 Jul 2002 17:40:34 -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 RAA70430 for ; Fri, 26 Jul 2002 17:40:34 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6QMbsn31492; Fri, 26 Jul 2002 17:37:54 -0500 Message-Id: <200207262237.g6QMbsn31492@stout.americas.sgi.com> Date: Fri, 26 Jul 2002 17:37:54 -0500 Subject: TAKE - remove unnecessary includes, ensure config.h X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS pulls in a bunch of unneeded include files, the worst offenders are smp_lock.h and locks.h (why?). Also include ontop of xfs.h to make sure we _always_ have it. remove unnecessary includes, ensure config.h Date: Fri Jul 26 15:39:53 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123787a linux/fs/xfs/linux/xfs_vfs.c - 1.37 linux/fs/xfs/linux/xfs_super.c - 1.200 linux/fs/xfs/linux/xfs_ioctl.c - 1.70 linux/fs/xfs/xfs.h - 1.29 linux/fs/xfs/linux/xfs_stats.c - 1.7 linux/fs/xfs/support/kmem.c - 1.14 linux/fs/xfs/support/ktrace.c - 1.10 linux/fs/xfs/linux/xfs_sysctl.c - 1.7 linux/fs/xfs/pagebuf/page_buf.h - 1.30 From owner-linux-xfs@oss.sgi.com Fri Jul 26 16:09:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6QN92Rw022561 for ; Fri, 26 Jul 2002 16:09:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6QN924L022560 for linux-xfs-outgoing; Fri, 26 Jul 2002 16:09:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6QN8rRw022532 for ; Fri, 26 Jul 2002 16:08:54 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla2.xs4all.nl (8.12.3/8.12.3) with ESMTP id g6QN9ubO099579; Sat, 27 Jul 2002 01:09:56 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g6QN9uM17789; Sat, 27 Jul 2002 01:09:56 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Sat, 27 Jul 2002 01:09:56 +0200 (CEST) From: Seth Mos To: "Karl M. Hegbloom" cc: Stephen Lord , XFS , EVMS Devel Subject: Re: "Invalid client ID" after system lockup and subsequent reset ? In-Reply-To: <873cu6p5cd.fsf@bittersweet.intra.hegbloom.net> Message-ID: <20020727010604.J17674-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 26 Jul 2002, Karl M. Hegbloom wrote: > Stephen Lord writes: > > > Karl M. Hegbloom wrote: > > > > >Several times I've had my SMP machine with EVMS and XFS filesystems lock > > >up and need to be reset. After the reboot, sometimes filesystems won't > > >mount (it tends to be the "/var" partition) and I must boot to single > > >user mode. > > > > > Note that the problem is a lockup that I suspect is SMP + EVMS + > XFS(?) related. Since it only seems to happen when I am compiling > software, thus, when there is a large amount of file system activity, > I suspect there's a race condition someplace and a deadlock. It can happen during mount and I have seen this only on the 1.0.2 release kernels and a squid cache on /var Only the 1.0.2 release kernel was able to create this behaviour. - File writes to /var would be impossible and squid could not be stopped anymore. - Recovery was needed because filesystem was not clean. - System hangs during mount. Clearing the log was enough to make it mount again. I saw this about 3 times. After upgrading to a later kernel I never saw the problem again. The problem was no present with earlier kernels either. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Jul 26 19:09:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6R29WRw023765 for ; Fri, 26 Jul 2002 19:09:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6R29WL3023764 for linux-xfs-outgoing; Fri, 26 Jul 2002 19:09:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bittersweet.intra.hegbloom.net (ns.hegbloom.net [63.105.27.231]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6R29RRw023735 for ; Fri, 26 Jul 2002 19:09:27 -0700 Received: from bittersweet.intra.hegbloom.net (localhost.localnet [127.0.0.1]) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g6R2AZcR017535 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 26 Jul 2002 19:10:35 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) id g6R2AWDo017529; Fri, 26 Jul 2002 19:10:32 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f To: Seth Mos Cc: Stephen Lord , XFS , EVMS Devel Subject: Re: "Invalid client ID" after system lockup and subsequent reset ? References: <20020727010604.J17674-100000@xs1.xs4all.nl> From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 26 Jul 2002 19:10:32 -0700 In-Reply-To: <20020727010604.J17674-100000@xs1.xs4all.nl> Message-ID: <87ofctkjjb.fsf@bittersweet.intra.hegbloom.net> Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos writes: > It can happen during mount and I have seen this only on the 1.0.2 > release kernels and a squid cache on /var Please clarify what you mean by "1.0.2 release kernels". Is that an EVMS version, or an XFS version? -- As any limb well and duly exercised, grows stronger, the nerves of the body are corroborated thereby. --I. Watts. .''`. We are deB.ORG; You will be freed. : :' : `. `' From owner-linux-xfs@oss.sgi.com Fri Jul 26 19:30:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6R2U9Rw024040 for ; Fri, 26 Jul 2002 19:30:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6R2U9Rl024039 for linux-xfs-outgoing; Fri, 26 Jul 2002 19:30:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6R2U1Rw024011 for ; Fri, 26 Jul 2002 19:30:01 -0700 Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by deliverator.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 TAA08067 for ; Fri, 26 Jul 2002 19:31:08 -0700 (PDT) mail_from (mdz@csh.rit.edu) Received: from 209-6-103-23.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.103.23] helo=mizar.alcor.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.35 #5) id 17YHEQ-0004zY-00; Fri, 26 Jul 2002 22:22:58 -0400 Received: from mdz by mizar.alcor.net with local (Exim 3.35 #1 (Debian)) id 17YHEM-0002pc-00; Fri, 26 Jul 2002 22:22:54 -0400 Date: Fri, 26 Jul 2002 22:22:54 -0400 From: Matt Zimmerman To: "Karl M. Hegbloom" Cc: Seth Mos , Stephen Lord , XFS , EVMS Devel Subject: Re: [Evms-devel] Re: "Invalid client ID" after system lockup and subsequent reset ? Message-ID: <20020727022254.GC9074@alcor.net> Mail-Followup-To: "Karl M. Hegbloom" , Seth Mos , Stephen Lord , XFS , EVMS Devel References: <20020727010604.J17674-100000@xs1.xs4all.nl> <87ofctkjjb.fsf@bittersweet.intra.hegbloom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ofctkjjb.fsf@bittersweet.intra.hegbloom.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jul 26, 2002 at 07:10:32PM -0700, Karl M. Hegbloom wrote: > Seth Mos writes: > > > It can happen during mount and I have seen this only on the 1.0.2 > > release kernels and a squid cache on /var > > Please clarify what you mean by "1.0.2 release kernels". Is that an > EVMS version, or an XFS version? XFS. There is no 1.0.2 EVMS version. -- - mdz From owner-linux-xfs@oss.sgi.com Sat Jul 27 07:16:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6REG5Rw008784 for ; Sat, 27 Jul 2002 07:16:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6REG4k6008781 for linux-xfs-outgoing; Sat, 27 Jul 2002 07:16:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6REFsRw008751 for ; Sat, 27 Jul 2002 07:15:59 -0700 Received: (from lord@localhost) by localhost.localdomain (8.11.6/8.11.6) id g6REEuU01581 for linux-xfs@oss.sgi.com; Sat, 27 Jul 2002 09:14:56 -0500 Date: Sat, 27 Jul 2002 09:14:56 -0500 From: Stephen Lord Message-Id: <200207271414.g6REEuU01581@localhost.localdomain> Subject: TAKE - simplify hole zeroing code in xfs To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This makes xfs_iozero work without pagebufs, this was the only non-metadata use of pagebufs. Date: Sat Jul 27 07:15:03 PDT 2002 Workarea: cf-vpn-sw-corp-64-20.corp.sgi.com:/home/lord/src/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:123789a linux/fs/xfs/linux/xfs_lrw.c - 1.162 From owner-linux-xfs@oss.sgi.com Sat Jul 27 07:25:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6REPWRw009112 for ; Sat, 27 Jul 2002 07:25:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6REPWbD009111 for linux-xfs-outgoing; Sat, 27 Jul 2002 07:25:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6REPLRw009083 for ; Sat, 27 Jul 2002 07:25:22 -0700 Received: (from lord@localhost) by localhost.localdomain (8.11.6/8.11.6) id g6REOSq01769 for linux-xfs@oss.sgi.com; Sat, 27 Jul 2002 09:24:28 -0500 Date: Sat, 27 Jul 2002 09:24:28 -0500 From: Stephen Lord Message-Id: <200207271424.g6REOSq01769@localhost.localdomain> Subject: TAKE - some code cleanup To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove some CELL_CAPABLE code, make the forced shutdown path into a VFS operation and some other minor cleanups. Date: Sat Jul 27 07:25:06 PDT 2002 Workarea: cf-vpn-sw-corp-64-20.corp.sgi.com:/home/lord/src/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:123790a linux/fs/xfs/xfs_rw.c - 1.361 - remove cell_capable code from forced shutdown path and change arguments to make it a work as a vfs function linux/fs/xfs/xfs_vnodeops.c - 1.546 - remove a cell_capable ifdef linux/fs/xfs/xfs_vfsops.c - 1.363 - no need for vfs_flags option in unmount path, initialize vfs_force_shutdown vfs op. linux/fs/xfs/xfs_mount.h - 1.153 - remove vfs flags argument from unmount path make forced shutdown call VFS_FORCE_SHUTDOWN linux/fs/xfs/xfs_mount.c - 1.293 - remove vfs flags argument from unmount path linux/fs/xfs/xfs_inode.h - 1.165 - remove irix specific pragma linux/fs/xfs/xfs_utils.h - 1.22 - remove some cell_capable function prototypes linux/fs/xfs/linux/xfs_linux.h - 1.81 - remove some unneeded defines, switch from extern inline to static inline for roundup_64. linux/fs/xfs/linux/xfs_vfs.h - 1.23 - make forced shutdown a vfs operation linux/fs/xfs/linux/xfs_behavior.h - 1.9 - remove some cell_capable code From owner-linux-xfs@oss.sgi.com Sat Jul 27 08:30:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6RFUeRw028789 for ; Sat, 27 Jul 2002 08:30:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RFUer2028788 for linux-xfs-outgoing; Sat, 27 Jul 2002 08:30:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RFUWRw028760 for ; Sat, 27 Jul 2002 08:30:33 -0700 Received: from [209.96.179.113] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 17YTXl-000BYi-00 for linux-xfs@oss.sgi.com; Sat, 27 Jul 2002 11:31:46 -0400 Received: from daydream.shannon.net (daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g6RFOh800990 for ; Sat, 27 Jul 2002 11:24:43 -0400 (EDT) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id g6RFOhpW009989 for ; Sat, 27 Jul 2002 11:24:43 -0400 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id g6RFOhW2009988 for linux-xfs@oss.sgi.com; Sat, 27 Jul 2002 11:24:43 -0400 Date: Sat, 27 Jul 2002 11:24:43 -0400 From: Charles Shannon Hendrix To: linux-xfs Subject: Re: logdev on IDE Message-ID: <20020727152441.GA9977@widomaker.com> Mail-Followup-To: linux-xfs References: <1027535026.1648.5.camel@stantz.corp.sgi.com> <1027535678.14036.28.camel@stout.americas.sgi.com> <1027539660.1648.11.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1027539660.1648.11.camel@stantz.corp.sgi.com> User-Agent: Mutt/1.3.99i X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,ASCII_FORM_ENTRY version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jul 24, 2002 at 12:40:59PM -0700, Florin Andrei wrote: > Indeed, that would be a problem. > Anyway, some generous souls just gave me an external SCSI drive, so the > case for the IDE is closed. ;-) > > But, for future refference, is there a way to tell if an IDE drive is > doing bad things? I mean, other than pressing Reset repeatedly... > Or perhaps someone put up a list of good/bad IDE drives, in regard to > the caching problem... > I guess this should be interesting for anyone using a journalised FS. Some IDE drives lie about things like write-cache and the ordering of writes. For example, you can issue the command to turn write-cache off, but it doesn't really happen. Likewise, an IDE drive may report it has written a block of data, but it hasn't, meaning you can't garantee write ordering. I wish hard drive reviews would include information like this. I have heard that things like the IBM Ultrastar and Seagate Barracuda are fully compliant with all commands, but have never tried to test the theory. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Sat Jul 27 09:13:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6RGDXRw000739 for ; Sat, 27 Jul 2002 09:13:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RGDWWj000738 for linux-xfs-outgoing; Sat, 27 Jul 2002 09:13:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sweeney.demon.co.uk (sweeney.demon.co.uk [158.152.71.87]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RGDDRw032189 for ; Sat, 27 Jul 2002 09:13:25 -0700 Received: from opuntia (opuntia.sweeney.demon.co.uk [10.0.0.4]) by sweeney.demon.co.uk (Postfix) with SMTP id 06D8616FEF for ; Sat, 27 Jul 2002 17:13:47 +0100 (BST) Date: Sat, 27 Jul 2002 17:22:00 +0100 From: Keith Matthews To: Subject: Re: logdev on IDE Message-Id: <20020727172200.0d9e5c54.keith_m@sweeney.demon.co.uk> In-Reply-To: <20020727152441.GA9977@widomaker.com> References: <1027535026.1648.5.camel@stantz.corp.sgi.com> <1027535678.14036.28.camel@stout.americas.sgi.com> <1027539660.1648.11.camel@stantz.corp.sgi.com> <20020727152441.GA9977@widomaker.com> X-Mailer: Sylpheed version 0.7.8 (GTK+ 1.2.8; i586-pc-linux-gnu) X-no-archive: yes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 27 Jul 2002 11:24:43 -0400 "Charles Shannon Hendrix" wrote: > Some IDE drives lie about things like write-cache and the ordering of > writes. For example, you can issue the command to turn write-cache > off, but it doesn't really happen. > > Likewise, an IDE drive may report it has written a block of data, but > it hasn't, meaning you can't garantee write ordering. > > I wish hard drive reviews would include information like this. I have > heard that things like the IBM Ultrastar and Seagate Barracuda are > fully compliant with all commands, but have never tried to test the > theory. > I understand that this was through a hole in the ATA spec that was closed about 6 months ago. I have no idea if there are any drives to the old spec still in the supply chain, but those currently being manufactured are probably OK. From owner-linux-xfs@oss.sgi.com Sat Jul 27 15:03:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6RM3PRw015077 for ; Sat, 27 Jul 2002 15:03:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RM3POC015076 for linux-xfs-outgoing; Sat, 27 Jul 2002 15:03:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bittersweet.intra.hegbloom.net (ns.hegbloom.net [63.105.27.231]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RM3IRw015048 for ; Sat, 27 Jul 2002 15:03:19 -0700 Received: from bittersweet.intra.hegbloom.net (localhost.localnet [127.0.0.1]) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g6RM4UcR025868 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Sat, 27 Jul 2002 15:04:31 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) id g6RM4UUe025865; Sat, 27 Jul 2002 15:04:30 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f To: Seth Mos Cc: Stephen Lord , XFS , EVMS Devel Subject: Re: [Evms-devel] Re: "Invalid client ID" after system lockup and subsequent reset ? References: <20020727010604.J17674-100000@xs1.xs4all.nl> From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 27 Jul 2002 15:04:30 -0700 In-Reply-To: <20020727010604.J17674-100000@xs1.xs4all.nl> Message-ID: <8765z0kett.fsf@bittersweet.intra.hegbloom.net> Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos writes: > Clearing the log was enough to make it mount again. > I saw this about 3 times. After upgrading to a later kernel I never saw > the problem again. The problem was no present with earlier kernels > either. Do you use EVMS? -- As any limb well and duly exercised, grows stronger, the nerves of the body are corroborated thereby. --I. Watts. .''`. We are deB.ORG; You will be freed. : :' : `. `' From owner-linux-xfs@oss.sgi.com Sat Jul 27 15:19:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6RMJLRw015324 for ; Sat, 27 Jul 2002 15:19:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RMJAdo015317 for linux-xfs-outgoing; Sat, 27 Jul 2002 15:19:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RMIwRw015286 for ; Sat, 27 Jul 2002 15:19:04 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA32356 for ; Sat, 27 Jul 2002 17:20:03 -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 RAA87609 for ; Sat, 27 Jul 2002 17:20:03 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6RMHEZ07840; Sat, 27 Jul 2002 17:17:14 -0500 Message-Id: <200207272217.g6RMHEZ07840@stout.americas.sgi.com> Date: Sat, 27 Jul 2002 17:17:14 -0500 Subject: TAKE - clean up vmalloc'd memory handling X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk v2 logs with logbsize > 64k were failing, because xfs vmalloc'd these, and pagebuf subsequently used virt_to_page on them, which is only valid for kmalloc'd memory. New inline f'n mem_to_page() which does the right thing after testing for vmalloc'd memory. Also clean up kmem_free to make the vfree/kfree choice in the same manner as above; a bit more direct than it was. Date: Sat Jul 27 15:16:05 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123793a linux/fs/xfs/support/kmem.c - 1.15 - Use more direct test for vfree vs. kfree in kmem_free linux/fs/xfs/pagebuf/page_buf.c - 1.46 - Add mem_to_page() so we can get pages from vmalloc'd memory as well change virt_to_page to use mem_to_page From owner-linux-xfs@oss.sgi.com Sat Jul 27 15:20:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6RMKfRw015413 for ; Sat, 27 Jul 2002 15:20:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RMKd89015412 for linux-xfs-outgoing; Sat, 27 Jul 2002 15:20:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RMKWRw015384 for ; Sat, 27 Jul 2002 15:20:33 -0700 Received: from idcomm.com (IDENT:7wWAh4G2Kan5pt8Ue9uEpG5INnSKM2d7@tnt01-ppp-037.idcomm.com [216.98.194.37]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g6RMLjw04980 for ; Sat, 27 Jul 2002 16:21:45 -0600 Message-ID: <3D431D22.6030400@idcomm.com> Date: Sat, 27 Jul 2002 16:22:26 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: 2.4.19rc2 XFS oops trace Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Additional note on the oops trace I just sent. Here is an excerpt of mm/page_alloc.c, the "Bug" output marked for line 91: static void FASTCALL(__free_pages_ok (struct page *page, unsigned int order)); static void __free_pages_ok (struct page *page, unsigned int order) { unsigned long index, page_idx, mask, flags; free_area_t *area; struct page *base; zone_t *zone; /* Yes, think what happens when other parts of the kernel take * a reference to a page in order to pin it for io. -ben */ if (PageLRU(page)) lru_cache_del(page); if (page->buffers) BUG(); if (page->mapping) line 91 HERE-> BUG(); // LINE 91, oops "bug" output. if (!VALID_PAGE(page)) BUG(); if (PageLocked(page)) BUG(); if (PageActive(page)) BUG(); page->flags &= ~((1<; Sat, 27 Jul 2002 15:27:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RMRA2a015543 for linux-xfs-outgoing; Sat, 27 Jul 2002 15:27:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RMQqRw015511 for ; Sat, 27 Jul 2002 15:26:54 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by deliverator.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 PAA00752 for ; Sat, 27 Jul 2002 15:27:59 -0700 (PDT) mail_from (stimits@idcomm.com) Received: from idcomm.com (IDENT:7+paFQ8aGJS/GY2vJ+Z1XMhUHPHEz+Vr@tnt01-ppp-037.idcomm.com [216.98.194.37]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g6RMBBw03347 for ; Sat, 27 Jul 2002 16:11:11 -0600 Message-ID: <3D431AA8.4010306@idcomm.com> Date: Sat, 27 Jul 2002 16:11:52 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: 2.4.19rc2 XFS oops trace Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.4 required=5.0 tests=MAY_BE_FORGED,PORN_10 version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The oops being reported was not fatal, the machine continued to run fine. The only reason I noticed it is because I run tail -f on /var/log/messages whenever the modem is up. I do not know if this is related to XFS or not, perhaps someone could tell me if this needs to go elsewhere. The machine is SMP i840 chipset, the kernel is XFS cvs from a few weeks ago, 2.4.19 rc2. It uses aic7xxx module for scsi on its main drive (integrated U160 single channel controller on the motherboard), but also has IDE present (not mounted). I am in the process of building up on ext2 for transfer to XFS shortly. The current root partition is ext2, and one mounted partition is XFS, but was not being read at the time. Based on Redhat 7.3. One thing you will see in the trace that I found quite odd, it was looking for aic7xxx.o in /lib/. This is a module and it is present in the /lib/modules/`uname -r`/kernel/drivers/scsi/aic7xxx/ directory. Inserted modules: # lsmod Module Size Used by Tainted: P ppp_deflate 44064 1 (autoclean) ppp_async 8352 1 (autoclean) ppp_generic 23084 3 (autoclean) [ppp_deflate ppp_async] slhc 5884 1 (autoclean) [ppp_generic] emu10k1 66400 0 (autoclean) sound 72620 0 (autoclean) [emu10k1] ac97_codec 12224 0 (autoclean) [emu10k1] soundcore 6596 7 (autoclean) [emu10k1 sound] agpgart 22272 3 (autoclean) NVdriver 1066080 10 (autoclean) binfmt_misc 7524 1 parport_pc 25128 1 (autoclean) lp 7424 0 (autoclean) parport 38720 1 (autoclean) [parport_pc lp] ipchains 52552 103 md 63776 0 (unused) aic7xxx 146112 4 TRACE command (oops was saved to oops.txt): ksymoops -v \ /boot/vmlinux-2.4.19-rc2-xfs-1 \ -m /boot/System.map-2.4.19-rc2-xfs-1 oops.txt TRACE output: ksymoops 2.4.4 on i686 2.4.19-rc2-xfs-1. Options used -v /boot/vmlinux-2.4.19-rc2-xfs-1 (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.19-rc2-xfs-1/ (default) -m /boot/System.map-2.4.19-rc2-xfs-1 (specified) Error (expand_objects): cannot stat(/lib/aic7xxx.o) for aic7xxx ksymoops: No such file or directory kernel: kernel BUG at page_alloc.c:91! kernel: invalid operand: 0000 kernel: CPU: 1 kernel: EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 kernel: EFLAGS: 00013282 kernel: eax: c115c074 ebx: c120c268 ecx: c120c268 edx: c03987dc kernel: esi: c120c268 edi: 0000001e ebp: 00000000 esp: cff2bf10 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process kswapd (pid: 5, stackpage=cff2b000) kernel: Stack: 00000000 c120c268 0000001e 000001f7 c013e6a5 c120c268 000001d0 0000001e kernel: 000001f7 c013ca2a 00000000 c120c268 c01330c0 c0134158 c0133109 00000020 kernel: 000001d0 00000020 00000006 c12cf440 cff2ec00 000013a3 000001d0 c0398974 kernel: Call Trace: [] [] [] [] [] kernel: [] [] [] [] [] [] kernel: [] kernel: Code: 0f 0b 5b 00 42 06 2c c0 89 d8 2b 05 70 db 41 c0 69 c0 a3 8b >>EIP; c01338dd <__free_pages_ok+2d/264> <===== Trace; c013e6a5 Trace; c013ca2a Trace; c01330c0 Trace; c0134158 <__free_pages+1c/20> Trace; c0133109 Trace; c0133367 Trace; c01333d1 Trace; c013347f Trace; c01334ee Trace; c0133607 Trace; c0105000 <_stext+0/0> Trace; c01072db Code; c01338dd <__free_pages_ok+2d/264> 00000000 <_EIP>: Code; c01338dd <__free_pages_ok+2d/264> <===== 0: 0f 0b ud2a <===== Code; c01338df <__free_pages_ok+2f/264> 2: 5b pop %ebx Code; c01338e0 <__free_pages_ok+30/264> 3: 00 42 06 add %al,0x6(%edx) Code; c01338e3 <__free_pages_ok+33/264> 6: 2c c0 sub $0xc0,%al Code; c01338e5 <__free_pages_ok+35/264> 8: 89 d8 mov %ebx,%eax Code; c01338e7 <__free_pages_ok+37/264> a: 2b 05 70 db 41 c0 sub 0xc041db70,%eax Code; c01338ed <__free_pages_ok+3d/264> 10: 69 c0 a3 8b 00 00 imul $0x8ba3,%eax,%eax 1 error issued. Results may not be reliable. D. Stimits, stimits @ idcomm.com From owner-linux-xfs@oss.sgi.com Sat Jul 27 15:37:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6RMbPRw015826 for ; Sat, 27 Jul 2002 15:37:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RMbFSs015824 for linux-xfs-outgoing; Sat, 27 Jul 2002 15:37:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RMb5Rw015796 for ; Sat, 27 Jul 2002 15:37:08 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g6RMc8qr002269; Sun, 28 Jul 2002 00:38:08 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g6RMc8O60286; Sun, 28 Jul 2002 00:38:08 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Sun, 28 Jul 2002 00:38:08 +0200 (CEST) From: Seth Mos To: "Karl M. Hegbloom" cc: Stephen Lord , XFS , EVMS Devel Subject: Re: "Invalid client ID" after system lockup and subsequent reset ? In-Reply-To: <87ofctkjjb.fsf@bittersweet.intra.hegbloom.net> Message-ID: <20020728003713.B60206-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 26 Jul 2002, Karl M. Hegbloom wrote: > Seth Mos writes: > > > It can happen during mount and I have seen this only on the 1.0.2 > > release kernels and a squid cache on /var > > Please clarify what you mean by "1.0.2 release kernels". Is that an > EVMS version, or an XFS version? XFS release, sorry. I didn't saw I was crossposting. Cheers Seth From owner-linux-xfs@oss.sgi.com Sat Jul 27 15:43:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6RMhWRw016001 for ; Sat, 27 Jul 2002 15:43:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RMhHCd016000 for linux-xfs-outgoing; Sat, 27 Jul 2002 15:43:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RMgxRw015966 for ; Sat, 27 Jul 2002 15:43:09 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g6RMi6qr003153; Sun, 28 Jul 2002 00:44:07 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g6RMi6l60439; Sun, 28 Jul 2002 00:44:06 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Sun, 28 Jul 2002 00:44:06 +0200 (CEST) From: Seth Mos To: "Karl M. Hegbloom" cc: Stephen Lord , XFS , EVMS Devel Subject: Re: [Evms-devel] Re: "Invalid client ID" after system lockup and subsequent reset ? In-Reply-To: <8765z0kett.fsf@bittersweet.intra.hegbloom.net> Message-ID: <20020728004219.K60206-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 27 Jul 2002, Karl M. Hegbloom wrote: > Seth Mos writes: > > > Clearing the log was enough to make it mount again. > > I saw this about 3 times. After upgrading to a later kernel I never saw > > the problem again. The problem was no present with earlier kernels > > either. > > Do you use EVMS? No but the issue was that playing back recovery from the low was hanging. If I understand correctly EVMS is a layer underneath the filessytem and this could mean that there is something in the log which the recovery code has a tough time with. Cheers Seth From owner-linux-xfs@oss.sgi.com Sat Jul 27 15:52:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6RMq3Rw016256 for ; Sat, 27 Jul 2002 15:52:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RMpvI8016255 for linux-xfs-outgoing; Sat, 27 Jul 2002 15:51:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RMpiRw016224 for ; Sat, 27 Jul 2002 15:51:46 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17YaQi-0005JP-00; Sat, 27 Jul 2002 23:52:56 +0100 Date: Sat, 27 Jul 2002 23:52:56 +0100 From: Christoph Hellwig To: "D. Stimits" Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: 2.4.19rc2 XFS oops trace Message-ID: <20020727235256.A20207@infradead.org> References: <3D431AA8.4010306@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D431AA8.4010306@idcomm.com>; from stimits@idcomm.com on Sat, Jul 27, 2002 at 04:11:52PM -0600 X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Jul 27, 2002 at 04:11:52PM -0600, D. Stimits wrote: > I do not know if this is related to XFS or not, perhaps someone could > tell me if this needs to go elsewhere. You have nvidia's binary-only driver loaded and this is the typical nvidia oops. We get this reports about one time all two weeks on this list :P Steve, Eric, what do you think about installing the following patch (adopted from Red Hat rawhide) in CVS? --- linux/mm/page_alloc.c~ Thu Jul 4 16:33:28 2002 +++ linux/mm/page_alloc.c Thu Jul 4 16:33:28 2002 @@ -123,8 +123,12 @@ return; if (page->buffers) BUG(); - if (page->mapping) + if (page->mapping) { + printk(KERN_CRIT "Page has mapping still set. This is a serious situation. However if you \n"); + printk(KERN_CRIT "are using the NVidia binary only module please report this bug to \n"); + printk(KERN_CRIT "NVidia and not to the linux-xfs or linux kernel mailinglists.\n"); BUG(); + } if (!VALID_PAGE(page)) BUG(); if (PageSwapCache(page)) From owner-linux-xfs@oss.sgi.com Sat Jul 27 16:28:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6RNSuRw016806 for ; Sat, 27 Jul 2002 16:28:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6RNSpXQ016805 for linux-xfs-outgoing; Sat, 27 Jul 2002 16:28:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6RNSgRw016777 for ; Sat, 27 Jul 2002 16:28:43 -0700 Received: from idcomm.com (IDENT:+YDxLFOo6nhbk6RI46GdRaYUgWMWh0Xy@tnt01-ppp-234.idcomm.com [216.98.194.234]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g6RNTtw15284 for ; Sat, 27 Jul 2002 17:29:55 -0600 Message-ID: <3D432D1E.3090907@idcomm.com> Date: Sat, 27 Jul 2002 17:30:38 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: 2.4.19rc2 XFS oops trace References: <3D431D22.6030400@idcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk D. Stimits wrote: > Additional note on the oops trace I just sent. Here is an excerpt of > mm/page_alloc.c, the "Bug" output marked for line 91: > static void FASTCALL(__free_pages_ok (struct page *page, unsigned int > order)); > static void __free_pages_ok (struct page *page, unsigned int order) > { > unsigned long index, page_idx, mask, flags; > free_area_t *area; > struct page *base; > zone_t *zone; > > /* Yes, think what happens when other parts of the kernel take > * a reference to a page in order to pin it for io. -ben > */ > if (PageLRU(page)) > lru_cache_del(page); > > if (page->buffers) > BUG(); > if (page->mapping) > line 91 HERE-> BUG(); // LINE 91, oops "bug" output. > if (!VALID_PAGE(page)) > BUG(); > if (PageLocked(page)) > BUG(); > if (PageActive(page)) > BUG(); > page->flags &= ~((1< > > D. Stimits, stimits @ idcomm.com > > > One more note, kernel was compiled with kgcc. Also, upon shutdown, it hung trying to umount swap. D. Stimits, stimits @ idcomm.com From owner-linux-xfs@oss.sgi.com Sun Jul 28 01:14:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6S8E2Rw021556 for ; Sun, 28 Jul 2002 01:14:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6S8E2GP021555 for linux-xfs-outgoing; Sun, 28 Jul 2002 01:14:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6S8DrRw021525 for ; Sun, 28 Jul 2002 01:13:53 -0700 Received: from erbenson.alaska.net (5-pm5.nwc.alaska.net [209.112.139.5]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g6S8F2o08836; Sun, 28 Jul 2002 00:15:02 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 7280F3A18; Sun, 28 Jul 2002 00:14:56 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 3D67D10293; Sun, 28 Jul 2002 00:14:56 -0800 (AKDT) Date: Sun, 28 Jul 2002 00:14:56 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com, debian-powerpc@lists.debian.org Subject: XFS enabled Debian 3.0 powerpc installer Message-ID: <20020728001456.B1367@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com, debian-powerpc@lists.debian.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have built a set of XFS enabled Debian boot-floppies for PowerPC. Note that only the `new-powermac' flavor is supported (which pretty much means only NewWorld PowerMacs are supported). I also provide a mini bootable CDROM iso. Please see http://penguinppc.org/~eb/files/XFS-debian-README.txt for more information. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj1DqAAACgkQJKx7GixEevyvYACeMQhzRelx9LdnBq0s6bUkb1r7 klQAn3LsnURlZwIEEeGA3TataXSg4hIu =0aOC -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI-- From owner-linux-xfs@oss.sgi.com Sun Jul 28 01:25:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6S8PERw021766 for ; Sun, 28 Jul 2002 01:25:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6S8PCZ6021765 for linux-xfs-outgoing; Sun, 28 Jul 2002 01:25:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6S8OiRw021735 for ; Sun, 28 Jul 2002 01:24:45 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id DE044C01886; Sun, 28 Jul 2002 16:25:52 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 8C6A5C0186B; Sun, 28 Jul 2002 16:25:42 +0800 (PHT) Date: Sun, 28 Jul 2002 16:25:42 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List , Linux Kernel Mailing List Subject: Kernel BUG at page_alloc.c:91 (2.4.19-rc2-xfs) Message-ID: <20020728082542.GC1265@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List , Linux Kernel Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everyone, I apologize for sending this to both the Linux kernel mailing list as well as the Linux-XFS mailing list. I am sending this to the lkml because it's a kernel bug report. I'm sending this to the Linux-XFS mailing list because I do not know if "try_to_free_buffers+130/240" in the Call Trace has anything to do with changes that the XFS team has done on the Linux kernel. I got kernel BUG reports in my system logs[1] and dmesg[2] four times today. The first time it happened with process kswapd, the second with process httpd (of Apache), the third and fourth with ssh which I was firing up through wterm. They happened all within a fairly short period of time: the first at 16:02:05, the second at the same time, the third at 16:03:51 and the fourth at 16:03:53. I am running Linux kernel 2.4.19-rc2-xfs (CVS snapshot 20020718), compiled using the current gcc-3.1 Debian packages from Sid (gcc version 3.1.1 20020703 (Debian prerelease) according to `gcc-3.1 -v`), on an AMD Duron/850MHz. This system has been running continuously using this kernel for 7 days 22:13, according to uptime. I didn't do anything special this afternoon when all four kernel BUG incidences occured. Would any of the kernel or XFS developers want me to do anything to perhaps help debug this situation? I intend to move this system up to 2.4.19-rc3-xfs (CVS snapshot as of today), otherwise. Thanks a lot in advance. --> Jijo [1] Kernel BUG reports from syslog (with timestamps and slightly different call trace information): Jul 28 16:02:05 lawin kernel: kernel BUG at page_alloc.c:91! Jul 28 16:02:05 lawin kernel: invalid operand: 0000 Jul 28 16:02:05 lawin kernel: CPU: 0 Jul 28 16:02:05 lawin kernel: EIP: 0010:[__free_pages_ok+45/608] Tainted: P Jul 28 16:02:05 lawin kernel: EFLAGS: 00210282 Jul 28 16:02:05 lawin kernel: eax: c11c90fc ebx: c11c73d4 ecx: 00000000 edx: c0333f40 Jul 28 16:02:05 lawin kernel: esi: 00000000 edi: 000011b9 ebp: c0334050 esp: c12f3f08 Jul 28 16:02:05 lawin kernel: ds: 0018 es: 0018 ss: 0018 Jul 28 16:02:05 lawin kernel: Process kswapd (pid: 5, stackpage=c12f3000) Jul 28 16:02:05 lawin kernel: Stack: 00000001 00200282 00000003 cf0dc8c0 cf0dc8c0 cf0dc8c0 c11c73d4 c013f0e2 Jul 28 16:02:05 lawin kernel: cf0dc8c0 c0333f40 c11c73d4 000011b9 c0334050 c0134852 c11c73d4 000001d0 Jul 28 16:02:05 lawin kernel: c12f2000 000001c7 000001d0 00000002 0000001f 000001d0 00000020 00000006 Jul 28 16:02:05 lawin kernel: Call Trace: [try_to_free_buffers+130/240] [shrink_cache+642/784] [shrink_caches+97/160] [try_to_free_pages+54/96 ] [kswapd_balance_pgdat+86/160] Jul 28 16:02:05 lawin kernel: [kswapd_balance+24/48] [kswapd+157/192] [rest_init+0/64] [kernel_thread+46/64] [kswapd+0/192] Jul 28 16:02:05 lawin kernel: Jul 28 16:02:05 lawin kernel: Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 Jul 28 16:02:05 lawin kernel: kernel BUG at page_alloc.c:91! Jul 28 16:02:05 lawin kernel: invalid operand: 0000 Jul 28 16:02:05 lawin kernel: CPU: 0 Jul 28 16:02:05 lawin kernel: EIP: 0010:[__free_pages_ok+45/608] Tainted: P Jul 28 16:02:05 lawin kernel: EFLAGS: 00210282 Jul 28 16:02:05 lawin kernel: eax: c11ee984 ebx: c1261cc4 ecx: 00000000 edx: c0333f40 Jul 28 16:02:05 lawin kernel: esi: 00000000 edi: 00001232 ebp: c0334050 esp: c72bddc0 Jul 28 16:02:05 lawin kernel: ds: 0018 es: 0018 ss: 0018 Jul 28 16:02:05 lawin kernel: Process http (pid: 14620, stackpage=c72bd000) Jul 28 16:02:05 lawin kernel: Stack: 00000001 00200282 00000003 cf0dc3c0 cf0dc3c0 cf0dc3c0 c1261cc4 c013f0e2 Jul 28 16:02:05 lawin kernel: cf0dc3c0 c0333f40 c1261cc4 00001232 c0334050 c0134852 c1261cc4 000001d2 Jul 28 16:02:05 lawin kernel: c72bc000 000001d1 000001d2 00000020 0000001e 000001d2 00000020 00000006 Jul 28 16:02:05 lawin kernel: Call Trace: [try_to_free_buffers+130/240] [shrink_cache+642/784] [shrink_caches+97/160] [try_to_free_pages+54/96 ] [balance_classzone+87/448] Jul 28 16:02:06 lawin kernel: [__alloc_pages+237/400] [do_generic_file_write+818/1760] [ip_local_deliver+77/112] [xfs_write+591/2144] [ip_r cv_finish+0/544] [linvfs_write+228/288] Jul 28 16:02:06 lawin kernel: [sys_write+163/304] [system_call+51/56] Jul 28 16:02:06 lawin kernel: Jul 28 16:02:06 lawin kernel: Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 Jul 28 16:03:51 lawin kernel: kernel BUG at page_alloc.c:91! Jul 28 16:03:51 lawin kernel: invalid operand: 0000 Jul 28 16:03:51 lawin kernel: CPU: 0 Jul 28 16:03:51 lawin kernel: EIP: 0010:[__free_pages_ok+45/608] Tainted: P Jul 28 16:03:51 lawin kernel: EFLAGS: 00210282 Jul 28 16:03:51 lawin kernel: eax: c128cef4 ebx: c1209ea8 ecx: 00000000 edx: c0333f40 Jul 28 16:03:51 lawin kernel: esi: 00000000 edi: 00001234 ebp: c0334050 esp: cd2ffdec Jul 28 16:03:51 lawin kernel: ds: 0018 es: 0018 ss: 0018 Jul 28 16:03:51 lawin kernel: Process ssh (pid: 14631, stackpage=cd2ff000) Jul 28 16:03:51 lawin kernel: Stack: 00000001 00200282 00000003 cf0dc340 cf0dc340 cf0dc340 c1209ea8 c013f0e2 Jul 28 16:03:51 lawin kernel: cf0dc340 c0333f40 c1209ea8 00001234 c0334050 c0134852 c1209ea8 000001d2 Jul 28 16:03:51 lawin kernel: cd2fe000 000001d2 000001d2 00000020 0000001f 000001d2 00000020 00000006 Jul 28 16:03:51 lawin kernel: Call Trace: [try_to_free_buffers+130/240] [shrink_cache+642/784] [shrink_caches+97/160] [try_to_free_pages+54/96 ] [balance_classzone+87/448] Jul 28 16:03:51 lawin kernel: [__alloc_pages+237/400] [do_anonymous_page+104/240] [handle_mm_fault+119/272] [do_page_fault+350/1257] [via68 6a:__insmod_via686a_O/lib/modules/2.4.19-rc2-xfs/misc/via686a.+-156672/96] [via686a:__insmod_via686a_O/lib/modules/2.4.19-rc2-xfs/misc/via686a .+-156672/96] Jul 28 16:03:51 lawin kernel: [via686a:__insmod_via686a_O/lib/modules/2.4.19-rc2-xfs/misc/via686a.+-965242/96] [do_brk+280/528] [sys_brk+26 4/320] [do_page_fault+0/1257] [error_code+52/60] Jul 28 16:03:51 lawin kernel: Jul 28 16:03:51 lawin kernel: Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 Jul 28 16:03:53 lawin kernel: kernel BUG at page_alloc.c:91! Jul 28 16:03:53 lawin kernel: invalid operand: 0000 Jul 28 16:03:53 lawin kernel: CPU: 0 Jul 28 16:03:53 lawin kernel: EIP: 0010:[__free_pages_ok+45/608] Tainted: P Jul 28 16:03:53 lawin kernel: EFLAGS: 00210282 Jul 28 16:03:53 lawin kernel: eax: c12987b8 ebx: c10b9ba8 ecx: 00000000 edx: c0333f40 Jul 28 16:03:53 lawin kernel: esi: 00000000 edi: 00001235 ebp: c0334050 esp: cd2ffdd0 Jul 28 16:03:53 lawin kernel: ds: 0018 es: 0018 ss: 0018 Jul 28 16:03:53 lawin kernel: Process ssh (pid: 14633, stackpage=cd2ff000) Jul 28 16:03:53 lawin kernel: Stack: 00000001 00200282 00000003 cf0dc1c0 cf0dc1c0 cf0dc1c0 c10b9ba8 c013f0e2 Jul 28 16:03:53 lawin kernel: cf0dc1c0 c0333f40 c10b9ba8 00001235 c0334050 c0134852 c10b9ba8 000001d2 Jul 28 16:03:53 lawin kernel: cd2fe000 000001d2 000001d2 0000001f 00000020 000001d2 00000020 00000006 Jul 28 16:03:53 lawin kernel: Call Trace: [try_to_free_buffers+130/240] [shrink_cache+642/784] [shrink_caches+97/160] [try_to_free_pages+54/96 ] [balance_classzone+87/448] Jul 28 16:03:53 lawin kernel: [__alloc_pages+237/400] [do_no_page+257/432] [handle_mm_fault+119/272] [do_page_fault+350/1257] [old_mmap+257 /288] [filp_close+77/128] Jul 28 16:03:53 lawin kernel: [do_page_fault+0/1257] [error_code+52/60] Jul 28 16:03:53 lawin kernel: Jul 28 16:03:53 lawin kernel: Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 [2] Kernel BUG reports from dmesg (no timestamps): kernel BUG at page_alloc.c:91! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00210282 eax: c11c90fc ebx: c11c73d4 ecx: 00000000 edx: c0333f40 esi: 00000000 edi: 000011b9 ebp: c0334050 esp: c12f3f08 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=c12f3000) Stack: 00000001 00200282 00000003 cf0dc8c0 cf0dc8c0 cf0dc8c0 c11c73d4 c013f0e2 cf0dc8c0 c0333f40 c11c73d4 000011b9 c0334050 c0134852 c11c73d4 000001d0 c12f2000 000001c7 000001d0 00000002 0000001f 000001d0 00000020 00000006 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 kernel BUG at page_alloc.c:91! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00210282 eax: c11ee984 ebx: c1261cc4 ecx: 00000000 edx: c0333f40 esi: 00000000 edi: 00001232 ebp: c0334050 esp: c72bddc0 ds: 0018 es: 0018 ss: 0018 Process http (pid: 14620, stackpage=c72bd000) Stack: 00000001 00200282 00000003 cf0dc3c0 cf0dc3c0 cf0dc3c0 c1261cc4 c013f0e2 cf0dc3c0 c0333f40 c1261cc4 00001232 c0334050 c0134852 c1261cc4 000001d2 c72bc000 000001d1 000001d2 00000020 0000001e 000001d2 00000020 00000006 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 kernel BUG at page_alloc.c:91! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00210282 eax: c128cef4 ebx: c1209ea8 ecx: 00000000 edx: c0333f40 esi: 00000000 edi: 00001234 ebp: c0334050 esp: cd2ffdec ds: 0018 es: 0018 ss: 0018 Process ssh (pid: 14631, stackpage=cd2ff000) Stack: 00000001 00200282 00000003 cf0dc340 cf0dc340 cf0dc340 c1209ea8 c013f0e2 cf0dc340 c0333f40 c1209ea8 00001234 c0334050 c0134852 c1209ea8 000001d2 cd2fe000 000001d2 000001d2 00000020 0000001f 000001d2 00000020 00000006 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 kernel BUG at page_alloc.c:91! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00210282 eax: c12987b8 ebx: c10b9ba8 ecx: 00000000 edx: c0333f40 esi: 00000000 edi: 00001235 ebp: c0334050 esp: cd2ffdd0 ds: 0018 es: 0018 ss: 0018 Process ssh (pid: 14633, stackpage=cd2ff000) Stack: 00000001 00200282 00000003 cf0dc1c0 cf0dc1c0 cf0dc1c0 c10b9ba8 c013f0e2 cf0dc1c0 c0333f40 c10b9ba8 00001235 c0334050 c0134852 c10b9ba8 000001d2 cd2fe000 000001d2 000001d2 0000001f 00000020 000001d2 00000020 00000006 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Sun Jul 28 02:05:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6S95MRw022217 for ; Sun, 28 Jul 2002 02:05:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6S95LMP022216 for linux-xfs-outgoing; Sun, 28 Jul 2002 02:05:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.broadpark.no (217-13-4-9.dd.nextgentel.com [217.13.4.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6S95ERw022164 for ; Sun, 28 Jul 2002 02:05:16 -0700 Received: from broadpark.no (213-187-174-20.dd.nextgentel.com [213.187.174.20]) by mail.broadpark.no (Postfix) with ESMTP id EB2127D80 for ; Sun, 28 Jul 2002 11:06:19 +0200 (MEST) Message-ID: <3D43B40B.1010003@broadpark.no> Date: Sun, 28 Jul 2002 11:06:19 +0200 From: Kjell Randa User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.19rc2 XFS oops trace Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Jul 27, 2002 at 04:11:52PM -0600, D. Stimits wrote: [snip} > NVdriver 1066080 10 (autoclean) [snip] I have severals of theses oops and blame them all on a faulty Nvida driver. I upgraded the Nvida driver from 1.0-2880 to 1.0-2960 3 weeks ago and have not seen the oops afterwards. Kjell From owner-linux-xfs@oss.sgi.com Sun Jul 28 02:03:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6S93LRw022148 for ; Sun, 28 Jul 2002 02:03:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6S93Ia4022147 for linux-xfs-outgoing; Sun, 28 Jul 2002 02:03:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6S92ZRw022119 for ; Sun, 28 Jul 2002 02:02:37 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 83BC5C01887; Sun, 28 Jul 2002 17:03:45 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id A6532C0186B; Sun, 28 Jul 2002 17:03:36 +0800 (PHT) Date: Sun, 28 Jul 2002 17:03:36 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List , Linux Kernel Mailing List Subject: Re: Kernel BUG at page_alloc.c:91 (2.4.19-rc2-xfs) Message-ID: <20020728090336.GD1265@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List , Linux Kernel Mailing List References: <20020728082542.GC1265@leathercollection.ph> <20020728084718.GW1548@niksula.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020728084718.GW1548@niksula.cs.hut.fi> User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Jul 28, 2002 at 11:47:19AM +0300, Ville Herva wrote: > Please run these through ksymoops to get the hexadecimal addresses > resolved to function names. See > /usr/src/linux/Documentation/oops-tracing.txt. Ah, yes, I had forgotten to do that. I hadn't realized that the same requirement for reporting oopses held for reporting kernel BUGs. My sincerest apologies. I ran all four through ksymoops at once, and it worked so I guess this is a valid thing to do. I am still running the same configuration and haven't even rebooted, so I did not have to change any of ksymoops's defaults. The 'decoded' message follows. Thanks for the help. --> Jijo [1] Kernel BUG reports from dmesg passed through ksymoops: ksymoops 2.4.5 on i686 2.4.19-rc2-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.19-rc2-xfs/ (default) -m /boot/System.map-2.4.19-rc2-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. kernel BUG at page_alloc.c:91! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210282 eax: c11c90fc ebx: c11c73d4 ecx: 00000000 edx: c0333f40 esi: 00000000 edi: 000011b9 ebp: c0334050 esp: c12f3f08 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=c12f3000) Stack: 00000001 00200282 00000003 cf0dc8c0 cf0dc8c0 cf0dc8c0 c11c73d4 c013f0e2 cf0dc8c0 c0333f40 c11c73d4 000011b9 c0334050 c0134852 c11c73d4 000001d0 c12f2000 000001c7 000001d0 00000002 0000001f 000001d0 00000020 00000006 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 >>EIP; c013536d <__free_pages_ok+2d/260> <===== >>eax; c11c90fc <_end+e0baf8/104d29fc> >>ebx; c11c73d4 <_end+e09dd0/104d29fc> >>edx; c0333f40 >>edi; 000011b9 Before first symbol >>ebp; c0334050 >>esp; c12f3f08 <_end+f36904/104d29fc> Trace; c013f0e2 Trace; c0134852 Trace; c0134a11 Trace; c0134a86 Trace; c0134b36 Trace; c0134b98 Trace; c0134ccd Trace; c0105000 <_stext+0/0> Trace; c01071fe Trace; c0134c30 Code; c013536d <__free_pages_ok+2d/260> 00000000 <_EIP>: Code; c013536d <__free_pages_ok+2d/260> <===== 0: 0f 0b ud2a <===== Code; c013536f <__free_pages_ok+2f/260> 2: 5b pop %ebx Code; c0135370 <__free_pages_ok+30/260> 3: 00 f0 add %dh,%al Code; c0135372 <__free_pages_ok+32/260> 5: 62 2f bound %ebp,(%edi) Code; c0135374 <__free_pages_ok+34/260> 7: c0 89 d8 2b 05 d0 b0 rorb $0xb0,0xd0052bd8(%ecx) Code; c013537b <__free_pages_ok+3b/260> e: 39 c0 cmp %eax,%eax Code; c013537d <__free_pages_ok+3d/260> 10: c1 f8 02 sar $0x2,%eax Code; c0135380 <__free_pages_ok+40/260> 13: 69 00 00 00 00 00 imul $0x0,(%eax),%eax kernel BUG at page_alloc.c:91! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00210282 eax: c11ee984 ebx: c1261cc4 ecx: 00000000 edx: c0333f40 esi: 00000000 edi: 00001232 ebp: c0334050 esp: c72bddc0 ds: 0018 es: 0018 ss: 0018 Process http (pid: 14620, stackpage=c72bd000) Stack: 00000001 00200282 00000003 cf0dc3c0 cf0dc3c0 cf0dc3c0 c1261cc4 c013f0e2 cf0dc3c0 c0333f40 c1261cc4 00001232 c0334050 c0134852 c1261cc4 000001d2 c72bc000 000001d1 000001d2 00000020 0000001e 000001d2 00000020 00000006 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 >>EIP; c013536d <__free_pages_ok+2d/260> <===== >>eax; c11ee984 <_end+e31380/104d29fc> >>ebx; c1261cc4 <_end+ea46c0/104d29fc> >>edx; c0333f40 >>edi; 00001232 Before first symbol >>ebp; c0334050 >>esp; c72bddc0 <_end+6f007bc/104d29fc> Trace; c013f0e2 Trace; c0134852 Trace; c0134a11 Trace; c0134a86 Trace; c0135827 Trace; c0135a7d <__alloc_pages+ed/190> Trace; c01306b2 Trace; c029e04d Trace; c01fd88f Trace; c029e420 Trace; c01f90c4 Trace; c013ae93 Trace; c0108db7 Code; c013536d <__free_pages_ok+2d/260> 00000000 <_EIP>: Code; c013536d <__free_pages_ok+2d/260> <===== 0: 0f 0b ud2a <===== Code; c013536f <__free_pages_ok+2f/260> 2: 5b pop %ebx Code; c0135370 <__free_pages_ok+30/260> 3: 00 f0 add %dh,%al Code; c0135372 <__free_pages_ok+32/260> 5: 62 2f bound %ebp,(%edi) Code; c0135374 <__free_pages_ok+34/260> 7: c0 89 d8 2b 05 d0 b0 rorb $0xb0,0xd0052bd8(%ecx) Code; c013537b <__free_pages_ok+3b/260> e: 39 c0 cmp %eax,%eax Code; c013537d <__free_pages_ok+3d/260> 10: c1 f8 02 sar $0x2,%eax Code; c0135380 <__free_pages_ok+40/260> 13: 69 00 00 00 00 00 imul $0x0,(%eax),%eax kernel BUG at page_alloc.c:91! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00210282 eax: c128cef4 ebx: c1209ea8 ecx: 00000000 edx: c0333f40 esi: 00000000 edi: 00001234 ebp: c0334050 esp: cd2ffdec ds: 0018 es: 0018 ss: 0018 Process ssh (pid: 14631, stackpage=cd2ff000) Stack: 00000001 00200282 00000003 cf0dc340 cf0dc340 cf0dc340 c1209ea8 c013f0e2 cf0dc340 c0333f40 c1209ea8 00001234 c0334050 c0134852 c1209ea8 000001d2 cd2fe000 000001d2 000001d2 00000020 0000001f 000001d2 00000020 00000006 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 >>EIP; c013536d <__free_pages_ok+2d/260> <===== >>eax; c128cef4 <_end+ecf8f0/104d29fc> >>ebx; c1209ea8 <_end+e4c8a4/104d29fc> >>edx; c0333f40 >>edi; 00001234 Before first symbol >>ebp; c0334050 >>esp; cd2ffdec <_end+cf427e8/104d29fc> Trace; c013f0e2 Trace; c0134852 Trace; c0134a11 Trace; c0134a86 Trace; c0135827 Trace; c0135a7d <__alloc_pages+ed/190> Trace; c012b638 Trace; c012b8e7 Trace; c011897e Trace; d0966c00 <[NVdriver]nv_linux_devices+0/4a0> Trace; d0966c00 <[NVdriver]nv_linux_devices+0/4a0> Trace; d08a1586 <[NVdriver]__nvsym00486+82/90> Trace; c012cfc8 Trace; c012be88 Trace; c0118820 Trace; c0108ea8 Code; c013536d <__free_pages_ok+2d/260> 00000000 <_EIP>: Code; c013536d <__free_pages_ok+2d/260> <===== 0: 0f 0b ud2a <===== Code; c013536f <__free_pages_ok+2f/260> 2: 5b pop %ebx Code; c0135370 <__free_pages_ok+30/260> 3: 00 f0 add %dh,%al Code; c0135372 <__free_pages_ok+32/260> 5: 62 2f bound %ebp,(%edi) Code; c0135374 <__free_pages_ok+34/260> 7: c0 89 d8 2b 05 d0 b0 rorb $0xb0,0xd0052bd8(%ecx) Code; c013537b <__free_pages_ok+3b/260> e: 39 c0 cmp %eax,%eax Code; c013537d <__free_pages_ok+3d/260> 10: c1 f8 02 sar $0x2,%eax Code; c0135380 <__free_pages_ok+40/260> 13: 69 00 00 00 00 00 imul $0x0,(%eax),%eax kernel BUG at page_alloc.c:91! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00210282 eax: c12987b8 ebx: c10b9ba8 ecx: 00000000 edx: c0333f40 esi: 00000000 edi: 00001235 ebp: c0334050 esp: cd2ffdd0 ds: 0018 es: 0018 ss: 0018 Process ssh (pid: 14633, stackpage=cd2ff000) Stack: 00000001 00200282 00000003 cf0dc1c0 cf0dc1c0 cf0dc1c0 c10b9ba8 c013f0e2 cf0dc1c0 c0333f40 c10b9ba8 00001235 c0334050 c0134852 c10b9ba8 000001d2 cd2fe000 000001d2 000001d2 0000001f 00000020 000001d2 00000020 00000006 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 >>EIP; c013536d <__free_pages_ok+2d/260> <===== >>eax; c12987b8 <_end+edb1b4/104d29fc> >>ebx; c10b9ba8 <_end+cfc5a4/104d29fc> >>edx; c0333f40 >>edi; 00001235 Before first symbol >>ebp; c0334050 >>esp; cd2ffdd0 <_end+cf427cc/104d29fc> Trace; c013f0e2 Trace; c0134852 Trace; c0134a11 Trace; c0134a86 Trace; c0135827 Trace; c0135a7d <__alloc_pages+ed/190> Trace; c012b7c1 Trace; c012b8e7 Trace; c011897e Trace; c010e601 Trace; c013a3cd Trace; c0118820 Trace; c0108ea8 Code; c013536d <__free_pages_ok+2d/260> 00000000 <_EIP>: Code; c013536d <__free_pages_ok+2d/260> <===== 0: 0f 0b ud2a <===== Code; c013536f <__free_pages_ok+2f/260> 2: 5b pop %ebx Code; c0135370 <__free_pages_ok+30/260> 3: 00 f0 add %dh,%al Code; c0135372 <__free_pages_ok+32/260> 5: 62 2f bound %ebp,(%edi) Code; c0135374 <__free_pages_ok+34/260> 7: c0 89 d8 2b 05 d0 b0 rorb $0xb0,0xd0052bd8(%ecx) Code; c013537b <__free_pages_ok+3b/260> e: 39 c0 cmp %eax,%eax Code; c013537d <__free_pages_ok+3d/260> 10: c1 f8 02 sar $0x2,%eax Code; c0135380 <__free_pages_ok+40/260> 13: 69 00 00 00 00 00 imul $0x0,(%eax),%eax 1 warning issued. Results may not be reliable. -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Sun Jul 28 02:31:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6S9VrRw022615 for ; Sun, 28 Jul 2002 02:31:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6S9VqjM022614 for linux-xfs-outgoing; Sun, 28 Jul 2002 02:31:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.broadpark.no (217-13-4-9.dd.nextgentel.com [217.13.4.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6S9VdRw022585 for ; Sun, 28 Jul 2002 02:31:46 -0700 Received: from online.no (81.80-202-103.nextgentel.com [80.202.103.81]) by mail.broadpark.no (Postfix) with ESMTP id DA69F7D7B; Sun, 28 Jul 2002 11:32:45 +0200 (MEST) Message-ID: <3D43B897.7FD04347@online.no> Date: Sun, 28 Jul 2002 11:25:43 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5custom i686) X-Accept-Language: en MIME-Version: 1.0 To: Kjell Randa Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19rc2 XFS oops trace References: <3D43B40B.1010003@broadpark.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Kjell Randa wrote: > On Sat, Jul 27, 2002 at 04:11:52PM -0600, D. Stimits wrote: > > [snip} > > > NVdriver 1066080 10 (autoclean) > > [snip] > > I have severals of theses oops and blame them all on a faulty Nvida driver. > I upgraded the Nvida driver from 1.0-2880 to 1.0-2960 3 weeks ago and have not seen the oops afterwards. > > Kjell You could try to not use agpgart since, nv agpgart does not cause page_alloc.c failur. From owner-linux-xfs@oss.sgi.com Sun Jul 28 02:58:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6S9wPRw022901 for ; Sun, 28 Jul 2002 02:58:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6S9wOPW022900 for linux-xfs-outgoing; Sun, 28 Jul 2002 02:58:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6S9w8Rw022872 for ; Sun, 28 Jul 2002 02:58:18 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17YkpZ-0001hL-00; Sun, 28 Jul 2002 10:59:17 +0100 Date: Sun, 28 Jul 2002 10:59:17 +0100 From: Christoph Hellwig To: Federico Sevilla III Cc: Linux-XFS Mailing List , Linux Kernel Mailing List Subject: Re: Kernel BUG at page_alloc.c:91 (2.4.19-rc2-xfs) Message-ID: <20020728105917.A6391@infradead.org> Mail-Followup-To: Christoph Hellwig , Federico Sevilla III , Linux-XFS Mailing List , Linux Kernel Mailing List References: <20020728082542.GC1265@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020728082542.GC1265@leathercollection.ph>; from jijo@free.net.ph on Sun, Jul 28, 2002 at 04:25:42PM +0800 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Jul 28, 2002 at 04:25:42PM +0800, Federico Sevilla III wrote: > Hi everyone, > > I apologize for sending this to both the Linux kernel mailing list as > well as the Linux-XFS mailing list. I am sending this to the lkml > because it's a kernel bug report. I'm sending this to the Linux-XFS > mailing list because I do not know if "try_to_free_buffers+130/240" in > the Call Trace has anything to do with changes that the XFS team has > done on the Linux kernel. Let me guess: you're using nvidia's binary only module? if so please go and complain to them, this oops is characteristic for their buggy driver. From owner-linux-xfs@oss.sgi.com Sun Jul 28 03:01:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SA1cRw022987 for ; Sun, 28 Jul 2002 03:01:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SA1aY5022986 for linux-xfs-outgoing; Sun, 28 Jul 2002 03:01:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SA1LRw022958 for ; Sun, 28 Jul 2002 03:01:28 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 02389C01887; Sun, 28 Jul 2002 18:02:32 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id BC0FFC01886; Sun, 28 Jul 2002 18:02:22 +0800 (PHT) Date: Sun, 28 Jul 2002 18:02:22 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List , Linux Kernel Mailing List Subject: Re: Kernel BUG at page_alloc.c:91 (2.4.19-rc2-xfs) Message-ID: <20020728100222.GF1265@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List , Linux Kernel Mailing List References: <20020728082542.GC1265@leathercollection.ph> <20020728084718.GW1548@niksula.cs.hut.fi> <20020728090336.GD1265@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020728090336.GD1265@leathercollection.ph> User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Jul 28, 2002 at 05:03:36PM +0800, Federico Sevilla III wrote: > Ah, yes, I had forgotten to do that. I hadn't realized that the same > requirement for reporting oopses held for reporting kernel BUGs. I had further forgotten to mention that I have the NVidia 2960 binary module loaded, and that D. Stimits just posted a message on the Linux-XFS mailing list about a kernel BUG report also on page_alloc.c:91 on a similar 2.4.19-rc2-xfs CVS snapshot, also with the NVdriver module loaded. Kjell Randa noted that an upgrade to version 2960 fixed things for him, and Kjell Randa added that removing "agpgart" support fixes things. I have agpgart support for my VIA chipset, and it's possible that this is clashing with the NVdriver. I realize that I may have wasted people's time, since the NVidia driver is closed-source binary-only, and my system is tainted. I apologize for this but hope that my messages will at least help some other people who may run into this problem and will search the archives. I am upgrading to 2.4.19-rc3-xfs now, and will remove agpgart support from the kernel. I am keeping my fingers crossed. --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Sun Jul 28 03:22:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SAMARw023335 for ; Sun, 28 Jul 2002 03:22:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SAM8L3023334 for linux-xfs-outgoing; Sun, 28 Jul 2002 03:22:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SALkRw023306 for ; Sun, 28 Jul 2002 03:21:57 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 605EEC01887; Sun, 28 Jul 2002 18:22:56 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 5E4ACC01886; Sun, 28 Jul 2002 18:22:46 +0800 (PHT) Date: Sun, 28 Jul 2002 18:22:46 +0800 From: Federico Sevilla III To: Linux Kernel Mailing List , Linux-XFS Mailing List Subject: Unkillable processes stuck in "D" state running forever Message-ID: <20020728102246.GG1265@leathercollection.ph> Mail-Followup-To: Linux Kernel Mailing List , Linux-XFS Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everyone, Again I cross-post, and hope that people will accept my apologies. I do not know if this is a vanilla kernel problem, or something that has to do with XFS. I have been noticing problems on two of my boxes here with some processes somehow getting stuck in "D" state, which cannot be killed even by a SIGKILL by root, and stay on running forever. I have noticed the problem, so far, on 2.4.18-xfs and 2.4.19-rc2-xfs kernels. The 2.4.18-xfs kernel did not have any binary-only modules loaded (like NVdriver) and aside from the modules from the kernel only had the i2c and lm-sensors modules. It was compiled using gcc 2.95.4 and was running on a single Pentium III. The 2.4.19-rc2-xfs kernel had the NVdriver binary-only module loaded (coincidentally the same unit I reported kernel BUG reports in page_alloc.c:91 about earlier), plus kernel modules and the i2c and lm-sensors modules. It was compiled using gcc 3.1.1 (Debian prerelease) and was running on a single AMD Duron. I have not found a pattern to the occurence of these stuck processes. They don't happen at given intervales, or with only a particular type of process, or on certain workloads or tasks. They've happened on everything from X11 (consequently freezing the box), to the apt-method of dpkg (consequently preventing me from doing any apt-get installations), to the dhcp3 daemon (consequently preventing new boxes from getting IP addresses). They've also happened on boxes with two days uptime, or with 7 days uptime, or with 14. So far the only "solution" I've found to this problem has been to reboot. There is unfortunately absolutely nothing I can find in the logs to help explain what's going on with these processes. Because I have not figured out how to reproduce this, I do not know which process to run through strace or a similar tool to figure out what's going on. I hope someone can help shed light on this. Thank you very much. I have upgraded the 2.4.18-xfs box to 2.4.19-rc3-xfs, and will upgrade the 2.4.19-rc2-xfs box to 2.4.19-rc3-xfs as well, and will see if the problem goes away. If anyone else is experiencing similar "processes stuck in state 'D'" problems, please do chime in and add your experiences about the problem. --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Sun Jul 28 03:48:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SAmDRw023634 for ; Sun, 28 Jul 2002 03:48:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SAlwCt023632 for linux-xfs-outgoing; Sun, 28 Jul 2002 03:47:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from PC-5. ([61.48.16.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SAlYRw023570; Sun, 28 Jul 2002 03:47:41 -0700 x-esmtp: 0 0 1 Message-ID: <2135773-22002702893222933@smtp.vip.sina.com> To: "NEW020515" <911@911.COM> From: "ÖйúITÊý¾Ý¿âÍøÕ¾£¨www.itdatabase.net £©" <911@911.COM> Subject: ÖйúITÊý¾Ý¿âÍøÕ¾£¨www.itdatabase.net £© Date: Sun, 28 Jul 2002 17:32:22 +0800 MIME-Version: 1.0 Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6SAlnRw023575 X-Spam-Status: No, hits=3.6 required=5.0 tests=FROM_ENDS_IN_NUMS,SUPERLONG_LINE,CHARSET_FARAWAY,FROM_AND_TO_SAME version=2.20 X-Spam-Level: *** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ÖйúITÊý¾Ý¿âÍøÕ¾£¨www.itdatabase.net £©Ìṩ´óÁ¿ÓйØÖйúIT/ͨÐÅÊг¡ÒÔ¼°È«ÇòIT/ͨÐÅÊг¡µÄÏà¹ØÊý¾ÝºÍ·ÖÎö¡£ ±¾ÍøÕ¾Éæ¼°ÓйصçÐÅÔËÓªÊг¡¡¢µçÐÅÔËÓªÉÌ¡¢IT/ͨѶ²úÆ·¡¢IT³§ÉÌ¡¢ÒÔ¼°IT·¨ÂÉ·¨¹æµÈ¶à·½ÃæÐÅÏ¢£¬Îª¹ã´óIT/ͨѶ½çÈËÊ¿ÌṩÁËÒ»¸öÄÚÈÝÈ«Ãæ¡¢Êý¾Ý·á¸»¡¢²éѯ¿ì½ÝµÄרҵÐÅϢƽ̨£¬ÊÇÆóÒµ´ÓÊÂÊг¡·ÖÎö¡¢ÒµÎñÍØÕ¹ºÍ²úÆ·ÍƹãµÄÓÐÁ¦ÖúÊÖ¡£»¶Ó­Äú¹âÁÙ²¢¼ÓÈëwww.itdatabase.net From owner-linux-xfs@oss.sgi.com Sun Jul 28 04:34:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SBYpRw030818 for ; Sun, 28 Jul 2002 04:34:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SBYmBW030816 for linux-xfs-outgoing; Sun, 28 Jul 2002 04:34:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SBYaRw030788 for ; Sun, 28 Jul 2002 04:34:39 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 8FA01C0188C; Sun, 28 Jul 2002 19:35:48 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 80A7FC01886; Sun, 28 Jul 2002 19:35:36 +0800 (PHT) Date: Sun, 28 Jul 2002 19:35:36 +0800 From: Federico Sevilla III To: Linux Kernel Mailing List , Linux-XFS Mailing List Subject: Re: Unkillable processes stuck in "D" state running forever Message-ID: <20020728113536.GI1265@leathercollection.ph> Mail-Followup-To: Linux Kernel Mailing List , Linux-XFS Mailing List References: <20020728102246.GG1265@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020728102246.GG1265@leathercollection.ph> User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Jul 28, 2002 at 06:22:46PM +0800, Federico Sevilla III wrote: > I have been noticing problems on two of my boxes here with some > processes somehow getting stuck in "D" state, which cannot be killed > even by a SIGKILL by root, and stay on running forever. I have noticed > the problem, so far, on 2.4.18-xfs and 2.4.19-rc2-xfs kernels. I do not know how small a tidbit this will be, but together with these processes stuck in state "D", there is a continuing rise in the load averages of the system as reported by various interfaces (top/uptime/w/phpSysInfo). On the system running 2.4.18-xfs this rose to up to 25 before I eventually rebooted the box. Another bit: on the 2.4.18-xfs box, the number of processes getting stuck in state "D" kept growing. Various `ps ax` and `sync` processes in particular, would get stuck and stall as I would issue them. It may be interesting to note that with 2.4.19-rc2-xfs, with which I had my "latest encounter" with this problem, no `ps ax` or `sync` processes got stuck. Only the couple of apt-method processes that got stuck (and any new ones I would launch in an attempt to download a package from the Internet for installation) were there. Both units have already been upgraded to 2.4.19-rc3-xfs. I will send feedback if/when I run into any processes stuck in state "D" for abnormally long periods of time. --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Sun Jul 28 05:30:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SCUORw007206 for ; Sun, 28 Jul 2002 05:30:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SCUOrp007205 for linux-xfs-outgoing; Sun, 28 Jul 2002 05:30:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SCUJRw007177 for ; Sun, 28 Jul 2002 05:30:19 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA37011; Sun, 28 Jul 2002 07:31:31 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-28.corp.sgi.com [134.15.64.28]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA14687; Sun, 28 Jul 2002 07:31:31 -0500 (CDT) Subject: Re: NFS From: Stephen Lord To: Derek Glidden Cc: "linux-xfs@oss.sgi.com" In-Reply-To: <1027610148.23272.5.camel@two.nks.net> References: <20020724230655.O27801-100000@xs1.xs4all.nl> <1027550034.21591.13.camel@two.nks.net> <20020725063733.GB3940@thangorodrim.thompson.us> <1027610148.23272.5.camel@two.nks.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 28 Jul 2002 07:29:26 -0500 Message-Id: <1027859368.10337.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-07-25 at 10:15, Derek Glidden wrote: > > It's an option to mounting an XFS filesystem - not /etc/exports. > > Presumably it means something like "writesync" but I'm not sure if it's > still relevant to making NFS work reliably. > wsync has the effect of making all transactions in XFS synchronous, it was designed for NFS and is normally combined with turning on a synchronous writes in NFS. Basically this is for people who want to follow the original NFS spec - before the NFS server returns from an RPC, all associated data is spinning on disk, unless you have IDE write caching turned on of course. Steve From owner-linux-xfs@oss.sgi.com Sun Jul 28 06:16:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SDGXRw010087 for ; Sun, 28 Jul 2002 06:16:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SDGXqZ010086 for linux-xfs-outgoing; Sun, 28 Jul 2002 06:16:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SDGORw010058 for ; Sun, 28 Jul 2002 06:16:26 -0700 Received: from Port.imtp.ilyichevsk.odessa.ua (167.imtp.Ilyichevsk.Odessa.UA [195.66.192.167] (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 GAA01435 for ; Sun, 28 Jul 2002 06:18:10 -0700 (PDT) mail_from (vda@port.imtp.ilyichevsk.odessa.ua) Received: from there ([172.16.42.48]) by Port.imtp.ilyichevsk.odessa.ua (8.10.2/8.10.2) with SMTP id g6SDBVT29125; Sun, 28 Jul 2002 16:11:31 +0300 Message-Id: <200207281311.g6SDBVT29125@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset="us-ascii" From: Denis Vlasenko Reply-To: vda@port.imtp.ilyichevsk.odessa.ua To: Federico Sevilla III , Linux Kernel Mailing List , Linux-XFS Mailing List Subject: Re: Unkillable processes stuck in "D" state running forever Date: Sun, 28 Jul 2002 16:09:33 -0200 X-Mailer: KMail [version 1.3.2] References: <20020728102246.GG1265@leathercollection.ph> <20020728113536.GI1265@leathercollection.ph> In-Reply-To: <20020728113536.GI1265@leathercollection.ph> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 28 July 2002 09:35, Federico Sevilla III wrote: > On Sun, Jul 28, 2002 at 06:22:46PM +0800, Federico Sevilla III wrote: > > I have been noticing problems on two of my boxes here with some > > processes somehow getting stuck in "D" state, which cannot be killed > > even by a SIGKILL by root, and stay on running forever. I have noticed > > the problem, so far, on 2.4.18-xfs and 2.4.19-rc2-xfs kernels. > > I do not know how small a tidbit this will be, but together with these > processes stuck in state "D", there is a continuing rise in the load > averages of the system as reported by various interfaces > (top/uptime/w/phpSysInfo). On the system running 2.4.18-xfs this rose to > up to 25 before I eventually rebooted the box. > > Another bit: on the 2.4.18-xfs box, the number of processes getting > stuck in state "D" kept growing. Various `ps ax` and `sync` processes in > particular, would get stuck and stall as I would issue them. It may be > interesting to note that with 2.4.19-rc2-xfs, with which I had my "latest > encounter" with this problem, no `ps ax` or `sync` processes got stuck. > Only the couple of apt-method processes that got stuck (and any new ones > I would launch in an attempt to download a package from the Internet for > installation) were there. D state processes are sitting in kernel code waiting for something to happen. It is ok to sit in D state for milliseconds, it is acceptable to sit for seconds. If those processes are stuck forever, it's a bug. Capture Alt-SysRq-T output and ksymoops relevant part Yes it means you should have ksymoops installed and tested, which is easy to get wrong. I've done that too often. -- vda From owner-linux-xfs@oss.sgi.com Sun Jul 28 07:48:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SEmZRw010643 for ; Sun, 28 Jul 2002 07:48:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SEmZT2010642 for linux-xfs-outgoing; Sun, 28 Jul 2002 07:48:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from natalie.ampithy.com (pool-141-158-101-178.pitt.east.verizon.net [141.158.101.178]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SEmPRw010614 for ; Sun, 28 Jul 2002 07:48:26 -0700 Received: from phreaker.net (IDENT:1000@localhost [127.0.0.1]) by natalie.ampithy.com (8.12.4/8.12.4) with ESMTP id g6SFOQ5n000377 for ; Sun, 28 Jul 2002 11:24:27 -0400 Message-ID: <3D440CAA.509@phreaker.net> Date: Sun, 28 Jul 2002 11:24:26 -0400 From: Draken Korin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_force_shutdown on software raid Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well I have replicated the error mentioned in the FAQ about xfs_force_shutdown on a software raid (HPT370). Seems to work fine when moving a file or two over from another disk, but when an entire tree is copied it just spews out the i/o errors and unmounts itself, forcing me to stop the raid, run xfs_repair, and mount again. It's probally just my problem but if you needed some debugging informaion here ya go. XFS mounting filesystem md(9,0) raid0_make_request bug: can't convert block across chunks or bigger than 512k 159385589 64 xfs_force_shutdown(md(9,0),0x1) called from line 350 of file xfs_rw.c. Return address = 0xc01dd87d I/O Error Detected. Shutting down filesystem: md(9,0) Please umount the filesystem, and rectify the problem(s) I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x98007f5 ("xlog_bwrite") error 5 buf count 131072 xfs_force_shutdown(md(9,0),0x1) called from line 350 of file xfs_rw.c. Return address = 0xc01dd87d I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x98008f5 ("xlog_bwrite") error 5 buf count 131072 XFS: failed to locate log tail XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem md(9,0) raid0_make_request bug: can't convert block across chunks or bigger than 512k 159385589 64 xfs_force_shutdown(md(9,0),0x1) called from line 350 of file xfs_rw.c. Return address = 0xc01dd87d I/O Error Detected. Shutting down filesystem: md(9,0) Please umount the filesystem, and rectify the problem(s) I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x98007f5 ("xlog_bwrite") error 5 buf count 131072 xfs_force_shutdown(md(9,0),0x1) called from line 350 of file xfs_rw.c. Return address = 0xc01dd87d I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x98008f5 ("xlog_bwrite") error 5 buf count 131072 XFS: failed to locate log tail XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem md(9,0) From owner-linux-xfs@oss.sgi.com Sun Jul 28 14:46:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SLksRw024369 for ; Sun, 28 Jul 2002 14:46:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SLks0I024368 for linux-xfs-outgoing; Sun, 28 Jul 2002 14:46:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from totalrecall.idcomm.com (totalrecall-xvr.idcomm.com [207.40.197.36]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SLklRw024336 for ; Sun, 28 Jul 2002 14:46:47 -0700 Received: from idcomm.com (IDENT:YDUWi5R0+CRMv/u7YOI2Yh+OG3J4ennp@tnt01-ppp-253.idcomm.com [216.98.194.253]) by totalrecall.idcomm.com (8.11.6/8.11.6) with ESMTP id g6SLm3A16372; Sun, 28 Jul 2002 15:48:03 -0600 X-Spam-Filter: check_local@totalrecall.idcomm.com by digitalanswers.org Message-ID: <3D4466C1.70902@idcomm.com> Date: Sun, 28 Jul 2002 15:48:49 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kjell Randa CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.19rc2 XFS oops trace References: <3D43B40B.1010003@broadpark.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Kjell Randa wrote: > On Sat, Jul 27, 2002 at 04:11:52PM -0600, D. Stimits wrote: > > [snip} > >> NVdriver 1066080 10 (autoclean) > > > [snip] > > I have severals of theses oops and blame them all on a faulty Nvida driver. > I upgraded the Nvida driver from 1.0-2880 to 1.0-2960 3 weeks ago and > have not seen the oops afterwards. > > Kjell > > > > FYI, I had one oops of the nVidia driver as well, the same one, and it was 2960. I'm wondering if your above line has a typographic error, it says you upgraded from the higher number 2880 to the lower number 2960. If you meant you changed from 2960 to 2880, then I will do this too (even though so far I have had only one oops, and it did not interfere with the normal operation of the machine until shutdown, when swap would not umount). D. Stimits, stimits @ idcomm.com From owner-linux-xfs@oss.sgi.com Sun Jul 28 14:44:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SLiXRw024236 for ; Sun, 28 Jul 2002 14:44:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SLiXr8024235 for linux-xfs-outgoing; Sun, 28 Jul 2002 14:44:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from totalrecall.idcomm.com (totalrecall-xvr.idcomm.com [207.40.197.36]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SLi3Rw024203 for ; Sun, 28 Jul 2002 14:44:03 -0700 Received: from idcomm.com (IDENT:etE60KT7ki1zWXvbIDZ3tq25g1FPukrc@tnt01-ppp-253.idcomm.com [216.98.194.253]) by totalrecall.idcomm.com (8.11.6/8.11.6) with ESMTP id g6SLjAA16325; Sun, 28 Jul 2002 15:45:10 -0600 X-Spam-Filter: check_local@totalrecall.idcomm.com by digitalanswers.org Message-ID: <3D446613.1030804@idcomm.com> Date: Sun, 28 Jul 2002 15:45:55 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Federico Sevilla III CC: Linux-XFS Mailing List Subject: Re: Kernel BUG at page_alloc.c:91 (2.4.19-rc2-xfs) References: <20020728082542.GC1265@leathercollection.ph> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is the same bug I hit, it is unrelated to XFS. Turns out it is something for nVidia. Their email is linux-bugs@nvidia.com. See: http://www.nvidia.com/docs/lo/1021/SUPP/README.txt Search for "linux-bugs". In my case I was using SMP (dual PIII), and compiled kernel and kernel modules with Redhat's "kgcc" (which is what seems to be the most reliable kernel building compiler on RH), so it does not seem to be related to SMP or chipset or compiler version (you can mention that in the email to nvidia). I just sent my email to them on Friday or Saturday (I forget which), so they have not had time to look at it yet (unless they work as hard as SGI, but I don't think anyone else works that many hours!). D. Stimits, stimits @ idcomm.com Federico Sevilla III wrote: > Hi everyone, > > I apologize for sending this to both the Linux kernel mailing list as > well as the Linux-XFS mailing list. I am sending this to the lkml > because it's a kernel bug report. I'm sending this to the Linux-XFS > mailing list because I do not know if "try_to_free_buffers+130/240" in > the Call Trace has anything to do with changes that the XFS team has > done on the Linux kernel. > > I got kernel BUG reports in my system logs[1] and dmesg[2] four times > today. The first time it happened with process kswapd, the second with > process httpd (of Apache), the third and fourth with ssh which I was > firing up through wterm. They happened all within a fairly short period > of time: the first at 16:02:05, the second at the same time, the third > at 16:03:51 and the fourth at 16:03:53. > > I am running Linux kernel 2.4.19-rc2-xfs (CVS snapshot 20020718), > compiled using the current gcc-3.1 Debian packages from Sid (gcc version > 3.1.1 20020703 (Debian prerelease) according to `gcc-3.1 -v`), on an AMD > Duron/850MHz. This system has been running continuously using this > kernel for 7 days 22:13, according to uptime. I didn't do anything > special this afternoon when all four kernel BUG incidences occured. > > Would any of the kernel or XFS developers want me to do anything to > perhaps help debug this situation? I intend to move this system up to > 2.4.19-rc3-xfs (CVS snapshot as of today), otherwise. > > Thanks a lot in advance. > > --> Jijo > > [1] Kernel BUG reports from syslog (with timestamps and slightly > different call trace information): > > Jul 28 16:02:05 lawin kernel: kernel BUG at page_alloc.c:91! > Jul 28 16:02:05 lawin kernel: invalid operand: 0000 > Jul 28 16:02:05 lawin kernel: CPU: 0 > Jul 28 16:02:05 lawin kernel: EIP: 0010:[__free_pages_ok+45/608] Tainted: P > Jul 28 16:02:05 lawin kernel: EFLAGS: 00210282 > Jul 28 16:02:05 lawin kernel: eax: c11c90fc ebx: c11c73d4 ecx: 00000000 edx: c0333f40 > Jul 28 16:02:05 lawin kernel: esi: 00000000 edi: 000011b9 ebp: c0334050 esp: c12f3f08 > Jul 28 16:02:05 lawin kernel: ds: 0018 es: 0018 ss: 0018 > Jul 28 16:02:05 lawin kernel: Process kswapd (pid: 5, stackpage=c12f3000) > Jul 28 16:02:05 lawin kernel: Stack: 00000001 00200282 00000003 cf0dc8c0 cf0dc8c0 cf0dc8c0 c11c73d4 c013f0e2 > Jul 28 16:02:05 lawin kernel: cf0dc8c0 c0333f40 c11c73d4 000011b9 c0334050 c0134852 c11c73d4 000001d0 > Jul 28 16:02:05 lawin kernel: c12f2000 000001c7 000001d0 00000002 0000001f 000001d0 00000020 00000006 > Jul 28 16:02:05 lawin kernel: Call Trace: [try_to_free_buffers+130/240] [shrink_cache+642/784] [shrink_caches+97/160] [try_to_free_pages+54/96 > ] [kswapd_balance_pgdat+86/160] > Jul 28 16:02:05 lawin kernel: [kswapd_balance+24/48] [kswapd+157/192] [rest_init+0/64] [kernel_thread+46/64] [kswapd+0/192] > Jul 28 16:02:05 lawin kernel: > Jul 28 16:02:05 lawin kernel: Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 > Jul 28 16:02:05 lawin kernel: kernel BUG at page_alloc.c:91! > Jul 28 16:02:05 lawin kernel: invalid operand: 0000 > Jul 28 16:02:05 lawin kernel: CPU: 0 > Jul 28 16:02:05 lawin kernel: EIP: 0010:[__free_pages_ok+45/608] Tainted: P > Jul 28 16:02:05 lawin kernel: EFLAGS: 00210282 > Jul 28 16:02:05 lawin kernel: eax: c11ee984 ebx: c1261cc4 ecx: 00000000 edx: c0333f40 > Jul 28 16:02:05 lawin kernel: esi: 00000000 edi: 00001232 ebp: c0334050 esp: c72bddc0 > Jul 28 16:02:05 lawin kernel: ds: 0018 es: 0018 ss: 0018 > Jul 28 16:02:05 lawin kernel: Process http (pid: 14620, stackpage=c72bd000) > Jul 28 16:02:05 lawin kernel: Stack: 00000001 00200282 00000003 cf0dc3c0 cf0dc3c0 cf0dc3c0 c1261cc4 c013f0e2 > Jul 28 16:02:05 lawin kernel: cf0dc3c0 c0333f40 c1261cc4 00001232 c0334050 c0134852 c1261cc4 000001d2 > Jul 28 16:02:05 lawin kernel: c72bc000 000001d1 000001d2 00000020 0000001e 000001d2 00000020 00000006 > Jul 28 16:02:05 lawin kernel: Call Trace: [try_to_free_buffers+130/240] [shrink_cache+642/784] [shrink_caches+97/160] [try_to_free_pages+54/96 > ] [balance_classzone+87/448] > Jul 28 16:02:06 lawin kernel: [__alloc_pages+237/400] [do_generic_file_write+818/1760] [ip_local_deliver+77/112] [xfs_write+591/2144] [ip_r > cv_finish+0/544] [linvfs_write+228/288] > Jul 28 16:02:06 lawin kernel: [sys_write+163/304] [system_call+51/56] > Jul 28 16:02:06 lawin kernel: > Jul 28 16:02:06 lawin kernel: Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 > Jul 28 16:03:51 lawin kernel: kernel BUG at page_alloc.c:91! > Jul 28 16:03:51 lawin kernel: invalid operand: 0000 > Jul 28 16:03:51 lawin kernel: CPU: 0 > Jul 28 16:03:51 lawin kernel: EIP: 0010:[__free_pages_ok+45/608] Tainted: P > Jul 28 16:03:51 lawin kernel: EFLAGS: 00210282 > Jul 28 16:03:51 lawin kernel: eax: c128cef4 ebx: c1209ea8 ecx: 00000000 edx: c0333f40 > Jul 28 16:03:51 lawin kernel: esi: 00000000 edi: 00001234 ebp: c0334050 esp: cd2ffdec > Jul 28 16:03:51 lawin kernel: ds: 0018 es: 0018 ss: 0018 > Jul 28 16:03:51 lawin kernel: Process ssh (pid: 14631, stackpage=cd2ff000) > Jul 28 16:03:51 lawin kernel: Stack: 00000001 00200282 00000003 cf0dc340 cf0dc340 cf0dc340 c1209ea8 c013f0e2 > Jul 28 16:03:51 lawin kernel: cf0dc340 c0333f40 c1209ea8 00001234 c0334050 c0134852 c1209ea8 000001d2 > Jul 28 16:03:51 lawin kernel: cd2fe000 000001d2 000001d2 00000020 0000001f 000001d2 00000020 00000006 > Jul 28 16:03:51 lawin kernel: Call Trace: [try_to_free_buffers+130/240] [shrink_cache+642/784] [shrink_caches+97/160] [try_to_free_pages+54/96 > ] [balance_classzone+87/448] > Jul 28 16:03:51 lawin kernel: [__alloc_pages+237/400] [do_anonymous_page+104/240] [handle_mm_fault+119/272] [do_page_fault+350/1257] [via68 > 6a:__insmod_via686a_O/lib/modules/2.4.19-rc2-xfs/misc/via686a.+-156672/96] [via686a:__insmod_via686a_O/lib/modules/2.4.19-rc2-xfs/misc/via686a > .+-156672/96] > Jul 28 16:03:51 lawin kernel: [via686a:__insmod_via686a_O/lib/modules/2.4.19-rc2-xfs/misc/via686a.+-965242/96] [do_brk+280/528] [sys_brk+26 > 4/320] [do_page_fault+0/1257] [error_code+52/60] > Jul 28 16:03:51 lawin kernel: > Jul 28 16:03:51 lawin kernel: Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 > Jul 28 16:03:53 lawin kernel: kernel BUG at page_alloc.c:91! > Jul 28 16:03:53 lawin kernel: invalid operand: 0000 > Jul 28 16:03:53 lawin kernel: CPU: 0 > Jul 28 16:03:53 lawin kernel: EIP: 0010:[__free_pages_ok+45/608] Tainted: P > Jul 28 16:03:53 lawin kernel: EFLAGS: 00210282 > Jul 28 16:03:53 lawin kernel: eax: c12987b8 ebx: c10b9ba8 ecx: 00000000 edx: c0333f40 > Jul 28 16:03:53 lawin kernel: esi: 00000000 edi: 00001235 ebp: c0334050 esp: cd2ffdd0 > Jul 28 16:03:53 lawin kernel: ds: 0018 es: 0018 ss: 0018 > Jul 28 16:03:53 lawin kernel: Process ssh (pid: 14633, stackpage=cd2ff000) > Jul 28 16:03:53 lawin kernel: Stack: 00000001 00200282 00000003 cf0dc1c0 cf0dc1c0 cf0dc1c0 c10b9ba8 c013f0e2 > Jul 28 16:03:53 lawin kernel: cf0dc1c0 c0333f40 c10b9ba8 00001235 c0334050 c0134852 c10b9ba8 000001d2 > Jul 28 16:03:53 lawin kernel: cd2fe000 000001d2 000001d2 0000001f 00000020 000001d2 00000020 00000006 > Jul 28 16:03:53 lawin kernel: Call Trace: [try_to_free_buffers+130/240] [shrink_cache+642/784] [shrink_caches+97/160] [try_to_free_pages+54/96 > ] [balance_classzone+87/448] > Jul 28 16:03:53 lawin kernel: [__alloc_pages+237/400] [do_no_page+257/432] [handle_mm_fault+119/272] [do_page_fault+350/1257] [old_mmap+257 > /288] [filp_close+77/128] > Jul 28 16:03:53 lawin kernel: [do_page_fault+0/1257] [error_code+52/60] > Jul 28 16:03:53 lawin kernel: > Jul 28 16:03:53 lawin kernel: Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 > > > [2] Kernel BUG reports from dmesg (no timestamps): > > kernel BUG at page_alloc.c:91! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00210282 > eax: c11c90fc ebx: c11c73d4 ecx: 00000000 edx: c0333f40 > esi: 00000000 edi: 000011b9 ebp: c0334050 esp: c12f3f08 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 5, stackpage=c12f3000) > Stack: 00000001 00200282 00000003 cf0dc8c0 cf0dc8c0 cf0dc8c0 c11c73d4 c013f0e2 > cf0dc8c0 c0333f40 c11c73d4 000011b9 c0334050 c0134852 c11c73d4 000001d0 > c12f2000 000001c7 000001d0 00000002 0000001f 000001d0 00000020 00000006 > Call Trace: [] [] [] [] [] > [] [] [] [] [] > > Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 > kernel BUG at page_alloc.c:91! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00210282 > eax: c11ee984 ebx: c1261cc4 ecx: 00000000 edx: c0333f40 > esi: 00000000 edi: 00001232 ebp: c0334050 esp: c72bddc0 > ds: 0018 es: 0018 ss: 0018 > Process http (pid: 14620, stackpage=c72bd000) > Stack: 00000001 00200282 00000003 cf0dc3c0 cf0dc3c0 cf0dc3c0 c1261cc4 c013f0e2 > cf0dc3c0 c0333f40 c1261cc4 00001232 c0334050 c0134852 c1261cc4 000001d2 > c72bc000 000001d1 000001d2 00000020 0000001e 000001d2 00000020 00000006 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] > > Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 > kernel BUG at page_alloc.c:91! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00210282 > eax: c128cef4 ebx: c1209ea8 ecx: 00000000 edx: c0333f40 > esi: 00000000 edi: 00001234 ebp: c0334050 esp: cd2ffdec > ds: 0018 es: 0018 ss: 0018 > Process ssh (pid: 14631, stackpage=cd2ff000) > Stack: 00000001 00200282 00000003 cf0dc340 cf0dc340 cf0dc340 c1209ea8 c013f0e2 > cf0dc340 c0333f40 c1209ea8 00001234 c0334050 c0134852 c1209ea8 000001d2 > cd2fe000 000001d2 000001d2 00000020 0000001f 000001d2 00000020 00000006 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] > > Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 > kernel BUG at page_alloc.c:91! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00210282 > eax: c12987b8 ebx: c10b9ba8 ecx: 00000000 edx: c0333f40 > esi: 00000000 edi: 00001235 ebp: c0334050 esp: cd2ffdd0 > ds: 0018 es: 0018 ss: 0018 > Process ssh (pid: 14633, stackpage=cd2ff000) > Stack: 00000001 00200282 00000003 cf0dc1c0 cf0dc1c0 cf0dc1c0 c10b9ba8 c013f0e2 > cf0dc1c0 c0333f40 c10b9ba8 00001235 c0334050 c0134852 c10b9ba8 000001d2 > cd2fe000 000001d2 000001d2 0000001f 00000020 000001d2 00000020 00000006 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] > > Code: 0f 0b 5b 00 f0 62 2f c0 89 d8 2b 05 d0 b0 39 c0 c1 f8 02 69 > > From owner-linux-xfs@oss.sgi.com Sun Jul 28 14:49:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6SLnaRw024609 for ; Sun, 28 Jul 2002 14:49:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6SLnapf024608 for linux-xfs-outgoing; Sun, 28 Jul 2002 14:49:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from totalrecall.idcomm.com (totalrecall-xvr.idcomm.com [207.40.197.36]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6SLnTRw024580 for ; Sun, 28 Jul 2002 14:49:29 -0700 Received: from idcomm.com (IDENT:gy79ryZmcJJizDgua+VDmu6tpkPOZviL@tnt01-ppp-253.idcomm.com [216.98.194.253]) by totalrecall.idcomm.com (8.11.6/8.11.6) with ESMTP id g6SLokA16435; Sun, 28 Jul 2002 15:50:46 -0600 X-Spam-Filter: check_local@totalrecall.idcomm.com by digitalanswers.org Message-ID: <3D446763.3040608@idcomm.com> Date: Sun, 28 Jul 2002 15:51:31 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Knut J Bjuland CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.19rc2 XFS oops trace References: <3D43B40B.1010003@broadpark.no> <3D43B897.7FD04347@online.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Knut J Bjuland wrote: > Kjell Randa wrote: > > >>On Sat, Jul 27, 2002 at 04:11:52PM -0600, D. Stimits wrote: >> >>[snip} >> >> >>>NVdriver 1066080 10 (autoclean) >> >>[snip] >> >>I have severals of theses oops and blame them all on a faulty Nvida driver. >>I upgraded the Nvida driver from 1.0-2880 to 1.0-2960 3 weeks ago and have not seen the oops afterwards. >> >>Kjell > > > You could try to not use agpgart since, nv agpgart does not cause page_alloc.c failur. > > NOTE: People can email this to me off-list if desired, I thought it would be nice for initial replies on-list since there are people currently interested in the problem. Could you elaborate on this? I am using the agpgart forced to 2x agp, I think this is the non-nVidia version. Does the nVidia version of the nvagpgart fix this? I can try switching. D. Stimits, stimits @ idcomm.com From owner-linux-xfs@oss.sgi.com Sun Jul 28 18:24:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6T1OdRw025805 for ; Sun, 28 Jul 2002 18:24:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6T1OX9F025804 for linux-xfs-outgoing; Sun, 28 Jul 2002 18:24:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6T1OJRw025776 for ; Sun, 28 Jul 2002 18:24:21 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA04280 for ; Sun, 28 Jul 2002 18:26:01 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA40687; Mon, 29 Jul 2002 11:24:08 +1000 (AEST) Date: Mon, 29 Jul 2002 11:24:08 +1000 From: Tim Shimmin To: Lars Soltau Cc: Tim Shimmin , linux-xfs@oss.sgi.com Subject: Re: problems with restore Message-ID: <20020729112408.F2935839@boing.melbourne.sgi.com> References: <20020723114554.J2935839@boing.melbourne.sgi.com> <3D411D05.9020301@slab.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3D411D05.9020301@slab.de>; from lars.soltau@slab.de on Fri, Jul 26, 2002 at 11:57:25AM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Lars, On Fri, Jul 26, 2002 at 11:57:25AM +0200, Lars Soltau wrote: > > > > 2. [...] So one is not supposed to copy a dump from tape onto a disk file and > > then restore it. [...] > > Well, that's not very helpful. :-) > > I had some old tapes and borrowed a matching streamer to restore them. > After the restore directly from tape failed with an assertion failure > (see blow), I copied the files to disk because I had to return the > streamer before I had a chance to do a full examination of the assertion > failure. > > I ended up patching drive_minrmt.c to forget about all SCSI commands and > open consecutively numbered files on hard disk instead. Ahhh, the beauty of open source :) > It would be a nice feature for xfsrestore to be able to open a tape > backup from disk, wouldn't it? > I guess ;-) It would be nice if the dump format was independent of the dump tape commands - at the moment using a "dump tape" strategy means using the dump tape format with the tape scsi commands. > > 3. I don't know why xfsrestore is aborting with an assertion failure for you. > > I do, now. I single-stepped into the assertion and found out that one > 64bit offset in each record header, the first_mark_offset, had been > written highendian instead of littleendian. All the other offsets, for > example file_offset that is located directly before first_mark_offset, > had been written correctly. > If you check out the cmd/xfsdump/doc/CHANGES file, it was fixed in December last year: xfsdump-1.1.10 (10 December 2001) - fix xfsdump to endian convert all of the record header fields properly just prior to writing the header out (in particular first_mark_offset). This caused do_next_mark() assertion failures at some sites. > The backup has been written by a version of xfsdump compiled with egcs > on Linux. Personally, I suspect egcs's 64bit arithmetic. Anyway, I > patched the source to correct the offset on the fly and the problem > vanished. Good. The mail archive: http://marc.theaimsgroup.com/?l=linux-xfs&m=101435725816823&w=2 had suggestions for restoring from the bad dumps. Cheers, --Tim From owner-linux-xfs@oss.sgi.com Sun Jul 28 21:02:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6T42vRw027412 for ; Sun, 28 Jul 2002 21:02:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6T42tAY027411 for linux-xfs-outgoing; Sun, 28 Jul 2002 21:02:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6T42jRw027383 for ; Sun, 28 Jul 2002 21:02:49 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA04211 for ; Sun, 28 Jul 2002 21:04:26 -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 NAA31125 for linux-xfs@oss.sgi.com; Mon, 29 Jul 2002 13:59:55 +1000 (EST) Date: Mon, 29 Jul 2002 13:59:55 +1000 (EST) From: Nathan Scott Message-Id: <200207290359.NAA31125@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - sync user/kernel X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Jul 28 21:02:24 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:123815a cmd/xfsprogs/include/xfs_da_btree.h - 1.9 cmd/xfsprogs/include/xfs_mount.h - 1.25 cmd/xfsprogs/include/xfs_inode.h - 1.23 cmd/xfsprogs/include/xfs_types.h - 1.13 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.15 cmd/xfsprogs/libxfs/xfs_rtalloc.c - 1.12 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.11 cmd/xfsprogs/libxfs/xfs_dir2_sf.c - 1.9 cmd/dmapi/include/dmapi_kern.h - 1.10 cmd/dmapi/include/dmapi.h - 1.9 - sync up with recent changes to the corresponding kernel code. From owner-linux-xfs@oss.sgi.com Sun Jul 28 23:06:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6T666Rw028399 for ; Sun, 28 Jul 2002 23:06:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6T664At028398 for linux-xfs-outgoing; Sun, 28 Jul 2002 23:06:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6T65nRw028366 for ; Sun, 28 Jul 2002 23:05:56 -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 XAA07652 for ; Sun, 28 Jul 2002 23:07:40 -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 QAA46713 for linux-xfs@oss.sgi.com; Mon, 29 Jul 2002 16:03:05 +1000 (EST) Date: Mon, 29 Jul 2002 16:03:05 +1000 (EST) From: Nathan Scott Message-Id: <200207290603.QAA46713@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsinvutil interactive mode X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Jul 28 23:04:12 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:123819a xfsdump/invutil/getopt.h - 1.1 xfsdump/invutil/list.c - 1.1 xfsdump/invutil/stobj.h - 1.1 xfsdump/invutil/stobj.c - 1.1 xfsdump/invutil/screen.c - 1.1 xfsdump/invutil/menu.c - 1.1 xfsdump/invutil/list.h - 1.1 xfsdump/invutil/cmenu.c - 1.1 xfsdump/invutil/invidx.h - 1.1 xfsdump/invutil/cmenu.h - 1.1 xfsdump/invutil/fstab.c - 1.1 xfsdump/invutil/invutil.h - 1.1 xfsdump/invutil/invidx.c - 1.1 xfsdump/invutil/fstab.h - 1.1 xfsdump/configure.in - 1.21 xfsdump/VERSION - 1.35 xfsdump/doc/README.xfsdump - 1.6 xfsdump/doc/CHANGES - 1.43 xfsdump/man/man8/xfsinvutil.8 - 1.3 xfsdump/include/builddefs.in - 1.19 xfsdump/debian/control - 1.11 xfsdump/debian/changelog - 1.25 xfsdump/invutil/Makefile - 1.8 xfsdump/invutil/invutil.c - 1.9 - bump version, document changes for xfsinvutil interactive mode (ported from IRIX). From owner-linux-xfs@oss.sgi.com Mon Jul 29 03:03:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6TA3dRw030668 for ; Mon, 29 Jul 2002 03:03:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6TA3dgg030667 for linux-xfs-outgoing; Mon, 29 Jul 2002 03:03:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6TA2bRw030613 for ; Mon, 29 Jul 2002 03:02:37 -0700 Received: from hermes3.atos-group.com (hermes3.atos-group.com [160.92.18.10]) by deliverator.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 DAA00158 for ; Mon, 29 Jul 2002 03:03:57 -0700 (PDT) mail_from (Valery.Brasseur@atosorigin.com) Received: by hermes3.atos-group.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 12:02:42 +0200 Message-ID: <8D7D56C6ED3DD411998D009027DC685E0874E1A3@srv-grp-s1.segin.com> From: =?iso-8859-1?Q?Brasseur_Val=E9ry?= To: "'linux-xfs@oss.sgi.com'" Subject: xfs undelete problems Date: Mon, 29 Jul 2002 12:02:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am running 2.4.18 + xfs thisq week-end one of my XFS partition got full ! trying to do some cleanup in it I got an I/O error, then xfs did a shutdown ! and now i got this : Starting XFS recovery on filesystem: ida0(72,17) (dev: 72/17) xfs_iunlink_remove: XFS_TEST_ERROR() returned an error on ida0(72,17). Returning EFSCORRUPTED. xfs_inactive: xfs_ifree() returned an error = 990 on ida0(72,17) xfs_force_shutdown(ida0(72,17),0x1) called from line 1962 of file xfs_vnodeops.c. Return address = 0xc01d4d42 I/O Error Detected. Shutting down filesystem: ida0(72,17) Please umount the filesystem, and rectify the problem(s) Ending XFS recovery on filesystem: ida0(72,17) (dev: 72/17) and the xfs log is as this : xfs_logprint: data device: 0x4811 log device: 0x4811 daddr: 5120416 length: 65536 log tail: 51795 head: 51842 state: LOG REC AT LSN cycle 12663 block 51795 (0x3177, 0xca53) ============================================================================ TRANS: tid:0xdc895230 type:MKDIR #items:5 trans:0x0 q:0x808ae80 BUF: cnt:2 total:2 a:0x808aea0 len:24 a:0x808aed8 len:128 BUF: #regs:2 start blkno:0x138862 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808af60 len:28 a:0x808afb8 len:128 BUF: #regs:2 start blkno:0x13a780 len:8 bmap size:2 BUF DATA INO: cnt:3 total:3 a:0x808b040 len:52 a:0x808b0b8 len:96 a:0x808b120 len:8 INODE: #regs:3 ino:0x409de9 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: INO: cnt:3 total:3 a:0x808b130 len:52 a:0x808b1a8 len:96 a:0x808b210 len:36 INODE: #regs:3 ino:0x80 flags:0x3 dsize:36 CORE inode: DATA FORK LOCAL inode data: BUF: cnt:2 total:2 a:0x808b238 len:24 a:0x808b290 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xe3b0d7f8 type:MKDIR #items:5 trans:0x0 q:0x808ae98 BUF: cnt:2 total:2 a:0x808aeb8 len:24 a:0x808aef0 len:128 BUF: #regs:2 start blkno:0x2710c2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808af78 len:28 a:0x808afd0 len:128 BUF: #regs:2 start blkno:0x2765d0 len:8 bmap size:2 BUF DATA INO: cnt:3 total:3 a:0x808b058 len:52 a:0x808b0d0 len:96 a:0x808b138 len:8 INODE: #regs:3 ino:0x9c187b flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: INO: cnt:3 total:3 a:0x808b148 len:52 a:0x808b1c0 len:96 a:0x808b228 len:20 INODE: #regs:3 ino:0x409de9 flags:0x3 dsize:20 CORE inode: DATA FORK LOCAL inode data: BUF: cnt:2 total:2 a:0x808b240 len:24 a:0x808b298 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xe3b0dc80 type:SETATTR #items:1 trans:0x0 q:0x808aeb0 INO: cnt:3 total:3 a:0x808aed0 len:52 a:0x808af28 len:96 a:0x808af90 len:8 INODE: #regs:3 ino:0x9c187b flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xf4ca6190 type:SETATTR #items:1 trans:0x0 q:0x808aec8 INO: cnt:3 total:3 a:0x808aee8 len:52 a:0x808af40 len:96 a:0x808afa8 len:8 INODE: #regs:3 ino:0x9c187b flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xf4ca6550 type:MKDIR #items:5 trans:0x0 q:0x808aee0 BUF: cnt:2 total:2 a:0x808af00 len:24 a:0x808af38 len:128 BUF: #regs:2 start blkno:0x3a9922 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808afc0 len:28 a:0x808b018 len:128 BUF: #regs:2 start blkno:0x3a9938 len:8 bmap size:2 BUF DATA INO: cnt:3 total:3 a:0x808b0a0 len:52 a:0x808b118 len:96 a:0x808b180 len:8 INODE: #regs:3 ino:0xc002b0 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: INO: cnt:3 total:3 a:0x808b190 len:52 a:0x808b208 len:96 a:0x808b270 len:32 INODE: #regs:3 ino:0x409de9 flags:0x3 dsize:32 CORE inode: DATA FORK LOCAL inode data: BUF: cnt:2 total:2 a:0x808b298 len:24 a:0x808b2f0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xe3b0d9b0 type:SETATTR #items:1 trans:0x0 q:0x808aef8 INO: cnt:3 total:3 a:0x808af18 len:52 a:0x808af70 len:96 a:0x808afd8 len:8 INODE: #regs:3 ino:0xc002b0 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xdc895118 type:SETATTR #items:1 trans:0x0 q:0x808af10 INO: cnt:3 total:3 a:0x808af30 len:52 a:0x808af88 len:96 a:0x808aff0 len:8 INODE: #regs:3 ino:0xc002b0 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xf4ca6d70 type:MKDIR #items:5 trans:0x0 q:0x808af28 BUF: cnt:2 total:2 a:0x808af48 len:24 a:0x808af80 len:128 BUF: #regs:2 start blkno:0x4e2182 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b008 len:28 a:0x808b060 len:128 BUF: #regs:2 start blkno:0x4e2198 len:8 bmap size:2 BUF DATA INO: cnt:3 total:3 a:0x808b0e8 len:52 a:0x808b160 len:96 a:0x808b1c8 len:8 INODE: #regs:3 ino:0x1020044 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: INO: cnt:3 total:3 a:0x808b1d8 len:52 a:0x808b250 len:96 a:0x808b2b8 len:48 INODE: #regs:3 ino:0x409de9 flags:0x3 dsize:48 CORE inode: DATA FORK LOCAL inode data: BUF: cnt:2 total:2 a:0x808b2f0 len:24 a:0x808b348 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xf4ca6370 type:SETATTR #items:1 trans:0x0 q:0x808af40 INO: cnt:3 total:3 a:0x808af60 len:52 a:0x808afb8 len:96 a:0x808b020 len:8 INODE: #regs:3 ino:0x1020044 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xf4ca6938 type:SETATTR #items:1 trans:0x0 q:0x808af58 INO: cnt:3 total:3 a:0x808af78 len:52 a:0x808afd0 len:96 a:0x808b038 len:8 INODE: #regs:3 ino:0x1020044 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xe3b0d910 type:MKDIR #items:6 trans:0x0 q:0x808af70 BUF: cnt:2 total:2 a:0x808af90 len:24 a:0x808afc8 len:128 BUF: #regs:2 start blkno:0x61a9e2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b050 len:28 a:0x808b0a8 len:128 BUF: #regs:2 start blkno:0x61ae78 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808b130 len:28 a:0x808b188 len:128 BUF: #regs:2 start blkno:0x61a9f8 len:8 bmap size:2 BUF DATA INO: cnt:3 total:3 a:0x808b210 len:52 a:0x808b288 len:96 a:0x808b2f0 len:8 INODE: #regs:3 ino:0x1400082 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: INO: cnt:3 total:3 a:0x808b300 len:52 a:0x808b378 len:96 a:0x808b3e0 len:60 INODE: #regs:3 ino:0x409de9 flags:0x3 dsize:60 CORE inode: DATA FORK LOCAL inode data: BUF: cnt:2 total:2 a:0x808b420 len:24 a:0x808b478 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xe3b0daa0 type:SETATTR #items:1 trans:0x0 q:0x808af88 INO: cnt:3 total:3 a:0x808afa8 len:52 a:0x808b000 len:96 a:0x808b068 len:8 INODE: #regs:3 ino:0x1400082 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xdc895028 type:SETATTR #items:1 trans:0x0 q:0x808afa0 INO: cnt:3 total:3 a:0x808afc0 len:52 a:0x808b018 len:96 a:0x808b080 len:8 INODE: #regs:3 ino:0x1400082 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xf4ca6910 type:MKDIR #items:5 trans:0x0 q:0x808afb8 BUF: cnt:2 total:2 a:0x808afd8 len:24 a:0x808b010 len:128 BUF: #regs:2 start blkno:0x753242 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b098 len:28 a:0x808b0f0 len:128 BUF: #regs:2 start blkno:0x7547b0 len:8 bmap size:2 BUF DATA INO: cnt:3 total:3 a:0x808b178 len:52 a:0x808b1f0 len:96 a:0x808b258 len:8 INODE: #regs:3 ino:0x1818159 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: INO: cnt:3 total:3 a:0x808b268 len:52 a:0x808b2e0 len:96 a:0x808b348 len:76 INODE: #regs:3 ino:0x409de9 flags:0x3 dsize:76 CORE inode: DATA FORK LOCAL inode data: BUF: cnt:2 total:2 a:0x808b398 len:24 a:0x808b3f0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xdc8958c0 type:SETATTR #items:1 trans:0x0 q:0x808afd0 INO: cnt:3 total:3 a:0x808aff0 len:52 a:0x808b048 len:96 a:0x808b0b0 len:8 INODE: #regs:3 ino:0x1818159 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xdc895960 type:SETATTR #items:1 trans:0x0 q:0x808afe8 INO: cnt:3 total:3 a:0x808b008 len:52 a:0x808b060 len:96 a:0x808b0c8 len:8 INODE: #regs:3 ino:0x1818159 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xdc895870 type:MKDIR #items:5 trans:0x0 q:0x808b000 BUF: cnt:2 total:2 a:0x808b020 len:24 a:0x808b058 len:128 BUF: #regs:2 start blkno:0x88baa2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b0e0 len:28 a:0x808b138 len:128 BUF: #regs:2 start blkno:0x88bab8 len:8 bmap size:2 BUF DATA INO: cnt:3 total:3 a:0x808b1c0 len:52 a:0x808b238 len:96 a:0x808b2a0 len:8 INODE: #regs:3 ino:0x1c001e9 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: INO: cnt:3 total:3 a:0x808b2b0 len:52 a:0x808b328 len:96 a:0x808b390 len:88 INODE: #regs:3 ino:0x409de9 flags:0x3 dsize:88 CORE inode: DATA FORK LOCAL inode data: BUF: cnt:2 total:2 a:0x808b3f0 len:24 a:0x808b448 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xe3b0dfc8 type:SETATTR #items:1 trans:0x0 q:0x808b018 INO: cnt:3 total:3 a:0x808b038 len:52 a:0x808b090 len:96 a:0x808b0f8 len:8 INODE: #regs:3 ino:0x1c001e9 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: ============================================================================ TRANS: tid:0xe3b0d780 type:SETATTR #items:1 trans:0x0 q:0x808b030 INO: cnt:3 total:3 a:0x808b050 len:52 a:0x808b0a8 len:96 a:0x808b110 len:8 INODE: #regs:3 ino:0x1c001e9 flags:0x3 dsize:8 CORE inode: DATA FORK LOCAL inode data: LOG REC AT LSN cycle 12663 block 51816 (0x3177, 0xca68) ============================================================================ TRANS: tid:0xe3b0d640 type:RMDIR #items:3 trans:0x0 q:0x808b048 INO: cnt:3 total:3 a:0x808b068 len:52 a:0x808b0c0 len:96 a:0x808b128 len:128 INODE: #regs:3 ino:0x409dc4 flags:0x3 dsize:128 CORE inode: DATA FORK LOCAL inode data: INO: cnt:2 total:2 a:0x808b1b0 len:52 a:0x808b220 len:96 INODE: #regs:2 ino:0x9c1844 flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b288 len:24 a:0x808b2e0 len:128 BUF: #regs:2 start blkno:0x2710c2 len:1 bmap size:1 AGI Buffer: (XAGI) ============================================================================ TRANS: tid:0xe3b0d2a8 type:INACTIVE #items:4 trans:0x0 q:0x808b060 INO: cnt:2 total:2 a:0x808b080 len:52 a:0x808b0d0 len:96 INODE: #regs:2 ino:0x9c1844 flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b138 len:24 a:0x808b190 len:128 BUF: #regs:2 start blkno:0x2710c2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b218 len:28 a:0x808b270 len:128 BUF: #regs:2 start blkno:0x2765d0 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808b2f8 len:24 a:0x808b350 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xdc8954d8 type:RMDIR #items:3 trans:0x0 q:0x808b078 INO: cnt:3 total:3 a:0x808b098 len:52 a:0x808b0f0 len:96 a:0x808b158 len:120 INODE: #regs:3 ino:0x409dc4 flags:0x3 dsize:120 CORE inode: DATA FORK LOCAL inode data: INO: cnt:2 total:2 a:0x808b1d8 len:52 a:0x808b248 len:96 INODE: #regs:2 ino:0xc199e4 flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b2b0 len:24 a:0x808b308 len:128 BUF: #regs:2 start blkno:0x3a9922 len:1 bmap size:1 BUF DATA ============================================================================ TRANS: tid:0xdc895348 type:INACTIVE #items:4 trans:0x0 q:0x808b090 INO: cnt:2 total:2 a:0x808b0b0 len:52 a:0x808b100 len:96 INODE: #regs:2 ino:0xc199e4 flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b168 len:24 a:0x808b1c0 len:256 BUF: #regs:2 start blkno:0x3a9922 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b2c8 len:28 a:0x808b320 len:128 BUF: #regs:2 start blkno:0x3aacb8 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808b3a8 len:24 a:0x808b400 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xe3b0da00 type:RMDIR #items:3 trans:0x0 q:0x808b0a8 INO: cnt:3 total:3 a:0x808b0c8 len:52 a:0x808b120 len:96 a:0x808b188 len:112 INODE: #regs:3 ino:0x409dc4 flags:0x3 dsize:112 CORE inode: DATA FORK LOCAL inode data: INO: cnt:2 total:2 a:0x808b200 len:52 a:0x808b270 len:96 INODE: #regs:2 ino:0x24003e7 flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b2d8 len:24 a:0x808b330 len:128 BUF: #regs:2 start blkno:0xafcb62 len:1 bmap size:1 BUF DATA ============================================================================ TRANS: tid:0xe3b0dd20 type:INACTIVE #items:4 trans:0x0 q:0x808b0c0 INO: cnt:2 total:2 a:0x808b0e0 len:52 a:0x808b130 len:96 INODE: #regs:2 ino:0x24003e7 flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b198 len:24 a:0x808b1f0 len:256 BUF: #regs:2 start blkno:0xafcb62 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b2f8 len:28 a:0x808b350 len:128 BUF: #regs:2 start blkno:0xafcb78 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808b3d8 len:24 a:0x808b430 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xe3b0d6b8 type:RMDIR #items:3 trans:0x0 q:0x808b0d8 INO: cnt:3 total:3 a:0x808b0f8 len:52 a:0x808b150 len:96 a:0x808b1b8 len:104 INODE: #regs:3 ino:0x409dc4 flags:0x3 dsize:104 CORE inode: DATA FORK LOCAL inode data: INO: cnt:2 total:2 a:0x808b228 len:52 a:0x808b298 len:96 INODE: #regs:2 ino:0x280018a flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b300 len:24 a:0x808b358 len:128 BUF: #regs:2 start blkno:0xc353c2 len:1 bmap size:1 AGI Buffer: (XAGI) ============================================================================ TRANS: tid:0xdc895d98 type:INACTIVE #items:4 trans:0x0 q:0x808b0f0 INO: cnt:2 total:2 a:0x808b110 len:52 a:0x808b160 len:96 INODE: #regs:2 ino:0x280018a flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b1c8 len:24 a:0x808b220 len:128 BUF: #regs:2 start blkno:0xc353c2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b2a8 len:28 a:0x808b300 len:128 BUF: #regs:2 start blkno:0xc353d8 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808b388 len:24 a:0x808b3e0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xf4ca6528 type:RMDIR #items:3 trans:0x0 q:0x808b108 INO: cnt:3 total:3 a:0x808b128 len:52 a:0x808b180 len:96 a:0x808b1e8 len:96 INODE: #regs:3 ino:0x409dc4 flags:0x3 dsize:96 CORE inode: DATA FORK LOCAL inode data: INO: cnt:2 total:2 a:0x808b250 len:52 a:0x808b2c0 len:96 INODE: #regs:2 ino:0x86970 flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b328 len:24 a:0x808b380 len:128 BUF: #regs:2 start blkno:0x2 len:1 bmap size:1 BUF DATA ============================================================================ TRANS: tid:0xe3b0d848 type:INACTIVE #items:4 trans:0x0 q:0x808b120 INO: cnt:2 total:2 a:0x808b140 len:52 a:0x808b190 len:96 INODE: #regs:2 ino:0x86970 flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b1f8 len:24 a:0x808b250 len:256 BUF: #regs:2 start blkno:0x2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b358 len:28 a:0x808b3b0 len:128 BUF: #regs:2 start blkno:0x130 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808b438 len:24 a:0x808b490 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xf4ca6488 type:RMDIR #items:3 trans:0x0 q:0x808b138 INO: cnt:3 total:3 a:0x808b158 len:52 a:0x808b1b0 len:96 a:0x808b218 len:88 INODE: #regs:3 ino:0x409dc4 flags:0x3 dsize:88 CORE inode: DATA FORK LOCAL inode data: INO: cnt:2 total:2 a:0x808b278 len:52 a:0x808b2e8 len:96 INODE: #regs:2 ino:0x140f3ae flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b350 len:24 a:0x808b3a8 len:128 BUF: #regs:2 start blkno:0x61a9e2 len:1 bmap size:1 BUF DATA ============================================================================ TRANS: tid:0xe3b0d1b8 type:INACTIVE #items:4 trans:0x0 q:0x808b150 INO: cnt:2 total:2 a:0x808b170 len:52 a:0x808b1c0 len:96 INODE: #regs:2 ino:0x140f3ae flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b228 len:24 a:0x808b280 len:256 BUF: #regs:2 start blkno:0x61a9e2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b388 len:28 a:0x808b3e0 len:128 BUF: #regs:2 start blkno:0x61ae70 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808b468 len:24 a:0x808b4c0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xf4ca69b0 type:RMDIR #items:3 trans:0x0 q:0x808b168 INO: cnt:3 total:3 a:0x808b188 len:52 a:0x808b1e0 len:96 a:0x808b248 len:80 INODE: #regs:3 ino:0x409dc4 flags:0x3 dsize:80 CORE inode: DATA FORK LOCAL inode data: INO: cnt:2 total:2 a:0x808b2a0 len:52 a:0x808b310 len:96 INODE: #regs:2 ino:0x380060e flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b378 len:24 a:0x808b3d0 len:128 BUF: #regs:2 start blkno:0x1117542 len:1 bmap size:1 AGI Buffer: (XAGI) ============================================================================ TRANS: tid:0xdc895898 type:INACTIVE #items:4 trans:0x0 q:0x808b180 INO: cnt:2 total:2 a:0x808b1a0 len:52 a:0x808b1f0 len:96 INODE: #regs:2 ino:0x380060e flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b258 len:24 a:0x808b2b0 len:128 BUF: #regs:2 start blkno:0x1117542 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b338 len:28 a:0x808b390 len:128 BUF: #regs:2 start blkno:0x1117558 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808b418 len:24 a:0x808b470 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xdc895d20 type:RMDIR #items:3 trans:0x0 q:0x808b198 INO: cnt:3 total:3 a:0x808b1b8 len:52 a:0x808b210 len:96 a:0x808b278 len:72 INODE: #regs:3 ino:0x409dc4 flags:0x3 dsize:72 CORE inode: DATA FORK LOCAL inode data: INO: cnt:2 total:2 a:0x808b2c8 len:52 a:0x808b338 len:96 INODE: #regs:2 ino:0x9c184f flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b3a0 len:24 a:0x808b3f8 len:128 BUF: #regs:2 start blkno:0x2710c2 len:1 bmap size:1 AGI Buffer: (XAGI) ============================================================================ TRANS: tid:0xdc895b40 type:INACTIVE #items:4 trans:0x0 q:0x808b1b0 INO: cnt:2 total:2 a:0x808b1d0 len:52 a:0x808b220 len:96 INODE: #regs:2 ino:0x9c184f flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b288 len:24 a:0x808b2e0 len:128 BUF: #regs:2 start blkno:0x2710c2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x808b368 len:28 a:0x808b3c0 len:128 BUF: #regs:2 start blkno:0x2765d0 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808b448 len:24 a:0x808b4a0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xdc895e60 type:RMDIR #items:3 trans:0x0 q:0x808b1c8 INO: cnt:3 total:3 a:0x808b1e8 len:52 a:0x808b240 len:96 a:0x808b2a8 len:64 INODE: #regs:3 ino:0x409dc4 flags:0x3 dsize:64 CORE inode: DATA FORK LOCAL inode data: INO: cnt:2 total:2 a:0x808b2f0 len:52 a:0x808b360 len:96 INODE: #regs:2 ino:0x2001370 flags:0x1 dsize:0 CORE inode: BUF: cnt:2 total:2 a:0x808b3c8 len:24 a:0x808b420 len:128 BUF: #regs:2 start blkno:0x9c4302 len:1 bmap size:1 BUF DATA getting an log error after this last entry ! did someone can help me ? thanks valery From owner-linux-xfs@oss.sgi.com Mon Jul 29 07:19:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6TEJ1Rw002134 for ; Mon, 29 Jul 2002 07:19:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6TEJ1Lq002133 for linux-xfs-outgoing; Mon, 29 Jul 2002 07:19:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6TEIsRw002102 for ; Mon, 29 Jul 2002 07:18:54 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA37668; Mon, 29 Jul 2002 09:20:08 -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 JAA91157; Mon, 29 Jul 2002 09:20:08 -0500 (CDT) Date: Mon, 29 Jul 2002 09:17:03 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: =?iso-8859-1?Q?Brasseur_Val=E9ry?= cc: "'linux-xfs@oss.sgi.com'" Subject: Re: xfs undelete problems In-Reply-To: <8D7D56C6ED3DD411998D009027DC685E0874E1A3@srv-grp-s1.segin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by zeus-e8.americas.sgi.com id JAA37668 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6TEItRw002103 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 29 Jul 2002, Brasseur Valéry wrote: > I am running 2.4.18 + xfs > > thisq week-end one of my XFS partition got full ! trying to do some cleanup > in it I got > an I/O error, then xfs did a shutdown ! What messages were in your system log just prior to the shutdown? > and now i got this : > > Starting XFS recovery on filesystem: ida0(72,17) (dev: 72/17) > xfs_iunlink_remove: XFS_TEST_ERROR() returned an error on ida0(72,17). > Returning EFSCORRUPTED. > xfs_inactive: xfs_ifree() returned an error = 990 on ida0(72,17) > xfs_force_shutdown(ida0(72,17),0x1) called from line 1962 of file > xfs_vnodeops.c. Return address = 0xc01d4d42 > I/O Error Detected. Shutting down filesystem: ida0(72,17) > Please umount the filesystem, and rectify the problem(s) > Ending XFS recovery on filesystem: ida0(72,17) (dev: 72/17) So, you got a shutdown on a live filesystem, and now when you try to re-mount it, you also get another shutdown during log recovery? -Eric From owner-linux-xfs@oss.sgi.com Mon Jul 29 07:37:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6TEb1Rw006868 for ; Mon, 29 Jul 2002 07:37:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6TEb13Y006867 for linux-xfs-outgoing; Mon, 29 Jul 2002 07:37:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hermes7.axime.com (hermes7.atos-group.com [160.92.18.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6TEapRw005301 for ; Mon, 29 Jul 2002 07:36:52 -0700 Received: by hermes7.atos-group.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 16:38:04 +0200 Message-ID: <8D7D56C6ED3DD411998D009027DC685E0874E1AE@srv-grp-s1.segin.com> From: =?iso-8859-1?Q?Brasseur_Val=E9ry?= To: "'Eric Sandeen'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: xfs undelete problems Date: Mon, 29 Jul 2002 16:38:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6TEaqRw006839 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Monday, July 29, 2002 4:17 PM > To: Brasseur Valéry > Cc: 'linux-xfs@oss.sgi.com' > Subject: Re: xfs undelete problems > > > On Mon, 29 Jul 2002, Brasseur Valéry wrote: > > > I am running 2.4.18 + xfs > > > > thisq week-end one of my XFS partition got full ! trying to > do some cleanup > > in it I got > > an I/O error, then xfs did a shutdown ! > > What messages were in your system log just prior to the shutdown? as far as I can see, nothing special ! > > > and now i got this : > > > > Starting XFS recovery on filesystem: ida0(72,17) (dev: 72/17) > > xfs_iunlink_remove: XFS_TEST_ERROR() returned an error on > ida0(72,17). > > Returning EFSCORRUPTED. > > xfs_inactive: xfs_ifree() returned an error = 990 on ida0(72,17) > > xfs_force_shutdown(ida0(72,17),0x1) called from line 1962 of file > > xfs_vnodeops.c. Return address = 0xc01d4d42 > > I/O Error Detected. Shutting down filesystem: ida0(72,17) > > Please umount the filesystem, and rectify the problem(s) > > Ending XFS recovery on filesystem: ida0(72,17) (dev: 72/17) > > So, you got a shutdown on a live filesystem, and now when you > try to re-mount it, you also get another shutdown during log recovery? > > -Eric > yes I have try to remount it : same message, I try a repair but did'nt look Ok ! now I don't know whate to do ! thanks From owner-linux-xfs@oss.sgi.com Mon Jul 29 07:50:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6TEoPRw012397 for ; Mon, 29 Jul 2002 07:50:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6TEoPv3012396 for linux-xfs-outgoing; Mon, 29 Jul 2002 07:50:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6TEoIRw012367 for ; Mon, 29 Jul 2002 07:50:18 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA42848; Mon, 29 Jul 2002 09:51:35 -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 JAA25091; Mon, 29 Jul 2002 09:51:35 -0500 (CDT) Subject: RE: xfs undelete problems From: Eric Sandeen To: Brasseur =?ISO-8859-1?Q?Val=E9ry?= Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <8D7D56C6ED3DD411998D009027DC685E0874E1AE@srv-grp-s1.segin.com> References: <8D7D56C6ED3DD411998D009027DC685E0874E1AE@srv-grp-s1.segin.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 29 Jul 2002 09:48:31 -0500 Message-Id: <1027954111.24296.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6TEoJRw012368 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-07-29 at 09:38, Brasseur Valéry wrote: > > What messages were in your system log just prior to the shutdown? > > as far as I can see, nothing special ! Hm, well, there should be at least a message stating that it's shutting down - and probably which file called the shutdown. These problems can be hard to debug, but the more information the better... > yes I have try to remount it : same message, I try a repair but did'nt look > Ok ! > now I don't know whate to do ! As a last resort, you might try the -L option in xfs_repair, which will zero out your log - but you will lose information this way: -L Force Log Zeroing. Forces xfs_repair to zero the log even if it is dirty (contains metadata changes). When using this option the filesystem will likely appear to be corrupt, and can cause the loss of user files and/or data. Before you do this, you might wait to see if anyone else chimes in with other ideas, but I'm afraid I don't have a better one at the moment. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Jul 29 11:59:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6TIxZRw018533 for ; Mon, 29 Jul 2002 11:59:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6TIxZAk018532 for linux-xfs-outgoing; Mon, 29 Jul 2002 11:59:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6TIxSRw018504 for ; Mon, 29 Jul 2002 11:59:28 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA43800 for ; Mon, 29 Jul 2002 14:00:46 -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 OAA71308 for ; Mon, 29 Jul 2002 14:00:45 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6TIvdk27930; Mon, 29 Jul 2002 13:57:39 -0500 Message-Id: <200207291857.g6TIvdk27930@stout.americas.sgi.com> Date: Mon, 29 Jul 2002 13:57:39 -0500 Subject: TAKE - Tidy up mount args & parsing X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some tweaks to v2 log logbsize specification, also remove some duplicate bounds checking on other mount options. Date: Mon Jul 29 11:59:37 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123857a linux/fs/xfs/xfs_log.c - 1.251 - Don't automatically size down logbsize in v1 logs; let large iclogs on v1 logs fail later on. linux/fs/xfs/xfs_vfsops.c - 1.364 - Make mount failure messages a little more informative, like they were in xfs_parseargs before those got removed. linux/fs/xfs/linux/xfs_super.c - 1.201 - Allow logbsize to be specified in kilobytes Remove bounds checks for logbsize,logbufs,iosize that are duplicated in xfs_cmountfs. Don't allow "logbufs=none" option & subsequent fs trashing! linux/Documentation/filesystems/xfs.txt - 1.10 - Document specification of logbsize in kilobytes From owner-linux-xfs@oss.sgi.com Mon Jul 29 17:23:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6U0NbRw030285 for ; Mon, 29 Jul 2002 17:23:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6U0NbxW030284 for linux-xfs-outgoing; Mon, 29 Jul 2002 17:23:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6U0NWRw030255 for ; Mon, 29 Jul 2002 17:23:32 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.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 RAA01841 for ; Mon, 29 Jul 2002 17:24:44 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g6TNE1QR16236212 for ; Mon, 29 Jul 2002 16:14:01 -0700 (PDT) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA11394; Tue, 30 Jul 2002 09:13:31 +1000 (EST) Date: Tue, 30 Jul 2002 09:13:31 +1000 (EST) From: Nathan Scott Message-Id: <200207292313.JAA11394@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: sandeen@sgi.com, agruen@suse.de Subject: TAKE - xattr locking X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jul 29 16:10:14 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:123886a linux/fs/xattr.c - 1.8 - Sync up with AndreasG re locking. Mail from AG: we were "taking the BKL first, and then i_sem. This is a bit dangerous, and will lead to deadlocks on SMP machines, if another processor is holding i_sem." From owner-linux-xfs@oss.sgi.com Mon Jul 29 20:35:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6U3Z7Rw032211 for ; Mon, 29 Jul 2002 20:35:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6U3Z7sV032210 for linux-xfs-outgoing; Mon, 29 Jul 2002 20:35:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6U3Z0Rw032180 for ; Mon, 29 Jul 2002 20:35:00 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 UAA09497 for ; Mon, 29 Jul 2002 20:36:22 -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 NAA39653 for linux-xfs@oss.sgi.com; Tue, 30 Jul 2002 13:35:03 +1000 (EST) Date: Tue, 30 Jul 2002 13:35:03 +1000 (EST) From: Nathan Scott Message-Id: <200207300335.NAA39653@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - invutil X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Minor updates to the new invutil code - fixes QA and compiles cleanly on 64 bit machines. Date: Mon Jul 29 18:24:34 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:123899a xfstests/028.out - 1.6 - there's an extra message on matching with invutil now - add it in. Date: Mon Jul 29 20:33:24 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:123908a xfsdump/VERSION - 1.36 xfsdump/doc/CHANGES - 1.44 xfsdump/debian/changelog - 1.26 xfsdump/invutil/invutil.c - 1.11 - bump version for updates to invutil for ia64 builds. From owner-linux-xfs@oss.sgi.com Mon Jul 29 21:04:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6U44lRw032590 for ; Mon, 29 Jul 2002 21:04:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6U44l5q032589 for linux-xfs-outgoing; Mon, 29 Jul 2002 21:04:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6U44gRw032561 for ; Mon, 29 Jul 2002 21:04:43 -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 VAA02329 for ; Mon, 29 Jul 2002 21:06:40 -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 OAA51596 for linux-xfs@oss.sgi.com; Tue, 30 Jul 2002 14:04:50 +1000 (EST) Date: Tue, 30 Jul 2002 14:04:50 +1000 (EST) From: Nathan Scott Message-Id: <200207300404.OAA51596@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ia64 warning fixes X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jul 29 21:04:20 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:123910a cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.33 cmd/xfsdump/restore/content.c - 1.24 cmd/xfsdump/invutil/stobj.c - 1.2 - fix compiler warnings from builds for 64 bit processors. From owner-linux-xfs@oss.sgi.com Mon Jul 29 22:23:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6U5NiRw000857 for ; Mon, 29 Jul 2002 22:23:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6U5NiqJ000856 for linux-xfs-outgoing; Mon, 29 Jul 2002 22:23:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bittersweet.intra.hegbloom.net (ns.hegbloom.net [63.105.27.231]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6U5NSRw000826 for ; Mon, 29 Jul 2002 22:23:28 -0700 Received: from bittersweet.intra.hegbloom.net (localhost.localnet [127.0.0.1]) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g6U5OocR019781 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 29 Jul 2002 22:24:50 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) id g6U5OnAp019777; Mon, 29 Jul 2002 22:24:49 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f To: Seth Mos Cc: Stephen Lord , XFS , EVMS Devel Subject: Re: [Evms-devel] Re: "Invalid client ID" after system lockup and subsequent reset ? References: <20020728004219.K60206-100000@xs1.xs4all.nl> From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 29 Jul 2002 22:24:49 -0700 In-Reply-To: <20020728004219.K60206-100000@xs1.xs4all.nl> Message-ID: <878z3teqji.fsf@bittersweet.intra.hegbloom.net> Lines: 96 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos writes: > On 27 Jul 2002, Karl M. Hegbloom wrote: > > > Seth Mos writes: > > > > > Clearing the log was enough to make it mount again. I saw this > > > about 3 times. After upgrading to a later kernel I never saw the > > > problem again. The problem was no present with earlier kernels > > > either. > > > > Do you use EVMS? > > No but the issue was that playing back recovery from the low was > hanging. If I understand correctly EVMS is a layer underneath the > filessytem and this could mean that there is something in the log > which the recovery code has a tough time with. Wrong; that's just one result of the real problem that I reported. (Please go back and read my report again) I'm complaining that when I compile large software systems, and there's a lot of disk activity, my computer locks up. It behaves, IMO, as though there is a deadlock in the file system code. Programs that are already running keep going, but I cannot launch new ones or do anything that requires access to the filesystem. I have no recourse but to press the reset button, and at reboot, the log replay error happens. No wonder; it cannot write the log entry and then gets interrupted by a hardware reset while it's waiting for the deadlock to end? I wonder if it's an SMP + XFS + EVMS (or any combination involving SMP) issue, so I wrote to these lists to see if anyone knows what's the matter. It occurs to me that you may need more information... I'm running a Debian 2.4.18 kernel image with (can I get the XFS and EVMS version numbers from the running kernel somehow? If not, please make that possible... Ah, yes, dmesg... Alright, Mr. XFS? Will you PLEASE make it print a version number at boot?) patches supplied by Debian packages. IIRC, it was more than two months ago that I built the kernel I am running now, which displays the buggy behavior. (The last try with fresh patches would not boot due to the unaligned access bug you already know about.) The machine was originally configured with LVM, then I switched to EVMS. evms: EVMS v1.0.1 initializing .... info level(5). evms: object detected, deleting 'lvm/bittersweet/snapshot_area'. evms: Exporting EVMS Volume(63,255) from "/dev/evms/quota_tests". evms: Exporting EVMS Volume(63,254) from "/dev/evms/mirror". evms: Exporting EVMS Volume(63,253) from "/dev/evms/opt". evms: Exporting EVMS Volume(63,1) from "/dev/evms/hdg1". evms: Exporting EVMS Volume(63,2) from "/dev/evms/hde1". evms: Exporting EVMS Volume(63,3) from "/dev/evms/hda1". evms: Exporting EVMS Volume(63,4) from "/dev/evms/hda2". evms: Exporting EVMS Volume(63,5) from "/dev/evms/lvm/bittersweet/slash". evms: Exporting EVMS Volume(63,6) from "/dev/evms/lvm/bittersweet/home". evms: Exporting EVMS Volume(63,7) from "/dev/evms/lvm/bittersweet/src". evms: Exporting EVMS Volume(63,8) from "/dev/evms/lvm/bittersweet/usr_local". evms: Exporting EVMS Volume(63,9) from "/dev/evms/lvm/bittersweet/var". evms: Exporting EVMS Volume(63,10) from "/dev/evms/lvm/bittersweet/usr". SGI XFS with ACLs, DMAPI, realtime, quota, no debug enabled ... XFS mounting filesystem ide0(3,1) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: ide0(3,1) (dev: 3/1) hub.c: USB new device connect on bus1/2, assigned device number 3 Ending XFS recovery on filesystem: ide0(3,1) (dev: 3/1) VFS: Mounted root (xfs filesystem) readonly. ... XFS mounting filesystem evms(63,10) Starting XFS recovery on filesystem: evms(63,10) (dev: 63/10) Ending XFS recovery on filesystem: evms(63,10) (dev: 63/10) XFS mounting filesystem evms(63,9) Starting XFS recovery on filesystem: evms(63,9) (dev: 63/9) Ending XFS recovery on filesystem: evms(63,9) (dev: 63/9) XFS mounting filesystem evms(63,8) XFS mounting filesystem evms(63,7) Starting XFS recovery on filesystem: evms(63,7) (dev: 63/7) Ending XFS recovery on filesystem: evms(63,7) (dev: 63/7) XFS mounting filesystem evms(63,6) Starting XFS recovery on filesystem: evms(63,6) (dev: 63/6) Ending XFS recovery on filesystem: evms(63,6) (dev: 63/6) XFS mounting filesystem evms(63,254) XFS mounting filesystem evms(63,253) -- As any limb well and duly exercised, grows stronger, the nerves of the body are corroborated thereby. --I. Watts. .''`. We are deB.ORG; You will be freed. : :' : `. `' From owner-linux-xfs@oss.sgi.com Mon Jul 29 22:46:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6U5kGRw001219 for ; Mon, 29 Jul 2002 22:46:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6U5kGS9001218 for linux-xfs-outgoing; Mon, 29 Jul 2002 22:46:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bittersweet.intra.hegbloom.net (ns.hegbloom.net [63.105.27.231]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6U5k6Rw001190 for ; Mon, 29 Jul 2002 22:46:06 -0700 Received: from bittersweet.intra.hegbloom.net (localhost.localnet [127.0.0.1]) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g6U5lRcR022057 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 29 Jul 2002 22:47:27 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) id g6U5lRTU022054; Mon, 29 Jul 2002 22:47:27 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f To: debian-boot@lists.debian.org Cc: XFS Cc: EVMS Devel Subject: Re: Partition tools (Re: debian-installer status -- 2002-07-29) References: <87ofcr6ygx.fsf@arabella.raw.no> <87ofcrf4xl.fsf@bittersweet.intra.hegbloom.net> <20020729062651.GB32137@zombie.inka.de> <20020729130041.GJ8110@alcor.net> <20020729220908.GA701@zombie.inka.de> <20020729224641.GE4952@alcor.net> From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 29 Jul 2002 22:47:27 -0700 In-Reply-To: <20020729224641.GE4952@alcor.net> Message-ID: <874rehephs.fsf@bittersweet.intra.hegbloom.net> Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [Ob-CC: Cc'd just FYI. "d-i" refers to the next generation Debian Installer, which you may view at http://cvs.debian.org/ and discuss in debian-boot@lists.debian.org; also archived there - http.] Matt Zimmerman writes: > I am in complete agreement that we would not want to include EVMS, > XFS or similar in our default kernel unless (or until) they are part > of the official kernel. > > However, I am willing to do some work to support EVMS in d-i, and to > provide EVMS-enabled installation media for those who are interested > in trying it. If I can use this experience to improve volume > management support in d-i, then I would hope that my contributions > would be welcome. I am also interested in an EVMS + XFS (and SMP enabled; give them a choice of kernel images!) enabled install, as well as a totally automatic (perhaps scripted) one. The automatic install should support EVMS too, ideally. Someday it WILL undoubtedly be production quality, and WE'll be the first to have a turnkey installer for a system that utilizes it, if we do this. As I recall, d-i sports a very modular design that should make it possible to give the user a choice of which partitioning tool to pull in off the CD media. They can then choose standard or EVMS, cfdisk, disk druid, or depart (good a name as any?). Yes, at this point in time, EVMS + XFS should certainly be considered experimental. (My present system deadlocks when I compile software; bugs reported to XFS and EVMS lists; I hope they can fix it soon.) It might improve the bugfix and development rate some if more people got exposed to these new features, which may certainly occur if there's an easy way for them to install it and try it on a test box. (You must admit that installing by hand is for experts only.) I wonder if there's any kind of consolidation and reconciliation possible between the EVMS C API and libparted? Both are capable of creating disk partitions... (Sight unseen I cannot say myself; it just occured to me and thus I wonder.) -- As any limb well and duly exercised, grows stronger, the nerves of the body are corroborated thereby. --I. Watts. .''`. We are deB.ORG; You will be freed. : :' : `. `' From owner-linux-xfs@oss.sgi.com Tue Jul 30 01:40:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6U8ePRw002809 for ; Tue, 30 Jul 2002 01:40:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6U8ePnx002808 for linux-xfs-outgoing; Tue, 30 Jul 2002 01:40:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6U8eGRw002777 for ; Tue, 30 Jul 2002 01:40:17 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id SAA02504 for ; Tue, 30 Jul 2002 18:26:09 +0930 Message-ID: <3D465381.69437169@rebel.net.au> Date: Tue, 30 Jul 2002 18:21:13 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: What Does "kernel mtrr" mean... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The lines in /var/log/messages: Jul 29 07:38:22 linux kernel: mtrr: type mismatch for dc000000,100000 old: write-back new: write-combining Jul 29 07:38:22 linux kernel: mtrr: type mismatch for dc000000,200000 old: write-back new: write-combining Jul 29 07:38:22 linux kernel: mtrr: type mismatch for dc000000,400000 old: write-back new: write-combining Jul 29 07:38:22 linux kernel: mtrr: type mismatch for dc000000,800000 old: write-back new: write-combining Jul 29 07:38:22 linux kernel: mtrr: type mismatch for dc000000,1000000 old: write-back new: write-combining uname -a Linux linux 2.4.2-SGI_XFS_1.0 #1 Fri Apr 27 19:30:49 CDT 2001 i686 unknown [it's an ancient, original Athlon) ..I know, an older version and I'm not going to claim it's an XFS bug unless I can reproduce it when(ever) I update to a much newer version but it would be nice to know what that actually "means"... DSL -- At the end of the day you're another day older And the shirt on your back doesn't keep out the chill! (At the End of the Day -- Les Miserables [the musical]) From owner-linux-xfs@oss.sgi.com Tue Jul 30 01:50:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6U8o8Rw003029 for ; Tue, 30 Jul 2002 01:50:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6U8o8Kt003028 for linux-xfs-outgoing; Tue, 30 Jul 2002 01:50:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6U8o3Rw002998 for ; Tue, 30 Jul 2002 01:50:03 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) 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 BAA09699 for ; Tue, 30 Jul 2002 01:52:02 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g6U8oMQR16457483; Tue, 30 Jul 2002 01:50:23 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 181C03000BA; Tue, 30 Jul 2002 18:50:22 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 0A51394; Tue, 30 Jul 2002 18:50:22 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: David Lloyd Cc: linux-xfs@oss.sgi.com Subject: Re: What Does "kernel mtrr" mean... In-reply-to: Your message of "Tue, 30 Jul 2002 18:21:13 +0930." <3D465381.69437169@rebel.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jul 2002 18:50:16 +1000 Message-ID: <25369.1028019016@kao2.melbourne.sgi.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 30 Jul 2002 18:21:13 +0930, David Lloyd wrote: >Jul 29 07:38:22 linux kernel: mtrr: type mismatch for dc000000,100000 >old: write-back new: write-combining >..I know, an older version and I'm not going to claim it's an XFS bug >unless I can reproduce it when(ever) I update to a much newer version >but it would be nice to know what that actually "means"... Documentation/mtrr.txt From owner-linux-xfs@oss.sgi.com Tue Jul 30 04:06:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UB6nRw005217 for ; Tue, 30 Jul 2002 04:06:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UB6njY005216 for linux-xfs-outgoing; Tue, 30 Jul 2002 04:06:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UB6ZRw005185 for ; Tue, 30 Jul 2002 04:06:35 -0700 Received: from offline.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 17ZUr5-0003Qk-00 for linux-xfs@oss.sgi.com; Tue, 30 Jul 2002 12:07:55 +0100 Message-ID: <3D46738B.308AD0BF@moving-picture.com> Date: Tue, 30 Jul 2002 12:07:55 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Unable to handle kernel NULL pointer dereference with 2.4.19-rc3-xfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've just had the following oops with nfsd on an XFS file system using a CVS kernel from July 22nd - not sure if it's XFS or NFS related ... I'm running this kernel as I previous had problems with 2.4.18-xfs-1.1 and nfsd locking up - see: http://marc.theaimsgroup.com/?l=linux-xfs&m=102579948531207&w=2 This time I get similar symptoms, but I guess it may not be related as I get an oops. Thanks James Pearson Unable to handle kernel NULL pointer dereference at virtual address 00000090 c01d4a88 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00000070 ebx: 00000070 ecx: c02d2a8c edx: 00000090 esi: 00000008 edi: 00000008 ebp: f2974d24 esp: f71f9e14 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 1241, stackpage=f71f9000) Stack: ffffffe8 c01a81f6 00000070 00000000 00000000 00000000 f7917c00 f71f9e80 0000000a f7248800 c01c042b f7917c00 00000000 7097d0a1 00000000 00000008 f71f9e60 00000000 00000000 e59c2400 f7917c00 f7320814 f779c400 c01d2d92 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f0 fe 4b 20 0f 88 dc 02 00 00 66 83 7b 06 00 74 3f 0f b7 43 >>EIP; c01d4a88 <===== Trace; c01a81f6 Trace; c01c042b Trace; c01d2d92 Trace; f89d7ed8 <[nfsd]nfsd_get_dentry+28/b0> Trace; f89d831f <[nfsd]find_fh_dentry+3f/340> Trace; f89d8841 <[nfsd]fh_verify+221/420> Trace; f89deff7 <[nfsd]nfsd3_proc_getattr+97/b0> Trace; f89e5fa0 <[nfsd]nfsd_procedures3+20/2c0> Trace; f89d65a7 <[nfsd]nfsd_dispatch+b7/17b> Trace; f89e5fa0 <[nfsd]nfsd_procedures3+20/2c0> Trace; f8995da3 <[sunrpc]svc_process+333/4e8> Trace; f89e5958 <[nfsd]nfsd_version3+0/10> Trace; f89e5978 <[nfsd]nfsd_program+0/18> Trace; f89d63ab <[nfsd]nfsd+20b/350> Trace; c0107296 Trace; f89d61a0 <[nfsd]nfsd+0/350> Code; c01d4a88 00000000 <_EIP>: Code; c01d4a88 <===== 0: f0 fe 4b 20 lock decb 0x20(%ebx) <===== Code; c01d4a8c 4: 0f 88 dc 02 00 00 js 2e6 <_EIP+0x2e6> c01d4d6e <.text.lock.mrlock+24/96> Code; c01d4a92 a: 66 83 7b 06 00 cmpw $0x0,0x6(%ebx) Code; c01d4a97 f: 74 3f je 50 <_EIP+0x50> c01d4ad8 Code; c01d4a99 11: 0f b7 43 00 movzwl 0x0(%ebx),%eax 26 warnings and 3 errors issued. Results may not be reliable. From owner-linux-xfs@oss.sgi.com Tue Jul 30 04:44:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UBipRw005807 for ; Tue, 30 Jul 2002 04:44:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UBipNm005806 for linux-xfs-outgoing; Tue, 30 Jul 2002 04:44:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UBiiRw005777 for ; Tue, 30 Jul 2002 04:44:44 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA50904; Tue, 30 Jul 2002 06:46:04 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-1.corp.sgi.com [134.15.64.1]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA67324; Tue, 30 Jul 2002 06:46:03 -0500 (CDT) Subject: Re: [Evms-devel] Re: "Invalid client ID" after system lockup and subsequent reset ? From: Stephen Lord To: "Karl M. Hegbloom" Cc: Seth Mos , XFS , EVMS Devel In-Reply-To: <878z3teqji.fsf@bittersweet.intra.hegbloom.net> References: <20020728004219.K60206-100000@xs1.xs4all.nl> <878z3teqji.fsf@bittersweet.intra.hegbloom.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 30 Jul 2002 06:43:52 -0500 Message-Id: <1028029434.1121.44.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_SPACES version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-07-30 at 00:24, Karl M. Hegbloom wrote: > > I'm complaining that when I compile large software systems, and > there's a lot of disk activity, my computer locks up. It behaves, > IMO, as though there is a deadlock in the file system code. Programs > that are already running keep going, but I cannot launch new ones or > do anything that requires access to the filesystem. I have no > recourse but to press the reset button, and at reboot, the log replay > error happens. No wonder; it cannot write the log entry and then gets > interrupted by a hardware reset while it's waiting for the deadlock to > end? > > I wonder if it's an SMP + XFS + EVMS (or any combination involving > SMP) issue, so I wrote to these lists to see if anyone knows what's > the matter. > > It occurs to me that you may need more information... I'm running a > Debian 2.4.18 kernel image with (can I get the XFS and EVMS version > numbers from the running kernel somehow? If not, please make that > possible... Ah, yes, dmesg... Alright, Mr. XFS? Will you PLEASE make > it print a version number at boot?) patches supplied by Debian > packages. IIRC, it was more than two months ago that I built the > kernel I am running now, which displays the buggy behavior. (The last > try with fresh patches would not boot due to the unaligned access > bug you already know about.) You say current code will not boot? The problem is you need a much more recent XFS than ones which work in 2.4.18 to function with EVMS. Can you restate the unaligned access error? As for an XFS version, unfortunately the way we release code does not fit well with a version number - I sometimes wonder if we should change this - but it would mean a bunch of work on this end. Steve From owner-linux-xfs@oss.sgi.com Tue Jul 30 04:55:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UBtERw006025 for ; Tue, 30 Jul 2002 04:55:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UBtEtq006024 for linux-xfs-outgoing; Tue, 30 Jul 2002 04:55:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UBt9Rw005996 for ; Tue, 30 Jul 2002 04:55:09 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA48701; Tue, 30 Jul 2002 06:56:30 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-1.corp.sgi.com [134.15.64.1]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA50002; Tue, 30 Jul 2002 06:56:30 -0500 (CDT) Subject: Re: Unable to handle kernel NULL pointer dereference with 2.4.19-rc3-xfs From: Stephen Lord To: James Pearson Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D46738B.308AD0BF@moving-picture.com> References: <3D46738B.308AD0BF@moving-picture.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 30 Jul 2002 06:54:19 -0500 Message-Id: <1028030060.2171.1.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,SUBJ_HAS_SPACES version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-07-30 at 06:07, James Pearson wrote: > I've just had the following oops with nfsd on an XFS file system using a > CVS kernel from July 22nd - not sure if it's XFS or NFS related ... > It looks like XFS, I see a problem, will take a little bit to work out the correct fix. Steve From owner-linux-xfs@oss.sgi.com Tue Jul 30 06:06:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UD6ARw008119 for ; Tue, 30 Jul 2002 06:06:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UD6AQh008118 for linux-xfs-outgoing; Tue, 30 Jul 2002 06:06:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dns.mmm.it ([213.140.0.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UD65Rw008090 for ; Tue, 30 Jul 2002 06:06:06 -0700 Received: from localhost.localdomain ([217.59.125.133]) by dns.mmm.it (Post.Office MTA v3.5.3 release 223 ID# 638-61880U1500L100S0V35) with ESMTP id it for ; Tue, 30 Jul 2002 15:11:12 +0200 Date: Tue, 30 Jul 2002 15:12:42 +0200 From: malcolm.reid@shs.it (Malcolm Reid) To: linux-xfs@oss.sgi.com Subject: DMAPI Tokens? Message-ID: <20020730151242.A1936@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 Lines: 11 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am having a problem with DMAPI, in that I can only ever generate 999 tokens before the DMAPI breaks. For instance, if I have >= 1000 files which have managed regions and I use the sample migin application, everything works fine til the 1000 file, then I get the error wbee: Can't convert sid. Migin itself has executed the command execlp(wbee, wbee, -r, -s, , -t, 1000, 0) This happens every single time, both with the sample app migin and my test app. Closing and reopening the session does not help, I have to reboot to be able to use DMAPI commands again. Is this a problem with linux DMAPI or have I missed something. Thanks. From owner-linux-xfs@oss.sgi.com Tue Jul 30 07:23:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UENTRw010945 for ; Tue, 30 Jul 2002 07:23:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UENTLF010944 for linux-xfs-outgoing; Tue, 30 Jul 2002 07:23:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UENNRw010915 for ; Tue, 30 Jul 2002 07:23:23 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA41098; Tue, 30 Jul 2002 09:24:43 -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 JAA64826; Tue, 30 Jul 2002 09:24:43 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA35716; Tue, 30 Jul 2002 09:24:43 -0500 (CDT) Message-Id: <200207301424.JAA35716@slobber.americas.sgi.com> To: malcolm.reid@shs.it (Malcolm Reid) cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI Tokens? Date: Tue, 30 Jul 2002 09:24:42 -0500 From: Dean Roehrich X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: malcolm.reid@shs.it (Malcolm Reid) >I am having a problem with DMAPI, in that I can only ever generate 999 >tokens before the DMAPI breaks. For instance, if I have >= 1000 files >which have managed regions >and I use the sample migin application, everything works fine til the >1000 file, then I get the error wbee: Can't convert sid. Migin itself >has executed the command >execlp(wbee, wbee, -r, -s, , -t, 1000, 0) This happens every single >time, both with the sample app migin and my test app. Closing and >reopening the session does not help, >I have to reboot to be able to use DMAPI commands again. Is this a >problem with linux DMAPI or have I missed something. Thanks. That execlp line shows that you're missing the arg for -s. The code in wbee.c wants that arg for a sscanf, and that's where the error is coming out. There's nothing in there that points to a token problem. In migin.c, look at spawn_kid(). The size setting for sidbuf[] and tokenbuf[] looks unsafe. In both of them, set their size to a constant, say 10, and try that. If that works, let me know and I'll check it in. Dean From owner-linux-xfs@oss.sgi.com Tue Jul 30 07:30:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UEUHRw011212 for ; Tue, 30 Jul 2002 07:30:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UEUHFi011211 for linux-xfs-outgoing; Tue, 30 Jul 2002 07:30:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blade.4t2.com (blade.4t2.com [194.77.116.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UEU8Rw011183 for ; Tue, 30 Jul 2002 07:30:08 -0700 Received: from mx.sem-gmbh.com ([172.16.11.10]:12416 "EHLO ipsec.blade.4t2.com" ident: "NO-IDENT-SERVICE[2]" smtp-auth: TLS-PEER: ) by blade.4t2.com with ESMTP id ; Tue, 30 Jul 2002 16:31:14 +0200 Received: from sem-dev01.sem-gmbh.com ([194.99.20.211]:63750 "EHLO sem-gmbh.com") by sem-two.sem-gmbh.com with ESMTP id ; Tue, 30 Jul 2002 16:30:49 +0200 Message-ID: <3D46A2E4.8050106@sem-gmbh.com> Date: Tue, 30 Jul 2002 16:29:56 +0200 From: Dirk Munzinger User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.0.0) Gecko/20020530 X-Accept-Language: de, de-at, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs-filesystem is broken after rsync Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hallo, I want to rsync two servers via rsync (2.5.5) but doing this will end in an broken xfs-filesystem... well, the setup is on both server: - kernel 2.4.18 with the latest xfs-patch from the xfs-website - rsync 2.5.5 running with the option -avz The rsync-destionation is an xfs-partition the source an reiserfs-partition and rsync is controlled by a script which starts the run. If the script is executed rsync starts to work just fine but after a few minutes an some MB later suddenly rsync complains about Input/output error. If I go no to the destination-dir and do a ls -l the filesystem seams to be empty but an df says that there are data in the filesystem - the filesystem is broken. If I do now an xfs_repair I get a lot of problems reported but at the end it looks like that the filesystem is still broken because if I start rsync again I get the Input/output-errors just from the start. I have just tried again with an fresh formated xfs filesystem and the problem is still there. If I do now an xfs_repair I get this message (which I have not seen befor) Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. any ideas what is going wrong ? If you need more infos please let me know ! - Dirk From owner-linux-xfs@oss.sgi.com Tue Jul 30 07:44:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UEiCRw011487 for ; Tue, 30 Jul 2002 07:44:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UEiC6g011486 for linux-xfs-outgoing; Tue, 30 Jul 2002 07:44:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UEi4Rw011458 for ; Tue, 30 Jul 2002 07:44:05 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA49509; Tue, 30 Jul 2002 09:45:25 -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 JAA12800; Tue, 30 Jul 2002 09:45:24 -0500 (CDT) Subject: Re: xfs-filesystem is broken after rsync From: Eric Sandeen To: Dirk Munzinger Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D46A2E4.8050106@sem-gmbh.com> References: <3D46A2E4.8050106@sem-gmbh.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 30 Jul 2002 09:42:10 -0500 Message-Id: <1028040131.2511.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-07-30 at 09:29, Dirk Munzinger wrote: > Hallo, > > I want to rsync two servers via rsync (2.5.5) but doing this will end in > an broken xfs-filesystem... Hi Dirk - Take a look in your logs, I'm guessing that the filesystem shut down for some reason. (disk error, memory corruption, etc.) Anything that happens after that would result in the symptoms you're describing. If there's anything interesting in the logs, please forward that to the list. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Jul 30 07:45:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UEjFRw011768 for ; Tue, 30 Jul 2002 07:45:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UEjFhc011767 for linux-xfs-outgoing; Tue, 30 Jul 2002 07:45:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blade.4t2.com (blade.4t2.com [194.77.116.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UEj9Rw011723 for ; Tue, 30 Jul 2002 07:45:09 -0700 Received: from mx.sem-gmbh.com ([172.16.11.10]:19072 "EHLO ipsec.blade.4t2.com" ident: "NO-IDENT-SERVICE[2]" smtp-auth: TLS-PEER: ) by blade.4t2.com with ESMTP id ; Tue, 30 Jul 2002 16:46:21 +0200 Received: from sem-dev01.sem-gmbh.com ([194.99.20.211]:64262 "EHLO sem-gmbh.com") by sem-two.sem-gmbh.com with ESMTP id ; Tue, 30 Jul 2002 16:35:18 +0200 Message-ID: <3D46A3F4.9090604@sem-gmbh.com> Date: Tue, 30 Jul 2002 16:34:28 +0200 From: Dirk Munzinger User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.0.0) Gecko/20020530 X-Accept-Language: de, de-at, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs-filesystem is broken after rsync (log-info) References: <3D46A2E4.8050106@sem-gmbh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I forgot to add the /var/log/message output: kernel: xfs_force_shutdown(ide1(22,68),0x8) called from line 1039 of file xfs_trans.c. R eturn address = 0xd090e6a9 Jul 30 16:24:57 two kernel: Corruption of in-memory data detected. Shutting down filesystem: ide1(22,68) Jul 30 16:24:57 two kernel: Please umount the filesystem, and rectify the problem(s) Jul 30 16:26:53 two kernel: XFS mounting filesystem ide1(22,68) Jul 30 16:26:53 two kernel: Starting XFS recovery on filesystem: ide1(22,68) (dev: 22/68) Jul 30 16:26:54 two kernel: Ending XFS recovery on filesystem: ide1(22,68) (dev: 22/68) That's all. By the way befor I switched the partition to xfs it was formated with reiserfs and there were no problems. The disk itself also seams to be ok. - Dirk From owner-linux-xfs@oss.sgi.com Tue Jul 30 07:54:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UEsPRw012018 for ; Tue, 30 Jul 2002 07:54:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UEsPGW012017 for linux-xfs-outgoing; Tue, 30 Jul 2002 07:54:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from laptop.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UEsLRw011989 for ; Tue, 30 Jul 2002 07:54:21 -0700 Received: (from lord@localhost) by laptop.americas.sgi.com (8.11.6/8.11.6) id g6UErYk01346 for linux-xfs@oss.sgi.com; Tue, 30 Jul 2002 09:53:34 -0500 Date: Tue, 30 Jul 2002 09:53:34 -0500 From: Stephen Lord Message-Id: <200207301453.g6UErYk01346@laptop.americas.sgi.com> Subject: TAKE - clean up a couple more cell defines To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More code cleanup Date: Tue Jul 30 07:55:17 PDT 2002 Workarea: eagdhcp-187-30.americas.sgi.com:/home/lord/src/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:123924a linux/fs/xfs/linux/xfs_vnode.h - 1.55 linux/fs/xfs/linux/xfs_vfs.h - 1.24 From owner-linux-xfs@oss.sgi.com Tue Jul 30 08:04:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UF4qRw012606 for ; Tue, 30 Jul 2002 08:04:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UF4qWI012605 for linux-xfs-outgoing; Tue, 30 Jul 2002 08:04:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UF4kRw012576 for ; Tue, 30 Jul 2002 08:04:47 -0700 Received: from ralf.wg ([192.168.1.2]:1039) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 4.10) id 17ZYZa-0002Nb-00; Tue, 30 Jul 2002 17:06:06 +0200 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Dirk Munzinger" Date: Tue, 30 Jul 2002 17:06:05 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2502) For Windows 2000 (5.0.2195;2) In-Reply-To: <3D46A3F4.9090604@sem-gmbh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: xfs-filesystem is broken after rsync (log-info) Message-Id: X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,GAPPY_TEXT version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 30 Jul 2002 16:34:28 +0200, Dirk Munzinger wrote: >By the way befor I switched the partition to xfs it was formated with >reiserfs and there were no problems. The disk itself also seams to be ok. Well, *seems* to be ok or *is* ok?! I'm asking this since we also had a hell of problems when we tried to migrate our RAID to XFS. It turned out that it wasn't XFS' fault but that the XFS drive was bad... :-(( -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jul 30 08:20:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UFKbRw013248 for ; Tue, 30 Jul 2002 08:20:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UFKbX5013247 for linux-xfs-outgoing; Tue, 30 Jul 2002 08:20:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bittersweet.intra.hegbloom.net (ns.hegbloom.net [63.105.27.231]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UFKSRw013219 for ; Tue, 30 Jul 2002 08:20:29 -0700 Received: from bittersweet.intra.hegbloom.net (localhost.localnet [127.0.0.1]) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g6UFLqcR028389 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 30 Jul 2002 08:21:52 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.5/8.12.5/Debian-1) id g6UFLo9W028384; Tue, 30 Jul 2002 08:21:50 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f To: Stephen Lord Cc: Seth Mos , XFS , EVMS Devel Subject: Re: [Evms-devel] Re: "Invalid client ID" after system lockup and subsequent reset ? References: <20020728004219.K60206-100000@xs1.xs4all.nl> <878z3teqji.fsf@bittersweet.intra.hegbloom.net> <1028029434.1121.44.camel@laptop.americas.sgi.com> From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 30 Jul 2002 08:21:50 -0700 In-Reply-To: <1028029434.1121.44.camel@laptop.americas.sgi.com> Message-ID: <87ofcp8cmp.fsf@bittersweet.intra.hegbloom.net> Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephen Lord writes: > You say current code will not boot? The problem is you need a much > more recent XFS than ones which work in 2.4.18 to function with EVMS. > Can you restate the unaligned access error? I bet it's not current code then. I tried last week, with Debian's "kernel-patch-xfs" version 1.0.2+20020304-2 and "kernel-patch-evms" version 1.0.1+1.1.0-pre4-2. It would not boot, there was errors messages about unaligned disk access or something (IIRC), and I found mention of it in the XFS list. You (Stephen Lord) said you had code that would hopefully fix it but that you did not want to commit it then since you where about to leave on vacation. Should I try a 2.5 kernel? I need one with both EVMS and XFS for this machine! Please advise. TIA > As for an XFS version, unfortunately the way we release code does > not fit well with a version number - I sometimes wonder if we should > change this - but it would mean a bunch of work on this end. Ok. I should have checked the patch package version number before. I must have been sleeping. -- As any limb well and duly exercised, grows stronger, the nerves of the body are corroborated thereby. --I. Watts. .''`. We are deB.ORG; You will be freed. : :' : `. `' From owner-linux-xfs@oss.sgi.com Tue Jul 30 08:21:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UFLDRw013393 for ; Tue, 30 Jul 2002 08:21:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UFLCgx013392 for linux-xfs-outgoing; Tue, 30 Jul 2002 08:21:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UFL8Rw013336 for ; Tue, 30 Jul 2002 08:21:08 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA26162 for ; Tue, 30 Jul 2002 10:22:30 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA20835 for ; Tue, 30 Jul 2002 10:22:29 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA23374 for linux-xfs@oss.sgi.com; Tue, 30 Jul 2002 10:22:29 -0500 (CDT) Date: Tue, 30 Jul 2002 10:22:29 -0500 (CDT) From: Dean Roehrich Message-Id: <200207301522.KAA23374@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi tests, fix migin.c spawn_kid() X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 30 08:22:14 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:123926a src/sample_hsm/migin.c - 1.5 - increase sizes of sidbuf[] and tokenbuf[]. From owner-linux-xfs@oss.sgi.com Tue Jul 30 08:22:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UFMVRw013591 for ; Tue, 30 Jul 2002 08:22:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UFMVon013590 for linux-xfs-outgoing; Tue, 30 Jul 2002 08:22:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UFMPRw013560 for ; Tue, 30 Jul 2002 08:22:25 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA50008; Tue, 30 Jul 2002 10:23:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA00591; Tue, 30 Jul 2002 10:23:46 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6UFGsM29358; Tue, 30 Jul 2002 10:16:54 -0500 Subject: Re: [Evms-devel] Re: "Invalid client ID" after system lockup and subsequent reset ? From: Steve Lord To: "Karl M. Hegbloom" Cc: Seth Mos , XFS , EVMS Devel In-Reply-To: <87ofcp8cmp.fsf@bittersweet.intra.hegbloom.net> References: <20020728004219.K60206-100000@xs1.xs4all.nl> <878z3teqji.fsf@bittersweet.intra.hegbloom.net> <1028029434.1121.44.camel@laptop.americas.sgi.com> <87ofcp8cmp.fsf@bittersweet.intra.hegbloom.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 30 Jul 2002 10:16:53 -0500 Message-Id: <1028042213.6269.115.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_SPACES,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-07-30 at 10:21, Karl M. Hegbloom wrote: > Stephen Lord writes: > > > You say current code will not boot? The problem is you need a much > > more recent XFS than ones which work in 2.4.18 to function with EVMS. > > Can you restate the unaligned access error? > > I bet it's not current code then. I tried last week, with Debian's > "kernel-patch-xfs" version 1.0.2+20020304-2 and "kernel-patch-evms" > version 1.0.1+1.1.0-pre4-2. It would not boot, there was errors > messages about unaligned disk access or something (IIRC), and I found > mention of it in the XFS list. You (Stephen Lord) said you had code > that would hopefully fix it but that you did not want to commit it > then since you where about to leave on vacation. Code is in our 2.4 cvs tree now which should fix this, currently at 2.4.19-rc3. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jul 30 08:56:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UFu1Rw014163 for ; Tue, 30 Jul 2002 08:56:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UFu1KO014162 for linux-xfs-outgoing; Tue, 30 Jul 2002 08:56:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UFtuRw014128 for ; Tue, 30 Jul 2002 08:55:56 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA48863 for ; Tue, 30 Jul 2002 10:57:18 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA75589 for ; Tue, 30 Jul 2002 10:57:18 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA63705 for linux-xfs@oss.sgi.com; Tue, 30 Jul 2002 10:57:17 -0500 (CDT) Date: Tue, 30 Jul 2002 10:57:17 -0500 (CDT) From: Dean Roehrich Message-Id: <200207301557.KAA63705@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - use spin_trylock in dmapi X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 30 08:57:13 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123928a linux/fs/xfs_dmapi/dmapi_session.c - 1.11 linux/fs/xfs_dmapi/dmapi_register.c - 1.20 - use spin_trylock in dmapi From owner-linux-xfs@oss.sgi.com Tue Jul 30 09:07:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UG7TRw014586 for ; Tue, 30 Jul 2002 09:07:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UG7TkV014585 for linux-xfs-outgoing; Tue, 30 Jul 2002 09:07:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UG7HRw014541 for ; Tue, 30 Jul 2002 09:07:18 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g6UG8UQ01025 for linux-xfs@oss.sgi.com; Tue, 30 Jul 2002 11:08:30 -0500 Date: Tue, 30 Jul 2002 11:08:30 -0500 From: Dean Roehrich Message-Id: <200207301608.g6UG8UQ01025@rope.americas> Subject: TAKE - move dmapi into xfs dir X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 30 09:08:15 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/2.4.x-xfs-c The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123929a linux/fs/xfs_dmapi/Makefile.in 1.11 renamed to linux/fs/xfs/dmapi/Makefile.in 1.3 - linux/fs/xfs_dmapi/Makefile.in 1.10 Renamed to linux/fs/xfs/dmapi/Makefile.inNo Message Supplied linux/fs/xfs_dmapi/dmapi_session.c 1.12 renamed to linux/fs/xfs/dmapi/dmapi_session.c 1.11 - linux/fs/xfs_dmapi/dmapi_session.c 1.11 Renamed to linux/fs/xfs/dmapi/dmapi_session.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_right.c 1.14 renamed to linux/fs/xfs/dmapi/dmapi_right.c 1.10 - linux/fs/xfs_dmapi/dmapi_right.c 1.13 Renamed to linux/fs/xfs/dmapi/dmapi_right.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_register.c 1.21 renamed to linux/fs/xfs/dmapi/dmapi_register.c 1.13 - linux/fs/xfs_dmapi/dmapi_register.c 1.20 Renamed to linux/fs/xfs/dmapi/dmapi_register.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_region.c 1.6 renamed to linux/fs/xfs/dmapi/dmapi_region.c 1.6 - linux/fs/xfs_dmapi/dmapi_region.c 1.5 Renamed to linux/fs/xfs/dmapi/dmapi_region.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_private.h 1.17 renamed to linux/fs/xfs/dmapi/dmapi_private.h 1.8 - linux/fs/xfs_dmapi/dmapi_private.h 1.16 Renamed to linux/fs/xfs/dmapi/dmapi_private.hNo Message Supplied linux/fs/xfs_dmapi/dmapi_mountinfo.c 1.9 renamed to linux/fs/xfs/dmapi/dmapi_mountinfo.c 1.10 - linux/fs/xfs_dmapi/dmapi_mountinfo.c 1.8 Renamed to linux/fs/xfs/dmapi/dmapi_mountinfo.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_io.c 1.6 renamed to linux/fs/xfs/dmapi/dmapi_io.c 1.6 - linux/fs/xfs_dmapi/dmapi_io.c 1.5 Renamed to linux/fs/xfs/dmapi/dmapi_io.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_hole.c 1.6 renamed to linux/fs/xfs/dmapi/dmapi_hole.c 1.6 - linux/fs/xfs_dmapi/dmapi_hole.c 1.5 Renamed to linux/fs/xfs/dmapi/dmapi_hole.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_handle.c 1.6 renamed to linux/fs/xfs/dmapi/dmapi_handle.c 1.6 - linux/fs/xfs_dmapi/dmapi_handle.c 1.5 Renamed to linux/fs/xfs/dmapi/dmapi_handle.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_event.c 1.10 renamed to linux/fs/xfs/dmapi/dmapi_event.c 1.7 - linux/fs/xfs_dmapi/dmapi_event.c 1.9 Renamed to linux/fs/xfs/dmapi/dmapi_event.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_dmattr.c 1.6 renamed to linux/fs/xfs/dmapi/dmapi_dmattr.c 1.6 - linux/fs/xfs_dmapi/dmapi_dmattr.c 1.5 Renamed to linux/fs/xfs/dmapi/dmapi_dmattr.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_config.c 1.7 renamed to linux/fs/xfs/dmapi/dmapi_config.c 1.7 - linux/fs/xfs_dmapi/dmapi_config.c 1.6 Renamed to linux/fs/xfs/dmapi/dmapi_config.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_bulkattr.c 1.6 renamed to linux/fs/xfs/dmapi/dmapi_bulkattr.c 1.6 - linux/fs/xfs_dmapi/dmapi_bulkattr.c 1.5 Renamed to linux/fs/xfs/dmapi/dmapi_bulkattr.cNo Message Supplied linux/fs/xfs_dmapi/dmapi_attr.c 1.6 renamed to linux/fs/xfs/dmapi/dmapi_attr.c 1.6 - linux/fs/xfs_dmapi/dmapi_attr.c 1.5 Renamed to linux/fs/xfs/dmapi/dmapi_attr.cNo Message Supplied linux/fs/xfs_dmapi/Makefile 1.10 renamed to linux/fs/xfs/dmapi/Makefile 1.13 - linux/fs/xfs_dmapi/Makefile 1.9 Renamed to linux/fs/xfs/dmapi/MakefileNo Message Supplied linux/fs/xfs_dmapi/dmapi_sysent.c 1.9 renamed to linux/fs/xfs/dmapi/dmapi_sysent.c 1.12 - linux/fs/xfs_dmapi/dmapi_sysent.c 1.8 Renamed to linux/fs/xfs/dmapi/dmapi_sysent.cNo Message Supplied linux/fs/xfs_dmapi/Status 1.2 renamed to linux/fs/xfs/dmapi/Status 1.5 - linux/fs/xfs_dmapi/Status 1.1 Renamed to linux/fs/xfs/dmapi/StatusNo Message Supplied From owner-linux-xfs@oss.sgi.com Tue Jul 30 09:08:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UG8iRw014767 for ; Tue, 30 Jul 2002 09:08:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UG8inS014766 for linux-xfs-outgoing; Tue, 30 Jul 2002 09:08:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UG8eRw014736 for ; Tue, 30 Jul 2002 09:08:40 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g6UG9qi01102 for linux-xfs@oss.sgi.com; Tue, 30 Jul 2002 11:09:52 -0500 Date: Tue, 30 Jul 2002 11:09:52 -0500 From: Dean Roehrich Message-Id: <200207301609.g6UG9qi01102@rope.americas> Subject: TAKE - move dmapi hdrs into xfs/dmapi dir X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 30 09:09:44 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/2.4.x-xfs-c The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123930a linux/include/linux/dmapi.h 1.12 renamed to linux/fs/xfs/dmapi/dmapi.h 1.1 - linux/include/linux/dmapi.h 1.11 Renamed to linux/fs/xfs/dmapi/dmapi.hNo Message Supplied linux/include/linux/dmapi_kern.h 1.16 renamed to linux/fs/xfs/dmapi/dmapi_kern.h 1.1 - linux/include/linux/dmapi_kern.h 1.15 Renamed to linux/fs/xfs/dmapi/dmapi_kern.hNo Message Supplied From owner-linux-xfs@oss.sgi.com Tue Jul 30 09:19:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UGJpRw015009 for ; Tue, 30 Jul 2002 09:19:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UGJpaR015008 for linux-xfs-outgoing; Tue, 30 Jul 2002 09:19:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UGJiRw014979 for ; Tue, 30 Jul 2002 09:19:44 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g6UGKuU01267 for linux-xfs@oss.sgi.com; Tue, 30 Jul 2002 11:20:56 -0500 Date: Tue, 30 Jul 2002 11:20:56 -0500 From: Dean Roehrich Message-Id: <200207301620.g6UGKuU01267@rope.americas> Subject: TAKE - fix build after dmapi src move X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jul 30 09:20:26 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/2.4.x-xfs-c The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123931a linux/fs/Makefile - 1.54 linux/fs/xfs/xfs_dmapi.h - 1.31 linux/fs/xfs/Makefile - 1.149 linux/fs/xfs/linux/xfs_super.c - 1.202 linux/fs/xfs/dmapi/Makefile - 1.14 linux/fs/xfs/dmapi/dmapi_sysent.c - 1.13 linux/fs/xfs/Makefile.in - 1.22 linux/fs/xfs/dmapi/Makefile.in - 1.4 - fix build after dmapi src move From owner-linux-xfs@oss.sgi.com Tue Jul 30 13:17:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UKH2Rw004026 for ; Tue, 30 Jul 2002 13:17:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UKH2nt004025 for linux-xfs-outgoing; Tue, 30 Jul 2002 13:17:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UKGtRw003855 for ; Tue, 30 Jul 2002 13:16:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA53974 for ; Tue, 30 Jul 2002 15:18:18 -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 PAA74770 for ; Tue, 30 Jul 2002 15:18:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6UKF1O07937; Tue, 30 Jul 2002 15:15:01 -0500 Message-Id: <200207302015.g6UKF1O07937@stout.americas.sgi.com> Date: Tue, 30 Jul 2002 15:15:01 -0500 Subject: TAKE - Fix xfs_open_by_handle for large files on ia64 X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk sys_open does a trick of: #if BITS_PER_LONG != 32 flags |= O_LARGEFILE; #endif to set O_LARGEFILE on 64-bit machines, but if we were doing the open_by_handle ioctl, this didn't get set (since we don't go through sys_open). As a result, things like xfsdump, that use open_by_handle, failed for large files on 64-bit boxes. Date: Tue Jul 30 13:15:19 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:123972a linux/fs/xfs/linux/xfs_ioctl.c - 1.71 - Set O_LARGEFILE flag when we do xfs_open_by_handle on 64-bit machines (follow example of sys_open) From owner-linux-xfs@oss.sgi.com Tue Jul 30 13:24:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UKOnRw004650 for ; Tue, 30 Jul 2002 13:24:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UKOncj004649 for linux-xfs-outgoing; Tue, 30 Jul 2002 13:24:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UKOgRw004621 for ; Tue, 30 Jul 2002 13:24:43 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.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 NAA03687 for ; Tue, 30 Jul 2002 13:26:09 -0700 (PDT) mail_from (pj@engr.sgi.com) Received: from turbo-linux.engr.sgi.com (turbo-linux.engr.sgi.com [163.154.6.103]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA97639; Tue, 30 Jul 2002 13:24:46 -0700 (PDT) Received: by turbo-linux.engr.sgi.com (Postfix, from userid 2324) id D7D911015485; Tue, 30 Jul 2002 13:24:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turbo-linux.engr.sgi.com (Postfix) with ESMTP id 9EEE61C000AE; Tue, 30 Jul 2002 13:24:54 -0700 (PDT) Date: Tue, 30 Jul 2002 13:24:54 -0700 (PDT) From: Paul Jackson To: David Lloyd Cc: linux-xfs@oss.sgi.com Subject: Re: What Does "kernel mtrr" mean... In-Reply-To: <3D465381.69437169@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You can find some background on "mtrr" in the linux file Documentation/mtrr.txt, which begins: MTRR (Memory Type Range Register) control 3 Jun 1999 Richard Gooch On Intel P6 family processors (Pentium Pro, Pentium II and later) the Memory Type Range Registers (MTRRs) may be used to control processor access to memory ranges. This is most useful when you have a video (VGA) card on a PCI or AGP bus. Enabling write-combining allows bus write transfers to be combined into a larger transfer before bursting over the PCI/AGP bus. This can increase performance of image write operations 2.5 times or more. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373 From owner-linux-xfs@oss.sgi.com Tue Jul 30 14:16:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ULG5Rw005342 for ; Tue, 30 Jul 2002 14:16:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ULG46o005341 for linux-xfs-outgoing; Tue, 30 Jul 2002 14:16:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ULD8Rw005279 for ; Tue, 30 Jul 2002 14:13:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA56329 for ; Tue, 30 Jul 2002 16:14:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA31475 for ; Tue, 30 Jul 2002 16:14:30 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6UL7RE12262; Tue, 30 Jul 2002 16:07:27 -0500 Message-Id: <200207302107.g6UL7RE12262@jen.americas.sgi.com> Date: Tue, 30 Jul 2002 16:07:27 -0500 Subject: TAKE - merge up to 2.5.29 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.7 required=5.0 tests=PORN_12,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Took a while to resurrect kdb from the mayhem and to find patches to make SMP systems work. Almost guaranteed to make Linus put out 2.5.30 later today. Steve Date: Tue Jul 30 14:04:55 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:123982a linux/include/asm-mips/rmap.h - 1.1 linux/drivers/input/serio/sa1111ps2.c - 1.1 linux/security/security.c - 1.1 linux/security/dummy.c - 1.1 linux/security/capability.c - 1.1 linux/Documentation/cli-sti-removal.txt - 1.1 linux/security/Makefile - 1.1 linux/security/Config.in - 1.1 linux/security/Config.help - 1.1 linux/drivers/serial/clps711x.c - 1.1 linux/include/video/sgivw.h - 1.1 linux/include/asm-ppc64/ptrace-common.h - 1.1 linux/drivers/usb/serial/io_fw_down3.h - 1.1 linux/drivers/usb/serial/io_ti.c - 1.1 linux/Documentation/ldm.txt - 1.1 linux/drivers/serial/uart00.c - 1.1 linux/drivers/serial/sa1100.c - 1.1 linux/Documentation/serial/driver - 1.1 linux/drivers/serial/core.c - 1.1 linux/drivers/input/serio/ambakmi.c - 1.1 linux/drivers/input/joystick/grip_mp.c - 1.1 linux/drivers/char/agp/Config.help - 1.1 linux/drivers/char/agp/Config.in - 1.1 linux/drivers/video/virgefb.h - 1.1 linux/drivers/char/agp/agp.c - 1.1 linux/drivers/char/agp/ali-agp.c - 1.1 linux/drivers/char/agp/amd-agp.c - 1.1 linux/drivers/char/agp/sis-agp.c - 1.1 linux/drivers/serial/anakin.c - 1.1 linux/drivers/char/agp/frontend.c - 1.1 linux/drivers/char/agp/hp-agp.c - 1.1 linux/drivers/char/agp/i460-agp.c - 1.1 linux/drivers/char/agp/i810-agp.c - 1.1 linux/drivers/char/agp/i8x0-agp.c - 1.1 linux/drivers/acpi/namespace/nsxfeval.c - 1.1 linux/drivers/serial/amba.c - 1.1 linux/drivers/serial/Makefile - 1.1 linux/drivers/serial/Config.in - 1.1 linux/drivers/acpi/namespace/nsdumpdv.c - 1.1 linux/drivers/acpi/include/acdisasm.h - 1.1 linux/mm/rmap.c - 1.1 linux/drivers/serial/Config.help - 1.1 linux/include/asm-alpha/rmap.h - 1.1 linux/drivers/serial/8250_pnp.c - 1.1 linux/drivers/serial/8250_pci.c - 1.1 linux/include/asm-arm/proc-armv/rmap.h - 1.1 linux/include/asm-arm/rmap.h - 1.1 linux/include/asm-cris/rmap.h - 1.1 linux/include/asm-generic/rmap.h - 1.1 linux/drivers/serial/8250.h - 1.1 linux/drivers/char/agp/sworks-agp.c - 1.1 linux/include/asm-generic/sections.h - 1.1 linux/drivers/char/agp/via-agp.c - 1.1 linux/kernel/cpu.c - 1.1 linux/include/asm-mips64/rmap.h - 1.1 linux/include/asm-parisc/rmap.h - 1.1 linux/include/asm-ppc/rmap.h - 1.1 linux/drivers/serial/8250_cs.c - 1.1 linux/drivers/usb/serial/io_ti.h - 1.1 linux/include/asm-ppc64/iSeries/ItExtVpdPanel.h - 1.1 linux/include/asm-i386/rmap.h - 1.1 linux/drivers/ide/timing.h - 1.1 linux/include/asm-i386/sections.h - 1.1 linux/drivers/video/sis/sisfb.h - 1.1 linux/include/asm-ppc64/mmzone.h - 1.1 linux/drivers/serial/8250.c - 1.1 linux/arch/i386/mm/pgtable.c - 1.1 linux/drivers/serial/21285.c - 1.1 linux/include/video/mach64.h - 1.1 linux/include/asm-m68k/nubus.h - 1.1 linux/include/video/aty128.h - 1.1 linux/include/asm-m68k/rmap.h - 1.1 linux/include/linux/serial_core.h - 1.1 linux/include/asm-ia64/rmap.h - 1.1 linux/include/linux/security.h - 1.1 linux/include/asm-m68k/suspend.h - 1.1 linux/include/linux/preempt.h - 1.1 linux/include/asm-ppc64/rmap.h - 1.1 linux/include/asm-s390/rmap.h - 1.1 linux/include/asm-sh/rmap.h - 1.1 linux/include/asm-s390x/rmap.h - 1.1 linux/include/asm-m68k/thread_info.h - 1.1 linux/include/asm-sparc/rmap.h - 1.1 linux/include/asm-sparc64/rmap.h - 1.1 linux/include/asm-m68k/hw_irq.h - 1.1 linux/arch/ppc64/Config.help - 1.1 linux/arch/ppc64/kernel/rtas_flash.c - 1.1 linux/scripts/Makefile - 1.8 linux/net/sunrpc/xprt.c - 1.29 linux/net/sunrpc/sunrpc_syms.c - 1.13 linux/net/sunrpc/clnt.c - 1.19 linux/net/socket.c - 1.38 linux/net/ipx/af_ipx.c - 1.27 linux/net/core/scm.c - 1.8 linux/net/802/tr.c - 1.12 linux/mm/vmscan.c - 1.105 linux/mm/swapfile.c - 1.62 linux/mm/swap_state.c - 1.43 linux/mm/swap.c - 1.21 linux/mm/slab.c - 1.37 linux/mm/page_io.c - 1.28 linux/mm/page_alloc.c - 1.84 linux/mm/mremap.c - 1.31 linux/mm/mprotect.c - 1.30 linux/mm/mmap.c - 1.56 linux/mm/memory.c - 1.86 linux/mm/filemap.c - 1.127 linux/mm/Makefile - 1.16 linux/kernel/sys.c - 1.36 linux/kernel/softirq.c - 1.25 linux/kernel/signal.c - 1.36 linux/kernel/sched.c - 1.76 linux/kernel/panic.c - 1.18 linux/kernel/ksyms.c - 1.153 linux/kernel/kmod.c - 1.22 linux/kernel/fork.c - 1.63 linux/kernel/exit.c - 1.49 linux/kernel/capability.c - 1.9 linux/kernel/acct.c - 1.21 linux/kernel/Makefile - 1.32 linux/ipc/shm.c - 1.55 linux/ipc/sem.c - 1.21 linux/ipc/msg.c - 1.14 linux/init/main.c - 1.85 linux/include/scsi/scsicam.h - 1.4 linux/include/linux/zorro.h - 1.8 linux/include/linux/vmalloc.h - 1.19 linux/include/linux/ufs_fs.h - 1.15 linux/include/linux/tty.h - 1.17 linux/include/linux/trdevice.h - 1.5 linux/include/linux/sysctl.h - 1.53 linux/include/linux/swap.h - 1.60 linux/include/linux/sunrpc/xprt.h - 1.13 linux/include/linux/sunrpc/clnt.h - 1.10 linux/include/linux/smp_lock.h - 1.6 linux/include/linux/smp.h - 1.17 linux/include/linux/smb_fs.h - 1.20 linux/include/linux/shm.h - 1.14 linux/include/linux/serial167.h - 1.3 linux/include/linux/sched.h - 1.77 linux/include/linux/qnx4_fs.h - 1.13 linux/include/linux/proc_fs.h - 1.37 linux/include/linux/pci.h - 1.60 linux/include/linux/pagemap.h - 1.43 linux/include/linux/nubus.h - 1.6 linux/include/linux/notifier.h - 1.5 linux/include/linux/nfs_fs.h - 1.24 linux/include/linux/ncp_mount.h - 1.5 linux/include/linux/ncp_fs_i.h - 1.6 linux/include/linux/ncp_fs.h - 1.15 linux/include/linux/ncp.h - 1.4 linux/include/linux/nbd.h - 1.15 linux/include/linux/msg.h - 1.9 linux/include/linux/msdos_fs_i.h - 1.7 linux/include/linux/msdos_fs.h - 1.21 linux/include/linux/mm.h - 1.92 linux/include/linux/list.h - 1.15 linux/include/linux/kernel_stat.h - 1.11 linux/include/linux/kernel.h - 1.33 linux/include/linux/iso_fs.h - 1.16 linux/include/linux/interrupt.h - 1.22 linux/include/linux/hpfs_fs_i.h - 1.5 linux/include/linux/hfs_fs_i.h - 1.6 linux/include/linux/hfs_fs.h - 1.12 linux/include/linux/hdreg.h - 1.24 linux/include/linux/genhd.h - 1.21 linux/include/linux/fs.h - 1.184 linux/include/linux/fb.h - 1.25 linux/include/linux/dio.h - 1.3 linux/include/linux/blkdev.h - 1.63 linux/include/linux/binfmts.h - 1.12 linux/include/linux/affs_fs_i.h - 1.7 linux/include/linux/adfs_fs_i.h - 1.6 linux/include/linux/adfs_fs.h - 1.8 linux/include/asm-sparc64/system.h - 1.21 linux/include/asm-sparc64/spinlock.h - 1.12 linux/include/asm-sparc64/softirq.h - 1.11 linux/include/asm-sparc64/smplock.h - 1.7 linux/include/asm-sparc64/ide.h - 1.15 linux/include/asm-sparc/system.h - 1.11 linux/include/asm-sparc/spinlock.h - 1.9 linux/include/asm-sparc/softirq.h - 1.11 linux/include/asm-sparc/smplock.h - 1.6 linux/include/asm-ppc/vc_ioctl.h - 1.4 linux/include/asm-ppc/system.h - 1.23 linux/include/asm-ppc/smp.h - 1.17 linux/include/asm-ppc/machdep.h - 1.23 linux/include/asm-ppc/keyboard.h - 1.13 linux/include/asm-ppc/ide.h - 1.19 linux/include/asm-mips/system.h - 1.11 linux/include/asm-mips/smplock.h - 1.6 linux/include/asm-mips/ide.h - 1.14 linux/include/asm-mips/bitops.h - 1.9 linux/include/asm-m68k/virtconvert.h - 1.5 linux/include/asm-m68k/unistd.h - 1.14 linux/include/asm-m68k/types.h - 1.4 linux/include/asm-m68k/system.h - 1.10 linux/include/asm-m68k/smplock.h - 1.5 linux/include/asm-m68k/serial.h - 1.7 linux/include/asm-m68k/semaphore-helper.h - 1.4 linux/include/asm-m68k/scatterlist.h - 1.5 linux/include/asm-m68k/q40_keyboard.h - 1.5 linux/include/asm-m68k/processor.h - 1.15 linux/include/asm-m68k/pgtable.h - 1.16 linux/include/asm-m68k/param.h - 1.7 linux/include/asm-m68k/page.h - 1.12 linux/include/asm-m68k/mman.h - 1.4 linux/include/asm-m68k/macintosh.h - 1.6 linux/include/asm-m68k/machw.h - 1.4 linux/include/asm-m68k/irq.h - 1.6 linux/include/asm-m68k/io.h - 1.8 linux/include/asm-m68k/ide.h - 1.9 linux/include/asm-m68k/entry.h - 1.8 linux/include/asm-m68k/cache.h - 1.5 linux/include/asm-m68k/bitops.h - 1.9 linux/include/asm-m68k/atarihw.h - 1.5 linux/include/asm-i386/system.h - 1.27 linux/include/asm-i386/softirq.h - 1.16 linux/include/asm-i386/smplock.h - 1.15 linux/include/asm-i386/smp.h - 1.19 linux/include/asm-i386/processor.h - 1.41 linux/include/asm-i386/mmu_context.h - 1.21 linux/include/asm-i386/ide.h - 1.11 linux/include/asm-i386/hardirq.h - 1.20 linux/include/asm-i386/desc.h - 1.11 linux/include/asm-generic/smplock.h - 1.5 linux/include/asm-arm/system.h - 1.21 linux/include/asm-arm/proc-armv/system.h - 1.15 linux/include/asm-arm/proc-armo/system.h - 1.11 linux/include/asm-arm/ide.h - 1.6 linux/include/asm-arm/atomic.h - 1.12 linux/include/asm-alpha/system.h - 1.21 linux/include/asm-alpha/smplock.h - 1.5 linux/include/asm-alpha/io.h - 1.19 linux/include/asm-alpha/ide.h - 1.10 linux/fs/super.c - 1.90 linux/fs/stat.c - 1.28 linux/fs/readdir.c - 1.17 linux/fs/read_write.c - 1.22 linux/fs/proc/base.c - 1.40 linux/fs/proc/array.c - 1.46 linux/fs/open.c - 1.42 linux/fs/nfsd/stats.c - 1.10 linux/fs/nfsd/nfssvc.c - 1.23 linux/fs/nfsd/nfsctl.c - 1.33 linux/fs/nfsd/lockd.c - 1.10 linux/fs/nfsd/export.c - 1.39 linux/fs/nfs/inode.c - 1.49 linux/fs/nfs/dir.c - 1.42 linux/fs/ncpfs/symlink.c - 1.17 linux/fs/ncpfs/ncplib_kernel.h - 1.10 linux/fs/ncpfs/ncplib_kernel.c - 1.12 linux/fs/ncpfs/ioctl.c - 1.17 linux/fs/ncpfs/inode.c - 1.34 linux/fs/ncpfs/file.c - 1.21 linux/fs/ncpfs/dir.c - 1.31 linux/fs/ncpfs/Makefile - 1.5 linux/fs/namei.c - 1.59 linux/fs/locks.c - 1.28 linux/fs/ioctl.c - 1.16 linux/fs/inode.c - 1.80 linux/fs/hfs/hfs_btree.h - 1.6 linux/fs/hfs/hfs.h - 1.8 linux/fs/hfs/catalog.c - 1.7 linux/fs/hfs/btree.c - 1.4 linux/fs/hfs/binsert.c - 1.4 linux/fs/file_table.c - 1.21 linux/fs/fcntl.c - 1.22 linux/fs/fat/inode.c - 1.46 linux/fs/fat/file.c - 1.24 linux/fs/exec.c - 1.58 linux/fs/dquot.c - 1.59 linux/fs/buffer.c - 1.128 linux/fs/block_dev.c - 1.52 linux/fs/attr.c - 1.17 linux/drivers/zorro/zorro.c - 1.11 linux/drivers/zorro/Makefile - 1.10 linux/drivers/video/virgefb.c - 1.17 linux/drivers/video/vfb.c - 1.17 linux/drivers/video/vesafb.c - 1.24 linux/drivers/video/valkyriefb.h - 1.5 linux/drivers/video/valkyriefb.c - 1.18 linux/drivers/video/sgivwfb.h - 1.3 linux/drivers/video/sgivwfb.c - 1.16 linux/drivers/video/retz3fb.c - 1.18 linux/drivers/video/q40fb.c - 1.14 linux/drivers/video/pm2fb.c - 1.16 linux/drivers/video/platinumfb.c - 1.17 linux/drivers/video/offb.c - 1.22 linux/drivers/video/macmodes.c - 1.10 linux/drivers/video/macfb.c - 1.15 linux/drivers/video/imsttfb.c - 1.24 linux/drivers/video/hpfb.c - 1.15 linux/drivers/video/fonts.c - 1.5 linux/drivers/video/fm2fb.c - 1.16 linux/drivers/video/fbmem.c - 1.51 linux/drivers/video/fbgen.c - 1.10 linux/drivers/video/fbcon.c - 1.27 linux/drivers/video/fbcon-vga.c - 1.6 linux/drivers/video/fbcon-mac.c - 1.9 linux/drivers/video/dnfb.c - 1.16 linux/drivers/video/controlfb.c - 1.23 linux/drivers/video/chipsfb.c - 1.20 linux/drivers/video/atafb.c - 1.17 linux/drivers/video/amifb.c - 1.24 linux/drivers/video/S3triofb.c - 1.13 linux/drivers/video/Makefile - 1.42 linux/drivers/video/Config.in - 1.38 linux/drivers/scsi/wd7000.h - 1.5 linux/drivers/scsi/wd7000.c - 1.16 linux/drivers/scsi/ultrastor.h - 1.3 linux/drivers/scsi/ultrastor.c - 1.14 linux/drivers/scsi/u14-34f.h - 1.12 linux/drivers/scsi/u14-34f.c - 1.24 linux/drivers/scsi/tmscsim.c - 1.18 linux/drivers/scsi/t128.h - 1.5 linux/drivers/scsi/t128.c - 1.11 linux/drivers/scsi/sym53c416.h - 1.6 linux/drivers/scsi/sym53c416.c - 1.12 linux/drivers/scsi/st.h - 1.15 linux/drivers/scsi/st.c - 1.47 linux/drivers/scsi/sd.c - 1.64 linux/drivers/scsi/scsicam.c - 1.12 linux/drivers/scsi/scsi_debug.h - 1.8 linux/drivers/scsi/scsi_debug.c - 1.22 linux/drivers/scsi/scsi.h - 1.31 linux/drivers/scsi/qlogicpti.c - 1.20 linux/drivers/scsi/qlogicisp.h - 1.4 linux/drivers/scsi/qlogicisp.c - 1.28 linux/drivers/scsi/qlogicfc.h - 1.10 linux/drivers/scsi/qlogicfc.c - 1.29 linux/drivers/scsi/qlogicfas.h - 1.4 linux/drivers/scsi/qlogicfas.c - 1.15 linux/drivers/scsi/psi240i.h - 1.5 linux/drivers/scsi/psi240i.c - 1.9 linux/drivers/scsi/ppa.h - 1.10 linux/drivers/scsi/ppa.c - 1.16 linux/drivers/scsi/pci2220i.h - 1.8 linux/drivers/scsi/pci2220i.c - 1.24 linux/drivers/scsi/pci2000.h - 1.7 linux/drivers/scsi/pci2000.c - 1.21 linux/drivers/scsi/pas16.h - 1.4 linux/drivers/scsi/pas16.c - 1.12 linux/drivers/scsi/mvme16x.c - 1.8 linux/drivers/scsi/megaraid.h - 1.15 linux/drivers/scsi/megaraid.c - 1.35 linux/drivers/scsi/mac_esp.c - 1.13 linux/drivers/scsi/inia100.h - 1.11 linux/drivers/scsi/inia100.c - 1.20 linux/drivers/scsi/ini9100u.h - 1.11 linux/drivers/scsi/ini9100u.c - 1.18 linux/drivers/scsi/in2000.h - 1.10 linux/drivers/scsi/in2000.c - 1.11 linux/drivers/scsi/imm.h - 1.9 linux/drivers/scsi/imm.c - 1.16 linux/drivers/scsi/ide-scsi.c - 1.41 linux/drivers/scsi/ibmmca.h - 1.7 linux/drivers/scsi/ibmmca.c - 1.17 linux/drivers/scsi/hosts.h - 1.23 linux/drivers/scsi/gdth.h - 1.9 linux/drivers/scsi/gdth.c - 1.21 linux/drivers/scsi/g_NCR5380.h - 1.6 linux/drivers/scsi/g_NCR5380.c - 1.15 linux/drivers/scsi/fdomain.h - 1.5 linux/drivers/scsi/fdomain.c - 1.21 linux/drivers/scsi/fd_mcs.h - 1.4 linux/drivers/scsi/fd_mcs.c - 1.8 linux/drivers/scsi/eata.h - 1.11 linux/drivers/scsi/eata.c - 1.26 linux/drivers/scsi/dtc.h - 1.5 linux/drivers/scsi/dtc.c - 1.11 linux/drivers/scsi/dc390.h - 1.7 linux/drivers/scsi/bvme6000.c - 1.6 linux/drivers/scsi/atp870u.h - 1.7 linux/drivers/scsi/atp870u.c - 1.21 linux/drivers/scsi/atari_scsi.h - 1.4 linux/drivers/scsi/atari_NCR5380.c - 1.6 linux/drivers/scsi/aha1740.h - 1.4 linux/drivers/scsi/aha1740.c - 1.11 linux/drivers/scsi/aha1542.h - 1.7 linux/drivers/scsi/aha1542.c - 1.27 linux/drivers/scsi/aha152x.h - 1.9 linux/drivers/scsi/aha152x.c - 1.30 linux/drivers/scsi/advansys.h - 1.7 linux/drivers/scsi/advansys.c - 1.27 linux/drivers/scsi/README.st - 1.10 linux/drivers/scsi/NCR53c406a.h - 1.4 linux/drivers/scsi/NCR53c406a.c - 1.13 linux/drivers/scsi/NCR5380.c - 1.10 linux/drivers/scsi/BusLogic.h - 1.9 linux/drivers/scsi/BusLogic.c - 1.17 linux/drivers/scsi/53c7xx.c - 1.18 linux/drivers/pci/quirks.c - 1.29 linux/drivers/pci/proc.c - 1.26 linux/drivers/nubus/nubus.c - 1.9 linux/drivers/net/tlan.h - 1.13 linux/drivers/net/tlan.c - 1.28 linux/drivers/net/sonic.h - 1.9 linux/drivers/net/sgiseeq.c - 1.15 linux/drivers/net/plip.c - 1.22 linux/drivers/net/hplance.c - 1.11 linux/drivers/net/hamradio/baycom_ser_hdx.c - 1.16 linux/drivers/net/hamradio/baycom_ser_fdx.c - 1.17 linux/drivers/net/hamradio/baycom_par.c - 1.16 linux/drivers/net/eepro100.c - 1.47 linux/drivers/net/atarilance.c - 1.12 linux/drivers/net/acenic.c - 1.41 linux/drivers/net/a2065.c - 1.17 linux/drivers/net/Space.c - 1.35 linux/drivers/net/8390.h - 1.12 linux/drivers/net/82596.c - 1.20 linux/drivers/net/7990.c - 1.8 linux/drivers/macintosh/via-cuda.c - 1.10 linux/drivers/macintosh/adb.c - 1.16 linux/drivers/macintosh/Makefile - 1.13 linux/drivers/dio/dio.c - 1.6 linux/drivers/char/vt.c - 1.25 linux/drivers/char/tty_ioctl.c - 1.7 linux/drivers/char/tty_io.c - 1.48 linux/drivers/char/specialix_io8.h - 1.3 linux/drivers/char/serial167.c - 1.14 linux/drivers/char/serial.c - 1.61 linux/drivers/char/n_tty.c - 1.15 linux/drivers/char/mem.c - 1.46 linux/drivers/char/dn_keyb.c - 1.8 linux/drivers/char/Makefile - 1.66 linux/drivers/char/Config.in - 1.63 linux/drivers/cdrom/cdrom.c - 1.43 linux/drivers/block/xd.h - 1.9 linux/drivers/block/xd.c - 1.39 linux/drivers/block/rd.c - 1.55 linux/drivers/block/ps2esdi.c - 1.41 linux/drivers/block/paride/pt.c - 1.17 linux/drivers/block/paride/pg.c - 1.17 linux/drivers/block/paride/pf.c - 1.27 linux/drivers/block/paride/pd.c - 1.32 linux/drivers/block/paride/pcd.c - 1.22 linux/drivers/block/paride/paride.c - 1.13 linux/drivers/block/paride/on26.c - 1.7 linux/drivers/block/paride/on20.c - 1.6 linux/drivers/block/paride/ktti.c - 1.6 linux/drivers/block/paride/kbic.c - 1.6 linux/drivers/block/paride/frpw.c - 1.6 linux/drivers/block/paride/friq.c - 1.6 linux/drivers/block/paride/fit3.c - 1.6 linux/drivers/block/paride/fit2.c - 1.6 linux/drivers/block/paride/epia.c - 1.6 linux/drivers/block/paride/epat.c - 1.7 linux/drivers/block/paride/dstr.c - 1.6 linux/drivers/block/paride/comm.c - 1.6 linux/drivers/block/paride/bpck.c - 1.6 linux/drivers/block/paride/aten.c - 1.6 linux/drivers/block/paride/Makefile - 1.10 linux/drivers/block/loop.c - 1.61 linux/drivers/block/ll_rw_blk.c - 1.109 linux/drivers/block/genhd.c - 1.29 linux/drivers/block/floppy.c - 1.43 linux/drivers/block/ataflop.c - 1.25 linux/drivers/block/amiflop.c - 1.26 linux/drivers/block/acsi.c - 1.32 linux/drivers/acorn/block/mfmhd.c - 1.26 linux/drivers/Makefile - 1.36 linux/arch/sparc64/prom/misc.c - 1.12 linux/arch/sparc64/mm/init.c - 1.45 linux/arch/sparc64/kernel/time.c - 1.22 linux/arch/sparc64/kernel/smp.c - 1.46 linux/arch/sparc64/kernel/irq.c - 1.25 linux/arch/sparc64/config.in - 1.57 linux/arch/sparc/mm/srmmu.c - 1.33 linux/arch/sparc/kernel/time.c - 1.18 linux/arch/sparc/kernel/sun4m_smp.c - 1.21 linux/arch/sparc/kernel/sun4m_irq.c - 1.9 linux/arch/sparc/kernel/sun4d_smp.c - 1.22 linux/arch/sparc/kernel/sun4d_irq.c - 1.14 linux/arch/sparc/kernel/smp.c - 1.18 linux/arch/sparc/kernel/pcic.c - 1.20 linux/arch/sparc/kernel/irq.c - 1.21 linux/arch/sparc/config.in - 1.39 linux/arch/ppc/kernel/smp.c - 1.40 linux/arch/ppc/kernel/process.c - 1.38 linux/arch/ppc/kernel/ppc_ksyms.c - 1.46 linux/arch/ppc/kernel/open_pic.c - 1.27 linux/arch/ppc/kernel/misc.S - 1.42 linux/arch/ppc/kernel/irq.c - 1.36 linux/arch/ppc/kernel/idle.c - 1.25 linux/arch/ppc/config.in - 1.55 linux/arch/ppc/amiga/config.c - 1.17 linux/arch/ppc/8xx_io/uart.c - 1.20 linux/arch/mips/sgi/kernel/indy_sc.c - 1.10 linux/arch/mips/mm/r4xx0.c - 1.12 linux/arch/mips/lib/dump_tlb.c - 1.4 linux/arch/mips/kernel/ptrace.c - 1.14 linux/arch/mips/kernel/irq.c - 1.13 linux/arch/mips/config.in - 1.32 linux/arch/m68k/sun3x/config.c - 1.7 linux/arch/m68k/q40/config.c - 1.15 linux/arch/m68k/mvme16x/rtc.c - 1.10 linux/arch/m68k/mvme16x/config.c - 1.10 linux/arch/m68k/mvme147/config.c - 1.12 linux/arch/m68k/mm/memory.c - 1.12 linux/arch/m68k/mm/init.c - 1.16 linux/arch/m68k/mm/fault.c - 1.10 linux/arch/m68k/mac/macints.c - 1.9 linux/arch/m68k/mac/debug.c - 1.9 linux/arch/m68k/mac/config.c - 1.11 linux/arch/m68k/kernel/traps.c - 1.14 linux/arch/m68k/kernel/signal.c - 1.19 linux/arch/m68k/kernel/setup.c - 1.17 linux/arch/m68k/kernel/ptrace.c - 1.12 linux/arch/m68k/kernel/process.c - 1.17 linux/arch/m68k/kernel/m68k_defs.c - 1.6 linux/arch/m68k/kernel/head.S - 1.9 linux/arch/m68k/kernel/entry.S - 1.17 linux/arch/m68k/ifpsp060/iskeleton.S - 1.4 linux/arch/m68k/hp300/ints.c - 1.6 linux/arch/m68k/hp300/config.c - 1.6 linux/arch/m68k/fpsp040/skeleton.S - 1.4 linux/arch/m68k/config.in - 1.31 linux/arch/m68k/bvme6000/rtc.c - 1.10 linux/arch/m68k/bvme6000/config.c - 1.10 linux/arch/m68k/atari/stram.c - 1.17 linux/arch/m68k/atari/joystick.c - 1.9 linux/arch/m68k/atari/debug.c - 1.7 linux/arch/m68k/atari/config.c - 1.9 linux/arch/m68k/atari/ataints.c - 1.8 linux/arch/m68k/atari/Makefile - 1.5 linux/arch/m68k/apollo/dn_ints.c - 1.8 linux/arch/m68k/apollo/config.c - 1.8 linux/arch/m68k/amiga/config.c - 1.14 linux/arch/i386/mm/ioremap.c - 1.17 linux/arch/i386/mm/init.c - 1.39 linux/arch/i386/mm/fault.c - 1.25 linux/arch/i386/mm/Makefile - 1.7 linux/arch/i386/kernel/vm86.c - 1.15 linux/arch/i386/kernel/traps.c - 1.56 linux/arch/i386/kernel/trampoline.S - 1.6 linux/arch/i386/kernel/smp.c - 1.49 linux/arch/i386/kernel/ptrace.c - 1.23 linux/arch/i386/kernel/process.c - 1.51 linux/arch/i386/kernel/mtrr.c - 1.39 linux/arch/i386/kernel/mca.c - 1.13 linux/arch/i386/kernel/ldt.c - 1.12 linux/arch/i386/kernel/irq.c - 1.44 linux/arch/i386/kernel/io_apic.c - 1.41 linux/arch/i386/kernel/i386_ksyms.c - 1.51 linux/arch/i386/kernel/head.S - 1.25 linux/arch/i386/kernel/entry.S - 1.59 linux/arch/i386/kernel/apm.c - 1.50 linux/arch/i386/config.in - 1.85 linux/arch/i386/boot/video.S - 1.9 linux/arch/arm/kernel/irq.c - 1.20 linux/arch/arm/config.in - 1.44 linux/arch/alpha/kernel/smp.c - 1.35 linux/arch/alpha/kernel/smc37c93x.c - 1.4 linux/arch/alpha/kernel/smc37c669.c - 1.6 linux/arch/alpha/kernel/process.c - 1.27 linux/arch/alpha/kernel/irq.c - 1.22 linux/arch/alpha/kernel/core_t2.c - 1.11 linux/arch/alpha/kernel/core_mcpcia.c - 1.18 linux/arch/alpha/kernel/core_lca.c - 1.12 linux/arch/alpha/kernel/core_cia.c - 1.22 linux/arch/alpha/kernel/core_apecs.c - 1.12 linux/arch/alpha/config.in - 1.49 linux/Makefile - 1.210 linux/Documentation/00-INDEX - 1.13 linux/CREDITS - 1.84 linux/include/linux/ide.h - 1.56 linux/include/linux/i2o.h - 1.18 linux/include/linux/efs_fs.h - 1.10 linux/drivers/block/blkpg.c - 1.24 linux/arch/ppc/xmon/xmon.c - 1.20 linux/arch/mips/dec/irq.c - 1.9 linux/arch/mips/baget/irq.c - 1.10 linux/drivers/block/cpqarray.c - 1.50 linux/kernel/ptrace.c - 1.22 linux/arch/arm/kernel/isa.c - 1.5 linux/drivers/parport/share.c - 1.20 linux/drivers/parport/parport_pc.c - 1.47 linux/drivers/parport/parport_mfc3.c - 1.10 linux/drivers/parport/init.c - 1.12 linux/include/asm-i386/apic.h - 1.17 linux/drivers/net/macsonic.c - 1.13 linux/drivers/char/q40_keyb.c - 1.7 linux/fs/partitions/ultrix.c - 1.5 linux/fs/partitions/sun.h - 1.3 linux/fs/partitions/sun.c - 1.6 linux/fs/partitions/sgi.h - 1.3 linux/fs/partitions/sgi.c - 1.7 linux/fs/partitions/osf.h - 1.3 linux/fs/partitions/osf.c - 1.5 linux/fs/partitions/msdos.h - 1.3 linux/fs/partitions/msdos.c - 1.24 linux/fs/partitions/mac.h - 1.3 linux/fs/partitions/mac.c - 1.6 linux/fs/partitions/check.h - 1.8 linux/fs/partitions/check.c - 1.46 linux/fs/partitions/atari.h - 1.4 linux/fs/partitions/atari.c - 1.8 linux/fs/partitions/amiga.h - 1.3 linux/fs/partitions/amiga.c - 1.5 linux/fs/partitions/acorn.h - 1.5 linux/fs/partitions/acorn.c - 1.17 linux/fs/partitions/Config.in - 1.19 linux/drivers/video/vga.h - 1.5 linux/drivers/scsi/oktagon_esp.c - 1.9 linux/drivers/video/modedb.c - 1.6 linux/drivers/net/fc/iph5526_scsi.h - 1.2 linux/drivers/net/fc/iph5526.c - 1.20 linux/arch/alpha/kernel/ns87312.c - 1.2 linux/drivers/block/DAC960.c - 1.50 linux/arch/sh/kernel/process.c - 1.21 linux/arch/sh/kernel/irq.c - 1.15 linux/arch/sh/config.in - 1.26 linux/drivers/scsi/ips.h - 1.14 linux/drivers/scsi/ips.c - 1.28 linux/include/asm-sh/system.h - 1.12 linux/arch/m68k/sun3/config.c - 1.8 linux/arch/m68k/mm/motorola.c - 1.8 linux/include/linux/spinlock.h - 1.19 linux/arch/i386/kernel/smpboot.c - 1.43 linux/include/linux/pci_ids.h - 1.69 linux/drivers/video/tdfxfb.c - 1.22 linux/drivers/scsi/sim710.h - 1.5 linux/include/linux/pmu.h - 1.6 linux/include/asm-sh/ide.h - 1.14 linux/include/asm-i386/pgtable-3level.h - 1.11 linux/drivers/video/aty128fb.c - 1.28 linux/drivers/video/aty128.h - 1.6 linux/fs/proc/proc_misc.c - 1.37 linux/drivers/char/pcmcia/serial_cs.c - 1.8 linux/drivers/char/pcmcia/Makefile - 1.8 linux/drivers/char/pcmcia/Config.in - 1.9 linux/include/linux/agpgart.h - 1.5 linux/include/linux/agp_backend.h - 1.19 linux/drivers/net/aironet4500_proc.c - 1.11 linux/drivers/net/aironet4500_core.c - 1.19 linux/drivers/net/aironet4500_card.c - 1.15 linux/drivers/char/agp/agpgart_fe.c - 1.17 linux/drivers/char/agp/Makefile - 1.8 linux/kernel/timer.c - 1.27 linux/drivers/scsi/scsi_lib.c - 1.48 linux/drivers/char/agp/agpgart_be.c - 1.40 linux/drivers/char/agp/agp.h - 1.26 linux/drivers/sbus/char/jsflash.c - 1.19 linux/include/asm-ppc/hw_irq.h - 1.8 linux/include/linux/input.h - 1.19 linux/Documentation/usb/ov511.txt - 1.18 linux/kernel/uid16.c - 1.2 linux/arch/i386/kernel/apic.c - 1.32 linux/drivers/scsi/scsi_scan.c - 1.27 linux/drivers/scsi/3w-xxxx.h - 1.12 linux/drivers/scsi/3w-xxxx.c - 1.20 linux/arch/m68k/atari/hades-pci.c - 1.3 linux/include/asm-sparc/ide.h - 1.12 linux/include/asm-m68k/pci.h - 1.5 linux/include/asm-m68k/apollodma.h - 1.2 linux/drivers/net/mac89x0.c - 1.10 linux/drivers/net/macmace.c - 1.6 linux/drivers/char/vme_scc.c - 1.10 linux/arch/ia64/config.in - 1.32 linux/arch/ia64/kernel/irq.c - 1.20 linux/arch/ia64/kernel/smp.c - 1.17 linux/arch/ia64/kernel/ptrace.c - 1.16 linux/drivers/scsi/qla1280.h - 1.5 linux/drivers/scsi/qla1280.c - 1.18 linux/include/asm-ia64/ide.h - 1.11 linux/include/linux/raid/md_k.h - 1.25 linux/include/linux/raid/md.h - 1.16 linux/include/asm-ia64/system.h - 1.16 linux/drivers/video/sun3fb.c - 1.10 linux/drivers/net/8139too.c - 1.39 linux/drivers/macintosh/via-pmu68k.c - 1.6 linux/drivers/macintosh/via-maciisi.c - 1.2 linux/drivers/macintosh/via-macii.c - 1.3 linux/drivers/char/amiserial.c - 1.13 linux/arch/m68k/mac/misc.c - 1.7 linux/arch/m68k/mac/baboon.c - 1.6 linux/Documentation/filesystems/devfs/README - 1.16 linux/Documentation/filesystems/devfs/ChangeLog - 1.23 linux/fs/devfs/base.c - 1.40 linux/arch/mips/lib/r3k_dump_tlb.c - 1.4 linux/drivers/video/matrox/matroxfb_base.h - 1.13 linux/drivers/video/matrox/matroxfb_base.c - 1.19 linux/include/asm-mips64/ide.h - 1.11 linux/include/asm-mips64/system.h - 1.6 linux/arch/mips64/sgi-ip22/ip22-int.c - 1.8 linux/arch/mips64/mm/andes.c - 1.10 linux/arch/mips64/lib/dump_tlb.c - 1.4 linux/arch/mips64/sgi-ip27/ip27-irq.c - 1.10 linux/arch/mips64/config.in - 1.22 linux/arch/mips64/mm/r4xx0.c - 1.11 linux/arch/mips64/sgi-ip22/ip22-sc.c - 1.6 linux/arch/mips64/kernel/ptrace.c - 1.9 linux/drivers/char/epca.h - 1.2 linux/arch/alpha/kernel/irq_smp.c - 1.4 linux/include/linux/usb.h - 1.42 linux/drivers/usb/serial/usb-serial.h - 1.21 linux/drivers/usb/serial/Makefile - 1.21 linux/drivers/ide/via82cxxx.c - 1.32 linux/drivers/ide/umc8672.c - 1.7 linux/drivers/ide/trm290.c - 1.14 linux/drivers/ide/sl82c105.c - 1.15 linux/drivers/ide/sis5513.c - 1.23 linux/drivers/ide/rz1000.c - 1.9 linux/drivers/ide/q40ide.c - 1.6 linux/drivers/ide/piix.c - 1.28 linux/drivers/ide/pdc4030.c - 1.20 linux/drivers/ide/pdc202xx.c - 1.26 linux/drivers/ide/opti621.c - 1.13 linux/drivers/ide/ns87415.c - 1.13 linux/drivers/ide/ide.c - 1.59 linux/drivers/ide/ide-tape.c - 1.31 linux/drivers/ide/ide-pmac.c - 1.19 linux/drivers/ide/ide-pci.c - 1.31 linux/drivers/ide/ide-floppy.c - 1.29 linux/drivers/ide/ide-disk.c - 1.41 linux/drivers/ide/ide-cd.h - 1.14 linux/drivers/ide/ide-cd.c - 1.41 linux/drivers/ide/icside.c - 1.21 linux/drivers/ide/ht6560b.c - 1.11 linux/drivers/ide/hpt366.c - 1.23 linux/drivers/ide/hpt34x.c - 1.17 linux/drivers/ide/hd.c - 1.24 linux/drivers/ide/gayle.c - 1.8 linux/drivers/ide/dtc2278.c - 1.9 linux/drivers/ide/cy82c693.c - 1.15 linux/drivers/ide/cs5530.c - 1.13 linux/drivers/ide/cmd64x.c - 1.19 linux/drivers/ide/cmd640.c - 1.12 linux/drivers/ide/alim15x3.c - 1.20 linux/drivers/ide/ali14xx.c - 1.11 linux/drivers/ide/Makefile - 1.25 linux/drivers/ide/Config.in - 1.30 linux/Documentation/DocBook/Makefile - 1.34 linux/scripts/kernel-doc - 1.13 linux/scripts/gen-all-syms - 1.3 linux/scripts/docproc.c - 1.5 linux/scripts/docgen - 1.3 linux/include/linux/generic_serial.h - 1.5 linux/Documentation/DocBook/kernel-api.tmpl - 1.20 linux/drivers/usb/serial/keyspan_pda.S - 1.2 linux/Documentation/DocBook/parportbook.tmpl - 1.8 linux/include/linux/nfs_xdr.h - 1.8 linux/fs/nfs/nfs3proc.c - 1.13 linux/drivers/usb/serial/keyspan_pda.c - 1.28 linux/drivers/usb/serial/ftdi_sio.c - 1.38 linux/drivers/usb/serial/usbserial.c - 1.38 linux/drivers/usb/serial/whiteheat.c - 1.27 linux/drivers/usb/serial/visor.c - 1.37 linux/drivers/ide/aec62xx.c - 1.13 linux/drivers/usb/serial/omninet.c - 1.26 linux/fs/partitions/ibm.h - 1.4 linux/fs/partitions/ibm.c - 1.13 linux/drivers/usb/serial/digi_acceleport.c - 1.29 linux/include/linux/raid/raid5.h - 1.9 linux/include/linux/raid/raid1.h - 1.11 linux/arch/s390/config.in - 1.13 linux/include/asm-s390/system.h - 1.8 linux/include/asm-s390/ide.h - 1.5 linux/include/asm-s390/hdreg.h - 1.2 linux/include/asm-s390/smplock.h - 1.3 linux/arch/s390/kernel/irq.c - 1.10 linux/Documentation/s390/cds.txt - 1.7 linux/arch/s390/kernel/traps.c - 1.11 linux/arch/s390/kernel/setup.c - 1.9 linux/arch/s390/mm/fault.c - 1.10 linux/Documentation/kernel-doc-nano-HOWTO.txt - 1.5 linux/include/asm-mips64/smplock.h - 1.2 linux/arch/i386/kdb/kdbasupport.c - 1.19 linux/drivers/usb/storage/usb.c - 1.25 linux/drivers/usb/storage/scsiglue.c - 1.24 linux/drivers/usb/serial/keyspan.c - 1.29 linux/drivers/acpi/tables.c - 1.4 linux/drivers/acpi/resources/rsirq.c - 1.10 linux/drivers/acpi/resources/rsio.c - 1.10 linux/drivers/acpi/parser/psutils.c - 1.12 linux/drivers/acpi/parser/psparse.c - 1.13 linux/drivers/acpi/parser/psopcode.c - 1.12 linux/drivers/acpi/parser/psargs.c - 1.11 linux/drivers/acpi/namespace/nsxfobj.c - 1.13 linux/drivers/acpi/namespace/nsload.c - 1.11 linux/fs/jffs/inode-v23.c - 1.29 linux/drivers/acpi/include/amlcode.h - 1.11 linux/drivers/acpi/include/acpiosxf.h - 1.10 linux/drivers/acpi/ec.c - 1.10 linux/drivers/acpi/dispatcher/dswstate.c - 1.12 linux/drivers/acpi/dispatcher/dswload.c - 1.12 linux/drivers/acpi/dispatcher/dsutils.c - 1.12 linux/drivers/acpi/dispatcher/dsobject.c - 1.14 linux/drivers/mtd/ftl.c - 1.19 linux/drivers/mtd/mtdblock.c - 1.18 linux/include/linux/gameport.h - 1.8 linux/include/linux/serio.h - 1.6 linux/fs/partitions/ultrix.h - 1.3 linux/include/linux/irq_cpustat.h - 1.6 linux/drivers/media/video/i2c-parport.c - 1.4 linux/drivers/media/video/i2c-old.c - 1.5 linux/drivers/media/video/Makefile - 1.10 linux/drivers/media/video/Config.in - 1.7 linux/drivers/input/mousedev.c - 1.11 linux/drivers/input/keybdev.c - 1.10 linux/drivers/input/joydev.c - 1.11 linux/drivers/input/input.c - 1.10 linux/drivers/input/evdev.c - 1.11 linux/drivers/char/serial_21285.c - 1.8 linux/drivers/md/lvm.c - 1.33 linux/drivers/md/raid1.c - 1.23 linux/drivers/md/raid5.c - 1.30 linux/arch/i386/kernel/bluesmoke.c - 1.24 linux/drivers/acpi/include/acconfig.h - 1.14 linux/drivers/acpi/include/acdebug.h - 1.12 linux/drivers/acpi/include/acglobal.h - 1.11 linux/drivers/acpi/include/aclocal.h - 1.13 linux/drivers/acpi/include/acmacros.h - 1.11 linux/drivers/acpi/include/acnamesp.h - 1.11 linux/drivers/acpi/namespace/nsdump.c - 1.9 linux/drivers/block/cciss.c - 1.37 linux/drivers/char/serial_amba.c - 1.9 linux/drivers/macintosh/adbhid.c - 1.6 linux/drivers/macintosh/mac_hid.c - 1.5 linux/drivers/md/linear.c - 1.11 linux/drivers/md/md.c - 1.50 linux/drivers/md/raid0.c - 1.10 linux/drivers/md/xor.c - 1.8 linux/drivers/scsi/cpqfcTS.h - 1.5 linux/drivers/scsi/cpqfcTSinit.c - 1.18 linux/fs/dnotify.c - 1.5 linux/drivers/zorro/zorro.ids - 1.3 linux/drivers/usb/serial/belkin_sa.c - 1.21 linux/drivers/video/sis/initdef.h - 1.3 linux/drivers/video/sis/sis_main.c - 1.13 linux/include/asm-m68k/motorola_pgalloc.h - 1.7 linux/drivers/usb/serial/mct_u232.c - 1.21 linux/include/asm-parisc/ide.h - 1.6 linux/drivers/usb/serial/empeg.c - 1.26 linux/drivers/usb/serial/Config.in - 1.16 linux/include/asm-m68k/sun3_pgtable.h - 1.3 linux/include/asm-parisc/smplock.h - 1.2 linux/include/asm-m68k/motorola_pgtable.h - 1.2 linux/arch/parisc/config.in - 1.8 linux/include/asm-parisc/system.h - 1.2 linux/include/linux/shmem_fs.h - 1.7 linux/mm/shmem.c - 1.42 linux/drivers/acpi/power.c - 1.6 linux/include/linux/reiserfs_fs.h - 1.29 linux/arch/s390x/kernel/traps.c - 1.7 linux/arch/s390x/kernel/setup.c - 1.8 linux/include/asm-s390x/ide.h - 1.5 linux/include/asm-s390x/hdreg.h - 1.2 linux/arch/s390x/kernel/irq.c - 1.7 linux/drivers/s390/s390mach.c - 1.6 linux/arch/cris/config.in - 1.14 linux/arch/cris/kernel/irq.c - 1.9 linux/include/asm-s390x/smplock.h - 1.2 linux/arch/s390x/config.in - 1.8 linux/arch/s390x/mm/fault.c - 1.8 linux/drivers/s390/block/xpram.c - 1.21 linux/include/asm-s390x/system.h - 1.6 linux/include/asm-cris/system.h - 1.5 linux/include/asm-cris/sv_addr.agh - 1.3 linux/include/asm-cris/softirq.h - 1.4 linux/include/asm-cris/ide.h - 1.7 linux/drivers/usb/serial/io_usbvend.h - 1.8 linux/drivers/scsi/aic7xxx_old/aic7xxx.h - 1.3 linux/drivers/scsi/aic7xxx_old.c - 1.19 linux/drivers/scsi/aic7xxx/aic7xxx_linux_host.h - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.16 linux/drivers/s390/char/tubio.h - 1.5 linux/drivers/block/paride/ppc6lnx.c - 1.4 linux/drivers/block/paride/bpck6.c - 1.4 linux/include/asm-i386/rwsem.h - 1.5 linux/arch/mips/mips-boards/generic/time.c - 1.3 linux/lib/rwsem.c - 1.3 linux/arch/mips/ite-boards/generic/time.c - 1.3 linux/arch/mips/ite-boards/generic/irq.c - 1.5 linux/include/linux/rwsem.h - 1.3 linux/drivers/net/wireless/Config.in - 1.7 linux/drivers/net/wireless/orinoco.c - 1.9 linux/include/asm-m68k/raw_io.h - 1.3 linux/include/asm-m68k/zorro.h - 1.3 linux/drivers/mtd/nftlcore.c - 1.19 linux/drivers/mtd/mtdblock_ro.c - 1.11 linux/drivers/media/radio/miropcm20-rds-core.c - 1.4 linux/drivers/acpi/utilities/utglobal.c - 1.9 linux/drivers/usb/serial/pl2303.h - 1.4 linux/drivers/acpi/include/acutils.h - 1.7 linux/drivers/acpi/include/platform/acenv.h - 1.8 linux/drivers/acpi/debugger/dbcmds.c - 1.7 linux/drivers/acpi/debugger/dbfileio.c - 1.8 linux/drivers/acpi/debugger/dbxface.c - 1.6 linux/drivers/acpi/executer/exutils.c - 1.7 linux/drivers/acpi/executer/excreate.c - 1.7 linux/drivers/acpi/executer/exdump.c - 1.9 linux/drivers/usb/serial/cyberjack.c - 1.15 linux/drivers/usb/serial/pl2303.c - 1.17 linux/arch/mips/kernel/old-irq.c - 1.4 linux/arch/mips/kernel/smp.c - 1.9 linux/arch/mips/mm/sb1.c - 1.3 linux/arch/mips/mm/rm7k.c - 1.4 linux/arch/mips/mm/r5432.c - 1.5 linux/arch/mips/mm/mips32.c - 1.5 linux/drivers/usb/usb-skeleton.c - 1.14 linux/drivers/char/ser_a2232.c - 1.5 linux/drivers/message/fusion/mptscsih.h - 1.4 linux/drivers/message/fusion/mptscsih.c - 1.8 linux/drivers/ieee1394/sbp2.c - 1.9 linux/drivers/ieee1394/sbp2.h - 1.8 linux/fs/partitions/ldm.h - 1.7 linux/fs/partitions/ldm.c - 1.7 linux/drivers/video/aty/mach64_gx.c - 1.3 linux/drivers/video/aty/Makefile - 1.3 linux/drivers/video/aty/atyfb.h - 1.2 linux/drivers/video/aty/atyfb_base.c - 1.12 linux/drivers/video/aty/mach64.h - 1.2 linux/drivers/video/aty/mach64_accel.c - 1.4 linux/drivers/video/aty/mach64_ct.c - 1.2 linux/drivers/video/aty/mach64_cursor.c - 1.3 linux/drivers/ide/serverworks.c - 1.15 linux/drivers/ide/it8172.c - 1.11 linux/drivers/ide/amd74xx.c - 1.15 linux/drivers/video/tx3912fb.c - 1.5 linux/drivers/video/sstfb.h - 1.3 linux/drivers/video/sstfb.c - 1.7 linux/Documentation/fb/README-sstfb.txt - 1.3 linux/drivers/scsi/dpti.h - 1.3 linux/drivers/scsi/dpt_i2o.c - 1.13 linux/drivers/ide/qd65xx.h - 1.3 linux/drivers/ide/qd65xx.c - 1.10 linux/arch/mips64/mips-boards/generic/time.c - 1.2 linux/arch/mips/gt64120/momenco_ocelot/irq.c - 1.2 linux/arch/mips/philips/nino/irq.c - 1.3 linux/Documentation/input/input-programming.txt - 1.2 linux/Documentation/input/input.txt - 1.3 linux/drivers/usb/serial/xircom_pgs.S - 1.2 linux/include/linux/raid/multipath.h - 1.5 linux/drivers/md/multipath.c - 1.11 linux/drivers/ide/pdcraid.c - 1.12 linux/drivers/ide/hptraid.c - 1.11 linux/drivers/ide/ataraid.c - 1.10 linux/arch/i386/kernel/nmi.c - 1.7 linux/include/asm-s390x/tlb.h - 1.3 linux/include/asm-s390/tlb.h - 1.3 linux/include/asm-m68k/tlb.h - 1.3 linux/include/asm-ia64/tlb.h - 1.3 linux/include/asm-i386/tlb.h - 1.3 linux/include/asm-sparc64/tlb.h - 1.4 linux/include/asm-arm/tlb.h - 1.3 linux/fs/jffs/jffs_proc.c - 1.3 linux/fs/namespace.c - 1.21 linux/fs/jffs/jffs_proc.h - 1.2 linux/drivers/ide/ide-m8xx.c - 1.5 linux/drivers/usb/serial/ir-usb.c - 1.17 linux/fs/quota.c - 1.15 linux/drivers/message/i2o/i2o_scsi.h - 1.2 linux/drivers/message/i2o/i2o_scsi.c - 1.7 linux/drivers/message/i2o/i2o_proc.c - 1.4 linux/drivers/message/i2o/i2o_pci.c - 1.5 linux/drivers/message/i2o/i2o_core.c - 1.6 linux/drivers/message/i2o/i2o_config.c - 1.6 linux/drivers/message/i2o/i2o_block.c - 1.17 linux/drivers/net/8139cp.c - 1.14 linux/drivers/acpi/executer/exoparg1.c - 1.7 linux/drivers/video/sis/300vtbl.h - 1.2 linux/drivers/video/sis/310vtbl.h - 1.2 linux/drivers/video/sis/325vtbl.h - 1.2 linux/drivers/video/sis/init.c - 1.2 linux/drivers/video/sis/init.h - 1.2 linux/drivers/video/sis/init301.c - 1.2 linux/drivers/video/sis/init301.h - 1.2 linux/drivers/video/sis/oem300.h - 1.2 linux/drivers/video/sis/oem310.h - 1.2 linux/drivers/video/sis/osdef.h - 1.2 linux/drivers/video/sis/sis_main.h - 1.3 linux/drivers/video/sis/vgatypes.h - 1.2 linux/drivers/video/sis/vstruct.h - 1.2 linux/drivers/hotplug/pci_hotplug_util.c - 1.3 linux/drivers/hotplug/pci_hotplug_core.c - 1.12 linux/drivers/hotplug/cpqphp_pci.c - 1.4 linux/drivers/hotplug/cpqphp_core.c - 1.5 linux/drivers/char/acpi_serial.c - 1.3 linux/include/linux/intermezzo_fs.h - 1.4 linux/include/linux/ext3_fs.h - 1.7 linux/include/linux/bio.h - 1.12 linux/fs/driverfs/inode.c - 1.17 linux/include/linux/device.h - 1.11 linux/init/do_mounts.c - 1.15 linux/drivers/usb/serial/ipaq.c - 1.10 linux/drivers/usb/serial/kl5kusb105.c - 1.10 linux/fs/xfs/pagebuf/page_buf.c - 1.47 linux/include/linux/init_task.h - 1.9 linux/drivers/ide/ide-taskfile.c - 1.18 linux/fs/ext2/ext2.h - 1.7 linux/drivers/video/neofb.c - 1.9 linux/fs/partitions/Config.help - 1.3 linux/arch/ppc/Config.help - 1.11 linux/drivers/video/Config.help - 1.4 linux/drivers/usb/serial/Config.help - 1.5 linux/drivers/usb/Config.help - 1.8 linux/drivers/ide/Config.help - 1.15 linux/drivers/hotplug/pcihp_skeleton.c - 1.2 linux/drivers/base/fs.c - 1.5 linux/drivers/pci/pci-driver.c - 1.8 linux/fs/xattr.c - 1.8 linux/drivers/input/joystick/grip.c - 1.3 linux/drivers/input/joystick/gf2k.c - 1.3 linux/drivers/input/joystick/gamecon.c - 1.4 linux/drivers/input/joystick/db9.c - 1.4 linux/drivers/input/joystick/cobra.c - 1.3 linux/drivers/input/joystick/analog.c - 1.4 linux/drivers/input/joystick/amijoy.c - 1.3 linux/drivers/input/joystick/adi.c - 1.4 linux/drivers/input/joystick/a3d.c - 1.3 linux/drivers/input/joystick/Makefile - 1.5 linux/drivers/input/joystick/Config.in - 1.4 linux/drivers/input/joystick/Config.help - 1.4 linux/drivers/input/joystick/interact.c - 1.3 linux/drivers/input/gameport/ns558.c - 1.3 linux/drivers/input/gameport/lightning.c - 1.3 linux/drivers/input/gameport/gameport.c - 1.4 linux/drivers/input/gameport/emu10k1-gp.c - 1.4 linux/drivers/input/gameport/cs461x.c - 1.4 linux/drivers/input/joystick/magellan.c - 1.4 linux/drivers/input/joystick/sidewinder.c - 1.3 linux/drivers/input/joystick/spaceball.c - 1.3 linux/drivers/input/joystick/spaceorb.c - 1.3 linux/drivers/input/joystick/stinger.c - 1.3 linux/drivers/input/joystick/tmdc.c - 1.3 linux/drivers/input/joystick/turbografx.c - 1.3 linux/drivers/input/joystick/warrior.c - 1.3 linux/drivers/input/serio/Config.in - 1.4 linux/drivers/input/serio/Makefile - 1.5 linux/drivers/input/serio/serio.c - 1.4 linux/drivers/input/serio/serport.c - 1.4 linux/include/asm-i386/thread_info.h - 1.4 linux/Documentation/preempt-locking.txt - 1.3 linux/sound/pci/via8233.c - 1.8 linux/sound/pci/via686.c - 1.7 linux/sound/pci/nm256/nm256.c - 1.7 linux/sound/pci/maestro3.c - 1.7 linux/sound/pci/intel8x0.c - 1.8 linux/sound/pci/ice1712.c - 1.8 linux/arch/ppc/4xx_io/Makefile - 1.2 linux/arch/ppc/4xx_io/stb_kb.c - 1.4 linux/sound/pci/ens1370.c - 1.7 linux/sound/pci/cs4281.c - 1.8 linux/sound/pci/cmipci.c - 1.9 linux/sound/pci/ali5451/ali5451.c - 1.7 linux/sound/pci/Config.in - 1.5 linux/arch/ppc/kernel/iSeries_head.S - 1.5 linux/arch/ppc/kernel/iSeries_misc.S - 1.4 linux/sound/oss/i810_audio.c - 1.5 linux/sound/oss/esssolo1.c - 1.3 linux/arch/ppc/kernel/ppc4xx_setup.c - 1.6 linux/arch/ppc/platforms/adir_setup.c - 1.3 linux/arch/ppc/platforms/apus_setup.c - 1.3 linux/arch/ppc/platforms/chrp_setup.c - 1.8 linux/arch/ppc/platforms/chrp_smp.c - 1.3 linux/arch/ppc/platforms/ev64260_setup.c - 1.3 linux/arch/ppc/platforms/gemini_setup.c - 1.4 linux/arch/ppc/platforms/iSeries_pic.c - 1.2 linux/arch/ppc/platforms/iSeries_smp.c - 1.3 linux/arch/ppc/platforms/k2_setup.c - 1.4 linux/arch/ppc/platforms/lopec_setup.c - 1.7 linux/arch/ppc/platforms/mcpn765_setup.c - 1.5 linux/arch/ppc/platforms/menf1_setup.c - 1.4 linux/arch/ppc/platforms/mvme5100_setup.c - 1.3 linux/arch/ppc/platforms/pcore_setup.c - 1.3 linux/arch/ppc/platforms/pmac_smp.c - 1.5 linux/arch/ppc/platforms/powerpmc250.c - 1.3 linux/arch/ppc/platforms/pplus_setup.c - 1.6 linux/arch/ppc/platforms/prep_setup.c - 1.8 linux/arch/ppc/platforms/prpmc750_setup.c - 1.3 linux/arch/ppc/platforms/prpmc800_setup.c - 1.3 linux/arch/ppc/platforms/redwood.c - 1.2 linux/arch/ppc/platforms/sandpoint_setup.c - 1.6 linux/arch/ppc/platforms/spruce.h - 1.2 linux/arch/ppc/platforms/spruce_setup.c - 1.4 linux/arch/ppc/platforms/walnut.c - 1.2 linux/arch/ppc/platforms/walnut.h - 1.2 linux/arch/ppc/platforms/zx4500_setup.c - 1.3 linux/arch/x86_64/config.in - 1.10 linux/arch/x86_64/kernel/apic.c - 1.3 linux/arch/x86_64/kernel/irq.c - 1.4 linux/arch/x86_64/kernel/ldt.c - 1.4 linux/arch/x86_64/kernel/mtrr.c - 1.6 linux/arch/x86_64/kernel/process.c - 1.7 linux/arch/x86_64/kernel/smp.c - 1.6 linux/arch/x86_64/kernel/traps.c - 1.6 linux/sound/isa/ad1848/ad1848_lib.c - 1.5 linux/include/asm-x86_64/ide.h - 1.5 linux/include/asm-x86_64/system.h - 1.5 linux/include/asm-x86_64/tlb.h - 1.3 linux/include/asm-ppc64/hardirq.h - 1.3 linux/include/asm-ppc64/time.h - 1.4 linux/arch/ppc64/mm/fault.c - 1.4 linux/arch/ppc64/mm/init.c - 1.6 linux/include/asm-ppc64/current.h - 1.2 linux/include/asm-ppc64/cache.h - 1.2 linux/include/asm-ppc64/ide.h - 1.4 linux/include/asm-ppc64/init.h - 1.2 linux/include/asm-ppc64/bitops.h - 1.3 linux/arch/ppc64/Makefile - 1.6 linux/arch/ppc64/boot/Makefile - 1.4 linux/arch/ppc64/config.in - 1.8 linux/arch/ppc64/defconfig - 1.5 linux/arch/ppc64/kernel/LparData.c - 1.4 linux/arch/ppc64/kernel/Makefile - 1.6 linux/arch/ppc64/kernel/XmPciLpEvent.c - 1.2 linux/arch/ppc64/kernel/align.c - 1.3 linux/arch/ppc64/kernel/binfmt_elf32.c - 1.2 linux/arch/ppc64/kernel/chrp_setup.c - 1.5 linux/arch/ppc64/kernel/eeh.c - 1.3 linux/arch/ppc64/kernel/entry.S - 1.6 linux/arch/ppc64/kernel/head.S - 1.4 linux/arch/ppc64/kernel/htab.c - 1.4 linux/arch/ppc64/kernel/iSeries_pci.c - 1.4 linux/arch/ppc64/kernel/iSeries_pci_reset.c - 1.2 linux/arch/ppc64/kernel/iSeries_setup.c - 1.5 linux/arch/ppc64/kernel/irq.c - 1.4 linux/arch/ppc64/kernel/misc.S - 1.4 linux/arch/ppc64/kernel/mk_defs.c - 1.5 linux/arch/ppc64/kernel/open_pic.c - 1.3 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.4 linux/arch/ppc64/kernel/pSeries_pci.c - 1.5 linux/arch/ppc64/kernel/pacaData.c - 1.4 linux/arch/ppc64/kernel/pci_dn.c - 1.3 linux/arch/ppc64/kernel/pmc.c - 1.3 linux/arch/ppc64/kernel/ppc_asm.h - 1.3 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.5 linux/arch/ppc64/kernel/proc_pmc.c - 1.3 linux/arch/ppc64/kernel/process.c - 1.5 linux/arch/ppc64/kernel/prom.c - 1.5 linux/arch/ppc64/kernel/ptrace.c - 1.2 linux/arch/ppc64/kernel/ptrace32.c - 1.2 linux/arch/ppc64/kernel/rtas-proc.c - 1.3 linux/arch/ppc64/kernel/rtas.c - 1.3 linux/arch/ppc64/kernel/rtasd.c - 1.4 linux/arch/ppc64/kernel/rtc.c - 1.3 linux/arch/ppc64/kernel/setup.c - 1.6 linux/arch/ppc64/kernel/signal.c - 1.6 linux/arch/ppc64/kernel/signal32.c - 1.6 linux/arch/ppc64/kernel/smp.c - 1.7 linux/arch/ppc64/kernel/stab.c - 1.5 linux/arch/ppc64/kernel/time.c - 1.5 linux/arch/ppc64/kernel/traps.c - 1.4 linux/arch/ppc64/kernel/xics.c - 1.4 linux/arch/ppc64/lib/string.S - 1.5 linux/arch/ppc64/vmlinux.lds - 1.4 linux/arch/ppc64/xmon/privinst.h - 1.2 linux/arch/ppc64/xmon/start.c - 1.4 linux/arch/ppc64/xmon/xmon.c - 1.5 linux/include/asm-ppc64/lmb.h - 1.3 linux/include/asm-ppc64/machdep.h - 1.4 linux/include/asm-ppc64/md.h - 1.2 linux/include/asm-ppc64/hw_irq.h - 1.3 linux/include/asm-ppc64/iSeries/HvCall.h - 1.3 linux/include/asm-ppc64/iSeries/HvCallHpt.h - 1.3 linux/include/asm-ppc64/iSeries/HvCallSc.h - 1.2 linux/include/asm-ppc64/vc_ioctl.h - 1.2 linux/include/asm-ppc64/uaccess.h - 1.4 linux/include/asm-ppc64/tlb.h - 1.2 linux/include/asm-ppc64/system.h - 1.5 linux/include/asm-ppc64/softirq.h - 1.2 linux/include/asm-ppc64/smplock.h - 1.2 linux/include/asm-ppc64/smp.h - 1.3 linux/include/asm-ppc64/iSeries/LparData.h - 1.3 linux/include/asm-ppc64/rtas.h - 1.3 linux/include/asm-ppc64/prom.h - 1.2 linux/include/asm-ppc64/processor.h - 1.5 linux/include/asm-ppc64/pgtable.h - 1.5 linux/include/asm-ppc64/pgalloc.h - 1.4 linux/include/asm-ppc64/param.h - 1.2 linux/include/asm-ppc64/page.h - 1.5 linux/Documentation/filesystems/jfs.txt - 1.2 linux/drivers/hotplug/ibmphp_core.c - 1.5 linux/fs/jfs/file.c - 1.6 linux/fs/jfs/inode.c - 1.7 linux/fs/jfs/jfs_dtree.c - 1.6 linux/fs/jfs/namei.c - 1.7 linux/fs/jfs/jfs_logmgr.c - 1.12 linux/fs/jfs/super.c - 1.10 linux/fs/jfs/symlink.c - 1.4 linux/fs/jfs/jfs_mount.c - 1.7 linux/fs/jfs/jfs_txnmgr.c - 1.10 linux/drivers/net/tulip/de2104x.c - 1.2 linux/drivers/net/tulip/de4x5.c - 1.3 linux/drivers/net/tulip/winbond-840.c - 1.2 linux/arch/ia64/sn/kernel/sv.c - 1.2 linux/arch/ia64/sn/kernel/llsc4.c - 1.3 linux/include/asm-i386/acpi.h - 1.4 linux/drivers/ide/ata-timing.c - 1.5 linux/drivers/ide/ata-timing.h - 1.6 linux/include/asm-ppc64/tlbflush.h - 1.3 linux/drivers/usb/class/Config.help - 1.3 linux/drivers/usb/image/microtek.c - 1.2 linux/drivers/usb/class/audio.c - 1.5 linux/drivers/usb/class/bluetty.c - 1.6 linux/drivers/usb/input/Config.help - 1.4 linux/drivers/usb/class/cdc-acm.c - 1.6 linux/drivers/usb/class/printer.c - 1.7 linux/drivers/usb/core/devices.c - 1.3 linux/drivers/usb/core/devio.c - 1.6 linux/drivers/usb/core/drivers.c - 1.4 linux/drivers/usb/core/hcd.c - 1.7 linux/drivers/usb/core/hub.c - 1.6 linux/drivers/usb/core/inode.c - 1.6 linux/drivers/usb/input/hid-core.c - 1.5 linux/drivers/usb/core/usb.c - 1.10 linux/drivers/usb/host/Config.help - 1.4 linux/drivers/usb/host/Config.in - 1.7 linux/drivers/usb/host/Makefile - 1.7 linux/drivers/usb/host/ehci-hcd.c - 1.6 linux/drivers/usb/host/ehci-q.c - 1.7 linux/drivers/usb/host/ehci-sched.c - 1.6 linux/drivers/usb/host/ohci-dbg.c - 1.6 linux/drivers/usb/host/ohci-hcd.c - 1.9 linux/drivers/usb/host/ohci-hub.c - 1.5 linux/fs/partitions/efi.h - 1.2 linux/fs/partitions/efi.c - 1.4 linux/drivers/usb/host/ohci-q.c - 1.7 linux/drivers/usb/host/ohci.h - 1.6 linux/drivers/usb/media/stv680.c - 1.6 linux/drivers/usb/media/usbvideo.c - 1.5 linux/drivers/usb/host/usb-ohci.c - 1.6 linux/drivers/usb/host/usb-ohci.h - 1.3 linux/drivers/usb/image/hpusbscsi.c - 1.4 linux/drivers/usb/image/mdc800.c - 1.6 linux/drivers/usb/image/scanner.c - 1.8 linux/drivers/usb/image/scanner.h - 1.5 linux/drivers/usb/input/Config.in - 1.5 linux/drivers/usb/input/Makefile - 1.6 linux/drivers/usb/input/hid-input.c - 1.3 linux/drivers/usb/input/hid.h - 1.3 linux/drivers/usb/input/hiddev.c - 1.7 linux/drivers/usb/input/usbkbd.c - 1.2 linux/drivers/usb/input/usbmouse.c - 1.2 linux/drivers/usb/input/wacom.c - 1.2 linux/drivers/usb/media/dabusb.c - 1.7 linux/drivers/usb/media/dsbr100.c - 1.3 linux/drivers/usb/media/ov511.c - 1.6 linux/drivers/usb/media/ov511.h - 1.3 linux/drivers/usb/media/pwc-if.c - 1.4 linux/drivers/usb/storage/Config.in - 1.3 linux/drivers/usb/storage/Config.help - 1.3 linux/drivers/usb/serial/safe_serial.c - 1.5 linux/drivers/usb/media/se401.c - 1.6 linux/drivers/usb/net/usbnet.c - 1.8 linux/drivers/usb/net/rtl8150.c - 1.6 linux/drivers/usb/net/pegasus.c - 1.7 linux/drivers/usb/media/vicam.c - 1.3 linux/drivers/usb/net/kaweth.c - 1.5 linux/drivers/usb/net/cdc-ether.c - 1.5 linux/drivers/usb/net/catc.c - 1.3 linux/mm/readahead.c - 1.6 linux/drivers/usb/misc/Config.help - 1.3 linux/drivers/usb/misc/uss720.c - 1.2 linux/drivers/usb/misc/auerswald.c - 1.6 linux/drivers/usb/misc/emi26.c - 1.4 linux/drivers/usb/misc/rio500.c - 1.4 linux/arch/ppc64/kernel/nvram.c - 1.2 linux/arch/ppc64/kernel/pSeries_htab.c - 1.3 linux/drivers/usb/misc/tiglusb.c - 1.5 linux/drivers/usb/misc/tiglusb.h - 1.2 linux/arch/ia64/hp/sim/simscsi.h - 1.2 linux/arch/ia64/hp/sim/simscsi.c - 1.2 linux/drivers/usb/misc/brlvger.c - 1.5 linux/drivers/scsi/scsi_mid_low_api.txt - 1.2 linux/drivers/ide/tcq.c - 1.9 linux/drivers/block/umem.c - 1.3 linux/include/asm-m68k/tlbflush.h - 1.2 linux/drivers/usb/host/uhci-debug.c - 1.2 linux/drivers/ide/quirks.c - 1.2 linux/drivers/usb/host/uhci-hcd.c - 1.6 linux/include/asm-m68k/cacheflush.h - 1.2 linux/drivers/ide/pcidma.c - 1.8 linux/arch/i386/pci/direct.c - 1.3 linux/fs/fs-writeback.c - 1.5 linux/include/linux/page-flags.h - 1.3 linux/arch/i386/pci/pcbios.c - 1.3 linux/mm/page-writeback.c - 1.6 linux/include/linux/buffer_head.h - 1.8 linux/include/asm-ppc64/naca.h - 1.2 linux/include/asm-ppc64/paca.h - 1.3 linux/include/linux/writeback.h - 1.6 linux/drivers/ide/atapi.c - 1.2 linux/drivers/ide/ioctl.c - 1.8 linux/drivers/ide/main.c - 1.5 linux/include/linux/atapi.h - 1.4 linux/drivers/ide/probe.c - 1.7 linux/drivers/usb/host/hc_simple.c - 1.3 linux/include/linux/mpage.h - 1.2 linux/fs/mpage.c - 1.4 linux/drivers/char/hvc_console.c - 1.2 linux/drivers/usb/host/usb-ohci-sa1111.c - 1.3 linux/drivers/usb/host/usb-ohci-pci.c - 1.3 linux/drivers/usb/core/message.c - 1.5 linux/drivers/acpi/ac.c - 1.2 linux/drivers/acpi/battery.c - 1.3 linux/drivers/acpi/bus.c - 1.4 linux/drivers/acpi/pci_root.c - 1.4 linux/drivers/acpi/fan.c - 1.2 linux/drivers/acpi/pci_link.c - 1.3 linux/drivers/acpi/button.c - 1.2 linux/drivers/acpi/pci_irq.c - 1.4 linux/drivers/acpi/thermal.c - 1.3 linux/drivers/acpi/system.c - 1.5 linux/drivers/acpi/processor.c - 1.5 linux/drivers/ide/device.c - 1.5 linux/drivers/usb/host/ohci-sa1111.c - 1.3 linux/drivers/usb/class/usb-midi.c - 1.3 linux/drivers/s390/net/lcs.c - 1.2 linux/arch/i386/kernel/suspend.c - 1.4 linux/drivers/s390/cio/s390io.c - 1.2 linux/drivers/usb/host/ohci-pci.c - 1.2 linux/drivers/s390/block/dasd_ioctl.c - 1.2 linux/arch/i386/kernel/cpu/common.c - 1.3 linux/drivers/usb/input/aiptek.c - 1.3 linux/arch/x86_64/pci/direct.c - 1.2 linux/drivers/input/joystick/guillemot.c - 1.2 linux/drivers/input/keyboard/maple_keyb.c - 1.2 linux/drivers/input/keyboard/atkbd.c - 1.3 linux/drivers/input/tsdev.c - 1.2 linux/drivers/input/touchscreen/gunze.c - 1.2 linux/drivers/input/serio/rpckbd.c - 1.3 linux/drivers/input/serio/parkbd.c - 1.3 linux/drivers/input/serio/i8042.c - 1.3 linux/drivers/input/serio/ct82c710.c - 1.3 linux/drivers/input/evbug.c - 1.3 linux/drivers/input/gameport/fm801-gp.c - 1.2 linux/drivers/input/gameport/vortex.c - 1.2 linux/drivers/input/power.c - 1.2 linux/drivers/input/mouse/sermouse.c - 1.2 linux/drivers/input/mouse/rpcmouse.c - 1.3 linux/drivers/input/mouse/psmouse.c - 1.3 linux/drivers/input/mouse/pc110pad.c - 1.2 linux/drivers/input/mouse/maplemouse.c - 1.2 linux/drivers/input/mouse/logibm.c - 1.2 linux/drivers/input/mouse/inport.c - 1.2 linux/drivers/input/mouse/amimouse.c - 1.3 linux/drivers/input/joystick/iforce/iforce-main.c - 1.3 linux/drivers/input/keyboard/xtkbd.c - 1.2 linux/drivers/input/keyboard/sunkbd.c - 1.2 linux/drivers/input/keyboard/ps2serkbd.c - 1.2 linux/drivers/input/joystick/iforce/iforce-packets.c - 1.3 linux/drivers/input/joystick/iforce/iforce-serio.c - 1.2 linux/drivers/input/keyboard/amikbd.c - 1.2 linux/drivers/input/keyboard/Makefile - 1.3 linux/drivers/input/keyboard/Config.in - 1.3 linux/drivers/input/keyboard/Config.help - 1.3 linux/drivers/input/joystick/twidjoy.c - 1.2 linux/drivers/usb/core/file.c - 1.2 linux/drivers/input/joystick/iforce/iforce-usb.c - 1.2 linux/drivers/acpi/tables/tbrsdt.c - 1.2 linux/include/linux/uinput.h - 1.2 linux/drivers/acpi/include/amlresrc.h - 1.2 linux/drivers/input/joystick/joydump.c - 1.2 linux/Documentation/input/xpad.txt - 1.2 linux/drivers/input/keyboard/newtonkbd.c - 1.2 linux/drivers/input/serio/i8042-ppcio.h - 1.2 linux/drivers/input/serio/q40kbd.c - 1.2 linux/fs/direct-io.c - 1.2 linux/drivers/input/touchscreen/h3600_ts_input.c - 1.2 linux/drivers/input/uinput.c - 1.2 linux/drivers/usb/input/powermate.c - 1.2 linux/drivers/usb/input/xpad.c - 1.2 linux/drivers/usb/input/hid-lgff.c - 1.2 linux/drivers/usb/input/hid-lg3dff.c - 1.2 linux/drivers/usb/input/hid-ff.c - 1.2 linux/drivers/usb/input/fixp-arith.h - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jul 30 15:09:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UM9ZRw005924 for ; Tue, 30 Jul 2002 15:09:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UM9Zg0005923 for linux-xfs-outgoing; Tue, 30 Jul 2002 15:09:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web13107.mail.yahoo.com (web13107.mail.yahoo.com [216.136.174.152]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UM92Rw005894 for ; Tue, 30 Jul 2002 15:09:02 -0700 Message-ID: <20020730221030.24542.qmail@web13107.mail.yahoo.com> Received: from [208.35.40.2] by web13107.mail.yahoo.com via HTTP; Tue, 30 Jul 2002 15:10:30 PDT Date: Tue, 30 Jul 2002 15:10:30 -0700 (PDT) From: Ravi Wijayaratne Subject: XFS stack overflow To: linux-xfs@oss.sgi.com Cc: lord@sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi All, We are experiencing an XFS stack overflow. Not a recurrent issue, but happens once in a while. Here is the oops message spewed out by our stack depth checker. It calls BUG() as soon as it sees some thing has overwritten the task_struct The oops was deliberately triggered. So please dont worry about the oops. My worry is the call depth 114. Here is the data about the system. Kernel: 2.4.18 XFS version: 1.1 LVM version: 1.0.3 any insights ? thanx Ravi ------ oops message ------ invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010293 eax: ce17e000 ebx: ce17e000 ecx: ed038364 edx: c035fb44 esi: ce17ecf8 edi: ed03834c ebp: ce17ecc0 esp: ce17ec7c ds: 0018 es: 0018 ss: 0018 Process smbd (pid: 14968, stackpage=ce17f000) Stack: ce17e000 ce17ecf8 ed03834c d7750320 00000286 c024b583 efea25c0 00000000 c0240944 00000286 ce17e000 c011835f c035faf0 ce17e000 ce17ecf8 ed038364 c035fb44 d7750320 c025ebd5 ed038000 00000000 00000000 d7750320 00003a00 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 8b 55 f0 83 7a 50 00 75 02 0f 0b 8b 4d f0 89 4d f8 8b >>EIP; c0111812 <===== >>eax; ce17e000 <_end+de14604/30496604> >>ebx; ce17e000 <_end+de14604/30496604> >>ecx; ed038364 <_end+2ccce968/30496604> >>edx; c035fb44 >>esi; ce17ecf8 <_end+de152fc/30496604> >>edi; ed03834c <_end+2ccce950/30496604> >>ebp; ce17ecc0 <_end+de152c4/30496604> >>esp; ce17ec7c <_end+de15280/30496604> Trace; c024b583 Trace; c0240944 Trace; c011835f <__run_task_queue+4f/5c> Trace; c025ebd5 Trace; c0260a30 Trace; c0264248 Trace; c02413f9 Trace; c01df438 <_pagebuf_page_io+290/324> Trace; c01df5c2 <_page_buf_page_apply+f6/108> Trace; c01dfa3a Trace; c01df6c4 Trace; c01df4cc <_page_buf_page_apply+0/108> Trace; c01deeed Trace; c01dea15 Trace; c01d218e Trace; c01a2d5d Trace; c0186c84 Trace; c0186cc1 Trace; c0188824 Trace; c0182f1d Trace; c01836cc Trace; c0183166 Trace; c01854de Trace; c019504e Trace; c029894e Trace; c01ddef6 Trace; c0117ffd Trace; c027361a Trace; c029162b Trace; c01e1e4b <_pagebuf_find_lockable_buffer+1ab/1dc> Trace; c01990c9 Trace; c01299e0 <_alloc_pages+18/1c> Trace; c0129cca <__get_free_pages+a/18> Trace; c01a91b2 Trace; f08b29f5 <[e1000]e1000_xmit_frame+1e9/4b0> Trace; c01ebbd5 Trace; c01c001f Trace; c01d2948 Trace; c01aae75 Trace; f08b29f5 <[e1000]e1000_xmit_frame+1e9/4b0> Trace; f08b29f5 <[e1000]e1000_xmit_frame+1e9/4b0> Trace; f090e8cf Trace; c027cb03 Trace; f0909968 Trace; f0901766 Trace; f0901777 Trace; c0277097 Trace; c0284980 Trace; c027cb03 Trace; c0284980 Trace; c02771fa Trace; c0284a2f Trace; c0284980 Trace; c0284e4d Trace; f08b29f5 <[e1000]e1000_xmit_frame+1e9/4b0> Trace; f08b29f5 <[e1000]e1000_xmit_frame+1e9/4b0> Trace; c027cb03 Trace; c02771fa Trace; f0900b54 Trace; f090e3ad Trace; f090e35c Trace; f090e8cf Trace; f0909968 Trace; f0901766 Trace; f0901777 Trace; c0277097 Trace; c0284980 Trace; c027cb03 Trace; c0284980 Trace; c02771fa Trace; c0284a2f Trace; c0284980 Trace; c0284e4d Trace; c0284980 Trace; c0292e5f Trace; c0292ef9 Trace; c0273b37 Trace; c029395f Trace; c029100d <__tcp_data_snd_check+4d/c0> Trace; c0290fb8 Trace; c02913f0 Trace; c029894e Trace; c0298dbb Trace; c0282657 Trace; c02829bf Trace; c027771d Trace; c0117ffd Trace; c0108164 Trace; c01ea918 Trace; c01d0000 Trace; c01b0000 Trace; c01bcea0 Trace; c01bcf35 Trace; c01ebd80 Trace; c01c1bfb Trace; c01d27e9 Trace; c01d2948 Trace; c01bf060 Trace; c01b187c Trace; c01a8a1f Trace; c01a8a8d Trace; c017cd12 Trace; c01d825f Trace; c0182776 Trace; c01e4c4d Trace; c01d7cc4 Trace; c01e4dec Trace; c0138761 Trace; c01388ff Trace; c012e933 Trace; c012ec7a Trace; c0106ddb Code; c0111812 00000000 <_EIP>: Code; c0111812 <===== 0: 0f 0b ud2a <===== Code; c0111814 2: 8b 55 f0 mov 0xfffffff0(%ebp),%edx Code; c0111817 5: 83 7a 50 00 cmpl $0x0,0x50(%edx) Code; c011181b 9: 75 02 jne d <_EIP+0xd> c011181f Code; c011181d b: 0f 0b ud2a Code; c011181f d: 8b 4d f0 mov 0xfffffff0(%ebp),%ecx Code; c0111822 10: 89 4d f8 mov %ecx,0xfffffff8(%ebp) Code; c0111825 13: 8b 00 mov (%eax),%eax ===== ------------------------------ Ravi Wijayaratne __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-linux-xfs@oss.sgi.com Tue Jul 30 16:57:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6UNvtRw011786 for ; Tue, 30 Jul 2002 16:57:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6UNvshc011785 for linux-xfs-outgoing; Tue, 30 Jul 2002 16:57:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rebel.net.au (IDENT:root@mail.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6UNvnRw011757 for ; Tue, 30 Jul 2002 16:57:50 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id JAA23260; Wed, 31 Jul 2002 09:43:43 +0930 Message-ID: <3D472A86.FB308C23@rebel.net.au> Date: Wed, 31 Jul 2002 09:38:38 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: What Does "kernel mtrr" mean... References: <25369.1028019016@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk That's all very well, but I still don't quite understand what the messages mean :-( DSL From owner-linux-xfs@oss.sgi.com Tue Jul 30 22:22:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6V5MARw006752 for ; Tue, 30 Jul 2002 22:22:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6V5MAUv006751 for linux-xfs-outgoing; Tue, 30 Jul 2002 22:22:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6V5M4Rw006630 for ; Tue, 30 Jul 2002 22:22:05 -0700 Received: from [209.96.179.193] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 17ZlxM-0003S9-00; Wed, 31 Jul 2002 01:23:33 -0400 Received: from daydream.shannon.net (daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g6V4tJs15854; Wed, 31 Jul 2002 00:55:19 -0400 (EDT) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id g6V4tFXM016732; Wed, 31 Jul 2002 00:55:15 -0400 Received: from localhost (localhost [[UNIX: localhost]]) by daydream.shannon.net (8.12.4/8.12.4/Submit) id g6V4tAcM016731; Wed, 31 Jul 2002 00:55:10 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Charles Shannon Hendrix Reply-To: shannon@widomaker.com Organization: Big Endian To: Keith Matthews , Subject: Re: logdev on IDE Date: Wed, 31 Jul 2002 00:55:10 -0400 User-Agent: KMail/1.4.1 References: <1027535026.1648.5.camel@stantz.corp.sgi.com> <20020727152441.GA9977@widomaker.com> <20020727172200.0d9e5c54.keith_m@sweeney.demon.co.uk> In-Reply-To: <20020727172200.0d9e5c54.keith_m@sweeney.demon.co.uk> MIME-Version: 1.0 Message-Id: <200207310055.10155.csh@spamcop.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6V5M5Rw006649 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,ASCII_FORM_ENTRY,DIFFERENT_REPLY_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Saturday 27 July 2002 12:22 pm, Keith Matthews wrote: > I understand that this was through a hole in the ATA spec that was > closed about 6 months ago. I have no idea if there are any drives to > the old spec still in the supply chain, but those currently being > manufactured are probably OK. That's interesting. I had always heard it was pretty deliberate, and often driven by benchmarking tests. This is good if true, though I still don't really like IDE drives. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Tue Jul 30 23:00:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6V60XRw011106 for ; Tue, 30 Jul 2002 23:00:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6V60XTx011105 for linux-xfs-outgoing; Tue, 30 Jul 2002 23:00:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blade.4t2.com (blade.4t2.com [194.77.116.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6V60RRw011077 for ; Tue, 30 Jul 2002 23:00:27 -0700 Received: from mx.sem-gmbh.com ([172.16.11.10]:23684 "EHLO ipsec.blade.4t2.com" ident: "NO-IDENT-SERVICE[2]" smtp-auth: TLS-PEER: ) by blade.4t2.com with ESMTP id ; Wed, 31 Jul 2002 08:01:31 +0200 Received: from sem-dev01.sem-gmbh.com ([194.99.20.211]:8711 "EHLO sem-gmbh.com") by sem-two.sem-gmbh.com with ESMTP id ; Wed, 31 Jul 2002 07:48:12 +0200 Message-ID: <3D4779F9.70309@sem-gmbh.com> Date: Wed, 31 Jul 2002 07:47:37 +0200 From: Dirk Munzinger User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.0.0) Gecko/20020530 X-Accept-Language: de, de-at, en-us, en MIME-Version: 1.0 To: "Ralf G. R. Bergs" CC: "linux-xfs@oss.sgi.com" Subject: Re: xfs-filesystem is broken after rsync (log-info) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Moin, Ralf G. R. Bergs schrieb: > On Tue, 30 Jul 2002 16:34:28 +0200, Dirk Munzinger wrote: >>By the way befor I switched the partition to xfs it was formated with >>reiserfs and there were no problems. The disk itself also seams to be ok. > > > Well, *seems* to be ok or *is* ok?! > > I'm asking this since we also had a hell of problems when we tried to migrate > our RAID to XFS. It turned out that it wasn't XFS' fault but that the XFS drive > was bad... :-(( Good question ;-) At the moment it seems to be OK but I will check it again with an other fs later and let you know. - Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 31 00:41:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6V7fTRw013520 for ; Wed, 31 Jul 2002 00:41:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6V7fTdI013519 for linux-xfs-outgoing; Wed, 31 Jul 2002 00:41:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6V7fKRw013491 for ; Wed, 31 Jul 2002 00:41:21 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6V7gns3006853; Wed, 31 Jul 2002 09:42:49 +0200 (CEST) Message-Id: <4.3.2.7.2.20020731093817.033587a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jul 2002 09:41:22 +0200 To: Dirk Munzinger , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs-filesystem is broken after rsync (log-info) In-Reply-To: <3D4779F9.70309@sem-gmbh.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 07:47 31-7-2002 +0200, you wrote: >Moin, > >Ralf G. R. Bergs schrieb: >>On Tue, 30 Jul 2002 16:34:28 +0200, Dirk Munzinger wrote: > >>>By the way befor I switched the partition to xfs it was formated with >>>reiserfs and there were no problems. The disk itself also seams to be ok. >> >>Well, *seems* to be ok or *is* ok?! >>I'm asking this since we also had a hell of problems when we tried to >>migrate our RAID to XFS. It turned out that it wasn't XFS' fault but that >>the XFS drive was bad... :-(( > >Good question ;-) At the moment it seems to be OK but I will check it >again with an other fs later and let you know. I have a number of XFS boxes and they all use rsync in one way or the other in 15,30 or 6 hour intervals and all goes well. I suspect broken hardware. It can sometimes be very subtle and only be caused by certain access patterns or drivers. Can you try checking out a XFS CVS tree? I believe you said you were using the 1.1 release. I have good results with the 2.4.19-rc3-xfs CVS tree on a number of different systems and it works really well. Can you check if this helps for you? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 31 01:15:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6V8FDRw013987 for ; Wed, 31 Jul 2002 01:15:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6V8FDfM013986 for linux-xfs-outgoing; Wed, 31 Jul 2002 01:15:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blade.4t2.com (blade.4t2.com [194.77.116.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6V8F6Rw013957 for ; Wed, 31 Jul 2002 01:15:06 -0700 Received: from mx.sem-gmbh.com ([172.16.11.10]:29830 "EHLO ipsec.blade.4t2.com" ident: "NO-IDENT-SERVICE[2]" smtp-auth: TLS-PEER: ) by blade.4t2.com with ESMTP id ; Wed, 31 Jul 2002 10:16:25 +0200 Received: from sem-dev01.sem-gmbh.com ([194.99.20.211]:24584 "EHLO sem-gmbh.com") by sem-two.sem-gmbh.com with ESMTP id ; Wed, 31 Jul 2002 10:01:29 +0200 Message-ID: <3D479933.4050307@sem-gmbh.com> Date: Wed, 31 Jul 2002 10:00:51 +0200 From: Dirk Munzinger User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.0.0) Gecko/20020530 X-Accept-Language: de, de-at, en-us, en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync (log-info) References: <4.3.2.7.2.20020731093817.033587a0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Seth Mos schrieb: > At 07:47 31-7-2002 +0200, you wrote: > > > I have a number of XFS boxes and they all use rsync in one way or the > other in 15,30 or 6 hour intervals and all goes well. I suspect broken > hardware. It can sometimes be very subtle and only be caused by certain > access patterns or drivers. I have just tested with a reiserfs on this partition again and everything is OK. Now I have switched back to xfs and rsync is running at the moment with no problem yet - but I have to wait until it is finished. > Can you try checking out a XFS CVS tree? I believe you said you were > using the 1.1 release. > I have good results with the 2.4.19-rc3-xfs CVS tree on a number of > different systems and it works really well. Can you check if this helps > for you? I really don't want to move to the 2.4.19 kernel because I am using 2.418 kernels patched with some other stuff like ipsec and they are working OK. The other problem is that this servers are in production so playing around with other kernels etc. might raise my daily telephone-ring-rate ;-) Regards, Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 31 01:32:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6V8WSRw014245 for ; Wed, 31 Jul 2002 01:32:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6V8WSOo014244 for linux-xfs-outgoing; Wed, 31 Jul 2002 01:32:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6V8WJRw014216 for ; Wed, 31 Jul 2002 01:32:19 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6V8Xlft008918; Wed, 31 Jul 2002 10:33:47 +0200 (CEST) Message-Id: <4.3.2.7.2.20020731102815.03304d28@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jul 2002 10:32:15 +0200 To: Dirk Munzinger From: Seth Mos Subject: Re: xfs-filesystem is broken after rsync (log-info) Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D479933.4050307@sem-gmbh.com> References: <4.3.2.7.2.20020731093817.033587a0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:00 31-7-2002 +0200, Dirk Munzinger wrote: >Hi, > >Seth Mos schrieb: >>At 07:47 31-7-2002 +0200, you wrote: >> >>I have a number of XFS boxes and they all use rsync in one way or the >>other in 15,30 or 6 hour intervals and all goes well. I suspect broken >>hardware. It can sometimes be very subtle and only be caused by certain >>access patterns or drivers. > >I have just tested with a reiserfs on this partition again and everything >is OK. Now I have switched back to xfs and rsync is running at the moment >with no problem yet - but I have to wait until it is finished. Did you try newer utilities to create the filesystem or newer repair tools perhaps? That might help. The 1.1 release is some time ago and the world has changed significantly since then. >I really don't want to move to the 2.4.19 kernel because I am using 2.418 >kernels patched with some other stuff like ipsec and they are working OK. >The other problem is that this servers are in production so playing around >with other kernels etc. might raise my daily telephone-ring-rate ;-) I believe ipsec plays nice with 2.4.19. Afaik nothing fundamental changed from 2.4.18 to 2.4.19. I'll try it out when I have time. 2.4.18 is ok and stable for me but the newer XFS code is only made available in CVS or releases. Maybe a 2.4.19 XFS release when 2.4.19 is done ;) *wink* Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 31 01:45:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6V8jDRw014489 for ; Wed, 31 Jul 2002 01:45:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6V8jDsU014488 for linux-xfs-outgoing; Wed, 31 Jul 2002 01:45:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blade.4t2.com (blade.4t2.com [194.77.116.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6V8j6Rw014459 for ; Wed, 31 Jul 2002 01:45:07 -0700 Received: from mx.sem-gmbh.com ([172.16.11.10]:42886 "EHLO ipsec.blade.4t2.com" ident: "NO-IDENT-SERVICE[2]" smtp-auth: TLS-PEER: ) by blade.4t2.com with ESMTP id ; Wed, 31 Jul 2002 10:46:28 +0200 Received: from sem-dev01.sem-gmbh.com ([194.99.20.211]:31240 "EHLO sem-gmbh.com") by sem-two.sem-gmbh.com with ESMTP id ; Wed, 31 Jul 2002 10:41:51 +0200 Message-ID: <3D47A2A7.4030709@sem-gmbh.com> Date: Wed, 31 Jul 2002 10:41:11 +0200 From: Dirk Munzinger User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.0.0) Gecko/20020530 X-Accept-Language: de, de-at, en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync References: <3D46A2E4.8050106@sem-gmbh.com> <1028040131.2511.1.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, Eric Sandeen schrieb: > On Tue, 2002-07-30 at 09:29, Dirk Munzinger wrote: > > Hi Dirk - > > Take a look in your logs, I'm guessing that the filesystem shut down for > some reason. (disk error, memory corruption, etc.) Anything that > happens after that would result in the symptoms you're describing. If > there's anything interesting in the logs, please forward that to the > list. If have tested now with an reiserfs partition without any problems and now with an xfs partition and here is the error again (as described already). The only log I get in /var/log/message is Jul 31 10:32:01 two kernel: xfs_force_shutdown(ide1(22,68),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xd090e6a9 Jul 31 10:32:01 two kernel: Corruption of in-memory data detected. Shutting down filesystem: ide1(22,68) Jul 31 10:32:01 two kernel: Please umount the filesystem, and rectify the problem(s) Is it possible to provide more logs from xfs itselfe and if so how ? Regards, Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 31 02:02:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6V928Rw014879 for ; Wed, 31 Jul 2002 02:02:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6V9289D014878 for linux-xfs-outgoing; Wed, 31 Jul 2002 02:02:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6V920Rw014849 for ; Wed, 31 Jul 2002 02:02:01 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6V93ThC019016; Wed, 31 Jul 2002 11:03:29 +0200 (CEST) Message-Id: <4.3.2.7.2.20020731105914.0335e828@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jul 2002 11:01:56 +0200 To: Dirk Munzinger , Eric Sandeen From: Seth Mos Subject: Re: xfs-filesystem is broken after rsync Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D47A2A7.4030709@sem-gmbh.com> References: <3D46A2E4.8050106@sem-gmbh.com> <1028040131.2511.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:41 31-7-2002 +0200, Dirk Munzinger wrote: >Hi Eric, > >Eric Sandeen schrieb: >>On Tue, 2002-07-30 at 09:29, Dirk Munzinger wrote: >>Hi Dirk - >>Take a look in your logs, I'm guessing that the filesystem shut down for >>some reason. (disk error, memory corruption, etc.) Anything that >>happens after that would result in the symptoms you're describing. If >>there's anything interesting in the logs, please forward that to the >>list. > >If have tested now with an reiserfs partition without any problems and now >with an xfs partition and here is the error again (as described already). >The only log I get in /var/log/message is Can you give me a overview of the hardware this is running on? Can you also list what other patches are applied to this kernel beside the ipsec patches? >Is it possible to provide more logs from xfs itselfe and if so how ? You would need KDB to be compiled in for that. The developers can help you with how to use it. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 31 02:48:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6V9mYRw015537 for ; Wed, 31 Jul 2002 02:48:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6V9mY4p015536 for linux-xfs-outgoing; Wed, 31 Jul 2002 02:48:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6V9mSRw015507 for ; Wed, 31 Jul 2002 02:48:28 -0700 Received: from blade.4t2.com (blade.4t2.com [194.77.116.115]) 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 CAB01954 for ; Wed, 31 Jul 2002 02:50:33 -0700 (PDT) mail_from (Dirk.Munzinger@sem-gmbh.com) Received: from mx.sem-gmbh.com ([172.16.11.10]:11143 "EHLO ipsec.blade.4t2.com" ident: "NO-IDENT-SERVICE[2]" smtp-auth: TLS-PEER: ) by blade.4t2.com with ESMTP id ; Wed, 31 Jul 2002 11:31:21 +0200 Received: from sem-dev01.sem-gmbh.com ([194.99.20.211]:45576 "EHLO sem-gmbh.com") by sem-two.sem-gmbh.com with ESMTP id ; Wed, 31 Jul 2002 11:29:05 +0200 Message-ID: <3D47ADB9.20501@sem-gmbh.com> Date: Wed, 31 Jul 2002 11:28:25 +0200 From: Dirk Munzinger User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.0.0) Gecko/20020530 X-Accept-Language: de, de-at, en-us, en MIME-Version: 1.0 To: Seth Mos CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync References: <3D46A2E4.8050106@sem-gmbh.com> <1028040131.2511.1.camel@stout.americas.sgi.com> <4.3.2.7.2.20020731105914.0335e828@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Moin, Seth Mos schrieb: > > Can you give me a overview of the hardware this is running on? Can you > also list what other patches are applied to this kernel beside the ipsec > patches? The hardware is an AMD K6 2/450 with 256 MB and 3 IDE HDs from IBM (it's just a backup server for the online-backup) In the meantime I have recompiled the 2.4.18 kernel only with the ipsec and the xfs patches - no other patches anymore. I am now testing with ext3. Formating the fs with mkfs.ext3 -c showed no problems. Regards, Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 31 03:45:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VAjpRw016288 for ; Wed, 31 Jul 2002 03:45:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VAjpn9016287 for linux-xfs-outgoing; Wed, 31 Jul 2002 03:45:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VAjhRw016259 for ; Wed, 31 Jul 2002 03:45:43 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id CFF22C280; Wed, 31 Jul 2002 12:47:06 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id MAA02947; Wed, 31 Jul 2002 12:47:05 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3262957306; Wed, 31 Jul 2002 12:46:58 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id BEEAE25836; Wed, 31 Jul 2002 12:46:56 +0200 (CEST) Message-ID: <3D47C020.50BB8806@ch.sauter-bc.com> Date: Wed, 31 Jul 2002 12:46:56 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Dirk Munzinger Cc: Seth Mos , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync References: <3D46A2E4.8050106@sem-gmbh.com> <1028040131.2511.1.camel@stout.americas.sgi.com> <4.3.2.7.2.20020731105914.0335e828@pop.xs4all.nl> <3D47ADB9.20501@sem-gmbh.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dirk Munzinger schrieb: > > Moin, > > Seth Mos schrieb: > > > > Can you give me a overview of the hardware this is running on? Can you > > also list what other patches are applied to this kernel beside the ipsec > > patches? > > The hardware is an AMD K6 2/450 with 256 MB and 3 IDE HDs from IBM (it's > just a backup server for the online-backup) > In the meantime I have recompiled the 2.4.18 kernel only with the ipsec > and the xfs patches - no other patches anymore. I was having problems with rsync -av.. one year ago on an almost identical system like you have. The unbelievable solution was to remove the verbose options from rsync!! Look here: http://oss.sgi.com/projects/xfs/mail_archive/200108/msg00777.html I didn't have any problem since then and I'm nightly syncing some 300'000 files via rsync. You could give it a try. Simon > > I am now testing with ext3. Formating the fs with mkfs.ext3 -c showed no > problems. > > Regards, Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 31 04:15:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VBFARw017123 for ; Wed, 31 Jul 2002 04:15:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VBFA1D017122 for linux-xfs-outgoing; Wed, 31 Jul 2002 04:15:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blade.4t2.com (blade.4t2.com [194.77.116.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VBF4Rw017093 for ; Wed, 31 Jul 2002 04:15:05 -0700 Received: from mx.sem-gmbh.com ([172.16.11.10]:56202 "EHLO ipsec.blade.4t2.com" ident: "NO-IDENT-SERVICE[2]" smtp-auth: TLS-PEER: ) by blade.4t2.com with ESMTP id ; Wed, 31 Jul 2002 13:16:23 +0200 Received: from sem-dev01.sem-gmbh.com ([194.99.20.211]:41993 "EHLO sem-gmbh.com") by sem-two.sem-gmbh.com with ESMTP id ; Wed, 31 Jul 2002 13:06:35 +0200 Message-ID: <3D47C490.5050108@sem-gmbh.com> Date: Wed, 31 Jul 2002 13:05:52 +0200 From: Dirk Munzinger User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.0.0) Gecko/20020530 X-Accept-Language: de, de-at, en-us, en MIME-Version: 1.0 To: Simon Matter CC: Seth Mos , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync References: <3D46A2E4.8050106@sem-gmbh.com> <1028040131.2511.1.camel@stout.americas.sgi.com> <4.3.2.7.2.20020731105914.0335e828@pop.xs4all.nl> <3D47ADB9.20501@sem-gmbh.com> <3D47C020.50BB8806@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi ! Simon Matter schrieb: > I was having problems with rsync -av.. one year ago on an almost > identical system like you have. The unbelievable solution was to remove > the verbose options from rsync!! > > Look here: > http://oss.sgi.com/projects/xfs/mail_archive/200108/msg00777.html Looks like you had the same problem... I will give it a try later and let you know if this is the solution or not ! Many thanks, Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 31 04:22:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VBMKRw017384 for ; Wed, 31 Jul 2002 04:22:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VBMJlr017383 for linux-xfs-outgoing; Wed, 31 Jul 2002 04:22:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VBMCRw017353 for ; Wed, 31 Jul 2002 04:22:13 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6VBNdkL079781; Wed, 31 Jul 2002 13:23:40 +0200 (CEST) Message-Id: <4.3.2.7.2.20020731131947.02f5a7f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jul 2002 13:21:35 +0200 To: Dirk Munzinger From: Seth Mos Subject: Re: xfs-filesystem is broken after rsync Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3D47ADB9.20501@sem-gmbh.com> References: <3D46A2E4.8050106@sem-gmbh.com> <1028040131.2511.1.camel@stout.americas.sgi.com> <4.3.2.7.2.20020731105914.0335e828@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:28 31-7-2002 +0200, Dirk Munzinger wrote: >Moin, > >Seth Mos schrieb: > > > > Can you give me a overview of the hardware this is running on? Can you > > also list what other patches are applied to this kernel beside the ipsec > > patches? > >The hardware is an AMD K6 2/450 with 256 MB and 3 IDE HDs from IBM (it's >just a backup server for the online-backup) I do know about early K6 processors (i had one) that had problems with more then 32MB but that were only a few. The K6-2 should not have that problem. If it does there should be a kernel message during bootup. >In the meantime I have recompiled the 2.4.18 kernel only with the ipsec >and the xfs patches - no other patches anymore. Can you tell me what other patches there were in. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 31 04:40:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VBeeRw018074 for ; Wed, 31 Jul 2002 04:40:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VBeenJ018073 for linux-xfs-outgoing; Wed, 31 Jul 2002 04:40:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VBeVRw018045 for ; Wed, 31 Jul 2002 04:40:33 -0700 Received: (qmail 28554 invoked from network); 31 Jul 2002 11:42:00 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 31 Jul 2002 11:42:00 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 2580A3000B8; Wed, 31 Jul 2002 21:41:58 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 00F6394; Wed, 31 Jul 2002 21:41:57 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ravi Wijayaratne Cc: linux-xfs@oss.sgi.com Subject: Re: XFS stack overflow In-reply-to: Your message of "Tue, 30 Jul 2002 15:10:30 MST." <20020730221030.24542.qmail@web13107.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Jul 2002 21:41:52 +1000 Message-ID: <12351.1028115712@ocs3.intra.ocs.com.au> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 30 Jul 2002 15:10:30 -0700 (PDT), Ravi Wijayaratne wrote: >We are experiencing an XFS stack overflow. Not a >recurrent issue, but happens once in a while. > >Here is the oops message spewed out by our stack >depth checker. It calls BUG() as soon as it sees >some thing has overwritten the task_struct > >The oops was deliberately triggered. So please dont >worry about the oops. My worry is the call depth 114. >Here is the data about the system. The stack backtrace code in the kernel prints anything on stack that looks like a kernel address. In this case a lot of the entries are spurious, unfortunately it is not clear what the real stack trace is. Does this kernel have preempt turned on? At first glance it looks like XFS was interrupted by some TCP/IP code, that should not happen. Can you compile the kernel with frame pointers (CONFIG_FRAME_POINTER=y) and kdb (CONFIG_KDB=y) then drop into kdb when the stack overflows. The kdb backtrace (command 'bt') using frame pointers is far more accurate and will show what is really happening. From owner-linux-xfs@oss.sgi.com Wed Jul 31 05:29:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VCTtRw020678 for ; Wed, 31 Jul 2002 05:29:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VCTteO020677 for linux-xfs-outgoing; Wed, 31 Jul 2002 05:29:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blade.4t2.com (blade.4t2.com [194.77.116.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VCTnRw020648 for ; Wed, 31 Jul 2002 05:29:50 -0700 Received: from mx.sem-gmbh.com ([172.16.11.10]:29838 "EHLO ipsec.blade.4t2.com" ident: "NO-IDENT-SERVICE[2]" smtp-auth: TLS-PEER: ) by blade.4t2.com with ESMTP id ; Wed, 31 Jul 2002 14:31:14 +0200 Received: from sem-dev01.sem-gmbh.com ([194.99.20.211]:35594 "EHLO sem-gmbh.com") by sem-two.sem-gmbh.com with ESMTP id ; Wed, 31 Jul 2002 14:28:33 +0200 Message-ID: <3D47D7C4.3090601@sem-gmbh.com> Date: Wed, 31 Jul 2002 14:27:48 +0200 From: Dirk Munzinger User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.0.0) Gecko/20020530 X-Accept-Language: de, de-at, en-us, en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync References: <3D46A2E4.8050106@sem-gmbh.com> <1028040131.2511.1.camel@stout.americas.sgi.com> <4.3.2.7.2.20020731105914.0335e828@pop.xs4all.nl> <3D47ADB9.20501@sem-gmbh.com> <3D47C020.50BB8806@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Moin, Simon Matter schrieb: > I was having problems with rsync -av.. one year ago on an almost > identical system like you have. The unbelievable solution was to remove > the verbose options from rsync!! I have just tested it but the xfs still crashs... - Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 31 06:10:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VDAiRw028589 for ; Wed, 31 Jul 2002 06:10:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VDAial028588 for linux-xfs-outgoing; Wed, 31 Jul 2002 06:10:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VDAQRw028552 for ; Wed, 31 Jul 2002 06:10:26 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id 47777C2B4; Wed, 31 Jul 2002 14:49:08 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA13189; Wed, 31 Jul 2002 14:49:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 81FEA57306; Wed, 31 Jul 2002 14:49:01 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id EE74225836; Wed, 31 Jul 2002 14:49:00 +0200 (CEST) Message-ID: <3D47DCBC.771B9BF4@ch.sauter-bc.com> Date: Wed, 31 Jul 2002 14:49:00 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Dirk Munzinger Cc: Seth Mos , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync References: <3D46A2E4.8050106@sem-gmbh.com> <1028040131.2511.1.camel@stout.americas.sgi.com> <4.3.2.7.2.20020731105914.0335e828@pop.xs4all.nl> <3D47ADB9.20501@sem-gmbh.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dirk Munzinger schrieb: > > Moin, > > Seth Mos schrieb: > > > > Can you give me a overview of the hardware this is running on? Can you > > also list what other patches are applied to this kernel beside the ipsec > > patches? > > The hardware is an AMD K6 2/450 with 256 MB and 3 IDE HDs from IBM (it's > just a backup server for the online-backup) > In the meantime I have recompiled the 2.4.18 kernel only with the ipsec > and the xfs patches - no other patches anymore. > > I am now testing with ext3. Formating the fs with mkfs.ext3 -c showed no > problems. Thats only read test, did you try, when formatted XFS, to fill the partition so any write error on the disks can show up? Also, did you check your memory? Since XFS sometimes consumes much more memory than with other filesystems, memory errors can show up, memtest86 is your friend. Simon > > Regards, Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 31 06:48:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VDmRRw002743 for ; Wed, 31 Jul 2002 06:48:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VDmRpf002742 for linux-xfs-outgoing; Wed, 31 Jul 2002 06:48:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VDmJRw002711 for ; Wed, 31 Jul 2002 06:48:19 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA60108; Wed, 31 Jul 2002 08:49:45 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA49829; Wed, 31 Jul 2002 08:49:44 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6VDgZ219590; Wed, 31 Jul 2002 08:42:35 -0500 Subject: Re: XFS stack overflow From: Steve Lord To: Ravi Wijayaratne Cc: linux-xfs@oss.sgi.com In-Reply-To: <12351.1028115712@ocs3.intra.ocs.com.au> References: <12351.1028115712@ocs3.intra.ocs.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 31 Jul 2002 08:42:35 -0500 Message-Id: <1028122955.19566.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-31 at 06:41, Keith Owens wrote: > On Tue, 30 Jul 2002 15:10:30 -0700 (PDT), > Ravi Wijayaratne wrote: > >We are experiencing an XFS stack overflow. Not a > >recurrent issue, but happens once in a while. > > > >Here is the oops message spewed out by our stack > >depth checker. It calls BUG() as soon as it sees > >some thing has overwritten the task_struct > > > >The oops was deliberately triggered. So please dont > >worry about the oops. My worry is the call depth 114. > >Here is the data about the system. > > The stack backtrace code in the kernel prints anything on stack that > looks like a kernel address. In this case a lot of the entries are > spurious, unfortunately it is not clear what the real stack trace is. > Does this kernel have preempt turned on? At first glance it looks like > XFS was interrupted by some TCP/IP code, that should not happen. > > Can you compile the kernel with frame pointers (CONFIG_FRAME_POINTER=y) > and kdb (CONFIG_KDB=y) then drop into kdb when the stack overflows. > The kdb backtrace (command 'bt') using frame pointers is far more > accurate and will show what is really happening. You probably need to use kgcc to do this, kdb has some issues with some more recent compilers and tends to skip large chunks of stack frames. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jul 31 07:16:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VEGHRw003217 for ; Wed, 31 Jul 2002 07:16:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VEGH41003216 for linux-xfs-outgoing; Wed, 31 Jul 2002 07:16:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VEGARw003184 for ; Wed, 31 Jul 2002 07:16:11 -0700 Received: (qmail 5640 invoked from network); 31 Jul 2002 14:17:39 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 31 Jul 2002 14:17:39 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 907A63000B8; Thu, 1 Aug 2002 00:17:37 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 4C90694; Thu, 1 Aug 2002 00:17:37 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ravi Wijayaratne Cc: linux-xfs@oss.sgi.com Subject: Re: XFS stack overflow In-reply-to: Your message of "31 Jul 2002 08:42:35 EST." <1028122955.19566.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Aug 2002 00:17:31 +1000 Message-ID: <13492.1028125051@ocs3.intra.ocs.com.au> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 31 Jul 2002 08:42:35 -0500, Steve Lord wrote: >You probably need to use kgcc to do this, kdb has some issues with some >more recent compilers and tends to skip large chunks of stack frames. Even when compiled with frame pointers? kdb should handle stack frames when the frame pointer is available. Yes I know Steve, I have to upgrade kdb to handle the i386 code generated by more recent compilers. But ia64 bug fixes come first. From owner-linux-xfs@oss.sgi.com Wed Jul 31 07:23:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VENiRw003504 for ; Wed, 31 Jul 2002 07:23:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VENi1r003503 for linux-xfs-outgoing; Wed, 31 Jul 2002 07:23:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VENbRw003474 for ; Wed, 31 Jul 2002 07:23:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA47065; Wed, 31 Jul 2002 09:24:59 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA39220; Wed, 31 Jul 2002 09:24:59 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6VEHo919749; Wed, 31 Jul 2002 09:17:50 -0500 Subject: Re: XFS stack overflow From: Steve Lord To: Keith Owens Cc: Ravi Wijayaratne , linux-xfs@oss.sgi.com In-Reply-To: <13492.1028125051@ocs3.intra.ocs.com.au> References: <13492.1028125051@ocs3.intra.ocs.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 31 Jul 2002 09:17:50 -0500 Message-Id: <1028125070.19736.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-31 at 09:17, Keith Owens wrote: > On 31 Jul 2002 08:42:35 -0500, > Steve Lord wrote: > >You probably need to use kgcc to do this, kdb has some issues with some > >more recent compilers and tends to skip large chunks of stack frames. > > Even when compiled with frame pointers? kdb should handle stack frames > when the frame pointer is available. > > Yes I know Steve, I have to upgrade kdb to handle the i386 code > generated by more recent compilers. But ia64 bug fixes come first. Sorry Keith, I was not prodding you, just making sure we got useful information, frame pointers do not seem to help when going through a function vector. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jul 31 07:51:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VEpbRw003981 for ; Wed, 31 Jul 2002 07:51:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VEpbjt003980 for linux-xfs-outgoing; Wed, 31 Jul 2002 07:51:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VEpWRw003948 for ; Wed, 31 Jul 2002 07:51:33 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 9BD3C14BFD; Wed, 31 Jul 2002 16:51:08 +0200 (MEST) Date: Wed, 31 Jul 2002 16:41:42 +0200 From: Andi Kleen To: Steve Lord Cc: Keith Owens , Ravi Wijayaratne , linux-xfs@oss.sgi.com Subject: Re: XFS stack overflow Message-ID: <20020731164142.A16177@wotan.suse.de> References: <13492.1028125051@ocs3.intra.ocs.com.au> <1028125070.19736.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1028125070.19736.1.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Sorry Keith, I was not prodding you, just making sure we got useful > information, frame pointers do not seem to help when going through a > function vector. That would sound more like a kdb unwinder bug. Perhaps the newer gcc is generating some call sequence that kdb is not expecting. -Andi From owner-linux-xfs@oss.sgi.com Wed Jul 31 09:26:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VGQPRw006347 for ; Wed, 31 Jul 2002 09:26:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VGQPSW006346 for linux-xfs-outgoing; Wed, 31 Jul 2002 09:26:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from MSUMAIL2.Campus.mnsu.edu (msuex2.campus.mnsu.edu [134.29.52.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VGQFRw006318 for ; Wed, 31 Jul 2002 09:26:15 -0700 content-class: urn:content-classes:message Subject: RE: xfs-filesystem is broken after rsync MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Date: Wed, 31 Jul 2002 11:27:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xfs-filesystem is broken after rsync Thread-Index: AcI4rah5Yvr/XD1WQtONSr72enaCigAAO3lV From: "Hundstad, Jeffrey E." To: "Seth Mos" , "Dirk Munzinger" Cc: "Eric Sandeen" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6VGQGRw006319 X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Linux-2.4.19-rc3 has code to eliminate the AMD K6 cache speculation bug. Gettting the current CVS of XFS might be worth trying 'cause it's based on the 2.4.19-rc3 codebase. If I remember correctly it has KDB also. BTW: When you have a filesystem that appears to work (ie Reiser or EXT3) can you try to compile the Linux Kernel using 'make -j'. I suspect that you have some memory error or cache problems. GCC should complain with SEG11 if there's a memory problem. I had a machine that worked with BSD, Windows etc.etc. but as soon as GCC did a make it would seg fault. Changing my main ram solved my problems. BTW^2: memtest86 ran for DAYS on this ram w/o errors. A comercial ram tester also said it was fine. -- jeffrey hundstad -----Original Message----- From: Seth Mos [mailto:knuffie@xs4all.nl] Sent: Wed 7/31/2002 6:21 AM To: Dirk Munzinger Cc: Eric Sandeen; linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync At 11:28 31-7-2002 +0200, Dirk Munzinger wrote: >Moin, > >Seth Mos schrieb: > > > > Can you give me a overview of the hardware this is running on? Can you > > also list what other patches are applied to this kernel beside the ipsec > > patches? > >The hardware is an AMD K6 2/450 with 256 MB and 3 IDE HDs from IBM (it's >just a backup server for the online-backup) I do know about early K6 processors (i had one) that had problems with more then 32MB but that were only a few. The K6-2 should not have that problem. If it does there should be a kernel message during bootup. >In the meantime I have recompiled the 2.4.18 kernel only with the ipsec >and the xfs patches - no other patches anymore. Can you tell me what other patches there were in. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 31 09:37:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VGbBRw006588 for ; Wed, 31 Jul 2002 09:37:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VGbBTf006587 for linux-xfs-outgoing; Wed, 31 Jul 2002 09:37:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from server.s8.com (server.s8.com [66.77.12.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VGb7Rw006547 for ; Wed, 31 Jul 2002 09:37:07 -0700 Received: from plokta.s8.com ([10.0.0.144]) by server.s8.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3TVGMW9N; Wed, 31 Jul 2002 09:34:48 -0700 Received: by plokta.s8.com (Postfix, from userid 20011) id 57D57C0042; Wed, 31 Jul 2002 09:38:33 -0700 (PDT) Subject: RE: xfs-filesystem is broken after rsync From: "Bryan O'Sullivan" To: "Hundstad, Jeffrey E." Cc: Seth Mos , Dirk Munzinger , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 31 Jul 2002 09:38:33 -0700 Message-Id: <1028133513.15836.28.camel@plokta.s8.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-31 at 09:27, Hundstad, Jeffrey E. wrote: > Linux-2.4.19-rc3 has code to eliminate the AMD K6 cache speculation bug. The cache speculation bug is in recent steppings of the K7 (Athlon XP and MP), not the K6. It's also specific to AGP. ; Wed, 31 Jul 2002 11:44:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VIiDB3009262 for linux-xfs-outgoing; Wed, 31 Jul 2002 11:44:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VIi6Rw009234 for ; Wed, 31 Jul 2002 11:44:07 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA68448 for ; Wed, 31 Jul 2002 13:45:33 -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 NAA41089 for ; Wed, 31 Jul 2002 13:45:33 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6VIg8f24384; Wed, 31 Jul 2002 13:42:08 -0500 Message-Id: <200207311842.g6VIg8f24384@stout.americas.sgi.com> Date: Wed, 31 Jul 2002 13:42:08 -0500 Subject: TAKE - Fix build X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk arch.h is gone, but fs/xfs/support/uuid.c was #including it. Date: Wed Jul 31 11:45:12 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:124064a linux/fs/xfs/support/uuid.c - 1.8 - arch.h is gone, don't #include it here From owner-linux-xfs@oss.sgi.com Wed Jul 31 11:47:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VIlLRw009457 for ; Wed, 31 Jul 2002 11:47:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VIlLrF009456 for linux-xfs-outgoing; Wed, 31 Jul 2002 11:47:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VIlFRw009424 for ; Wed, 31 Jul 2002 11:47:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA67230 for ; Wed, 31 Jul 2002 13:48: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 NAA93269 for ; Wed, 31 Jul 2002 13:48:42 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6VIjIO24458; Wed, 31 Jul 2002 13:45:18 -0500 Message-Id: <200207311845.g6VIjIO24458@stout.americas.sgi.com> Date: Wed, 31 Jul 2002 13:45:18 -0500 Subject: TAKE - Add some versioning to XFS X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Add a version string to the module description and the init string. Right now it just says "CVS" - I'll get something set up to add a date to it on a regular basis for CVS. It used to be that kernel versions were fine enough timestamps - not anymore, for 2.4 at least. :) Date: Wed Jul 31 11:47:05 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:124066a linux/fs/xfs/linux/xfs_version.h - 1.1 linux/fs/xfs/linux/xfs_super.c - 1.203 From owner-linux-xfs@oss.sgi.com Wed Jul 31 11:59:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VIxvRw009891 for ; Wed, 31 Jul 2002 11:59:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VIxviI009890 for linux-xfs-outgoing; Wed, 31 Jul 2002 11:59:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VIxpRw009856 for ; Wed, 31 Jul 2002 11:59:51 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 0D6141436E; Wed, 31 Jul 2002 21:01:18 +0200 (MEST) Date: Wed, 31 Jul 2002 21:01:10 +0200 From: Andi Kleen To: "Hundstad, Jeffrey E." Cc: Seth Mos , Dirk Munzinger , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync Message-ID: <20020731210110.A17421@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jul 31, 2002 at 11:27:34AM -0500, Hundstad, Jeffrey E. wrote: > Linux-2.4.19-rc3 has code to eliminate the AMD K6 cache speculation bug. Gettting the current CVS of XFS might be worth trying 'cause it's based on the 2.4.19-rc3 codebase. If I remember correctly it has KDB also. Please check your facts. There is no "K6 cache speculation bug". There is a problem with Athlon XP+ prefetching that is triggered by linux doing something illegal to the x86 spec (creating mappings with conflicting cache types). Still it can only hit when you're using AGP extensively usually only with some 3d graphic drivers. XFS definitely does not use AGP. -Andi From owner-linux-xfs@oss.sgi.com Wed Jul 31 12:27:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VJRKRw011087 for ; Wed, 31 Jul 2002 12:27:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VJRKdV011086 for linux-xfs-outgoing; Wed, 31 Jul 2002 12:27:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VJRDRw011054 for ; Wed, 31 Jul 2002 12:27:14 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 628D114B75; Wed, 31 Jul 2002 21:28:40 +0200 (MEST) Date: Wed, 31 Jul 2002 21:28:38 +0200 From: Andi Kleen To: "Hundstad, Jeffrey E." Cc: Andi Kleen , Seth Mos , Dirk Munzinger , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: xfs-filesystem is broken after rsync Message-ID: <20020731212838.A23587@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jul 31, 2002 at 02:21:22PM -0500, Hundstad, Jeffrey E. wrote: > As requested I checked my facts. I'm not sure from the comments (included below) which AMD processor(s) have the problems. Sometimes they talk about newer AMD Athlon and sometimes its B step AMD K6 before B 9730xxxx. I also know that the XFS code doesn't use the AGP bus but a generic memory corruption in the cache caused by AGP use could corrupt kernel space used by XFS. True? Not in this case. You can only get memory corruption on pages mapped into the AGP aperture. While XFS can get later a page that was previously mapped into the aperture it would not care about its previous (corrupted or not) contents. Also note the corruption is extremly rare and you are unlikly to trigger it unless you beat the system heavily for many hours/days. > /* > * B step AMD K6 before B 9730xxxx have hardware bugs that can cause > * misexecution of code under Linux. Owners of such processors should > * contact AMD for precise details and a CPU swap. This refers to a different bug. -Andi From owner-linux-xfs@oss.sgi.com Wed Jul 31 13:34:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VKYnRw012408 for ; Wed, 31 Jul 2002 13:34:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VKYmM1012407 for linux-xfs-outgoing; Wed, 31 Jul 2002 13:34:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VKYhRw012379 for ; Wed, 31 Jul 2002 13:34:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA70770 for ; Wed, 31 Jul 2002 15:36:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA43017 for ; Wed, 31 Jul 2002 15:36:10 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g6VKSwS01630; Wed, 31 Jul 2002 15:28:58 -0500 Message-Id: <200207312028.g6VKSwS01630@jen.americas.sgi.com> Date: Wed, 31 Jul 2002 15:28:58 -0500 Subject: TAKE - fix a log recovery bug To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You could not hit this unless you used some very odd mkfs parameters. Date: Wed Jul 31 13:35:09 PDT 2002 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:124083a linux/fs/xfs/xfs_buf_item.h - 1.36 - remove some dead prototypes linux/fs/xfs/xfs_buf_item.c - 1.126 - fix a recovery bug in fragmented buffers - linux specific From owner-linux-xfs@oss.sgi.com Wed Jul 31 14:31:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VLVuRw013117 for ; Wed, 31 Jul 2002 14:31:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VLVumA013116 for linux-xfs-outgoing; Wed, 31 Jul 2002 14:31:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VLVoRw013082 for ; Wed, 31 Jul 2002 14:31:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA69622 for ; Wed, 31 Jul 2002 16:33:18 -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 QAA83033 for ; Wed, 31 Jul 2002 16:33:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6VLTqO25637; Wed, 31 Jul 2002 16:29:52 -0500 Message-Id: <200207312129.g6VLTqO25637@stout.americas.sgi.com> Date: Wed, 31 Jul 2002 16:29:52 -0500 Subject: TAKE - Fix xfstest 009 for block size < page size X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This test was assuming that block size == page size... Date: Wed Jul 31 14:32:56 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:124092a cmd/xfstests/009 - 1.8 - Make this test work for fs block size < page size From owner-linux-xfs@oss.sgi.com Wed Jul 31 15:08:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VM8lRw014281 for ; Wed, 31 Jul 2002 15:08:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VM8lPr014280 for linux-xfs-outgoing; Wed, 31 Jul 2002 15:08:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VM8fRw014251 for ; Wed, 31 Jul 2002 15:08:41 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA66234 for ; Wed, 31 Jul 2002 17:10:08 -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 RAA73046 for ; Wed, 31 Jul 2002 17:10:08 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g6VM6gK27272; Wed, 31 Jul 2002 17:06:42 -0500 Message-Id: <200207312206.g6VM6gK27272@stout.americas.sgi.com> Date: Wed, 31 Jul 2002 17:06:42 -0500 Subject: TAKE - get rid of EOPNOTSUPP X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk from Christoph: "only used in two places in dmapi and two linux-specific headers." get rid of EOPNOTSUPP Date: Wed Jul 31 15:09:41 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:124099a linux/fs/xfs/linux/xfs_linux.h - 1.82 linux/fs/xfs/dmapi/dmapi_right.c - 1.11 linux/fs/xfs/xfs_acl.h - 1.20 linux/fs/xfs/xfs_cap.h - 1.6 From owner-linux-xfs@oss.sgi.com Wed Jul 31 15:23:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6VMNORw014531 for ; Wed, 31 Jul 2002 15:23:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6VMNOFv014530 for linux-xfs-outgoing; Wed, 31 Jul 2002 15:23:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from server.home.at (root@chello212186127068.14.vie.surfer.at [212.186.127.68]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6VMNFRw014502 for ; Wed, 31 Jul 2002 15:23:16 -0700 Received: from localhost.localdomain (sector17.home.at [192.168.1.1]) by server.home.at (8.12.1/8.12.1/Debian -5) with ESMTP id g6VMNvgP008725 for ; Thu, 1 Aug 2002 00:23:58 +0200 Subject: recovery failed after power off From: Christian Thalinger To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 01 Aug 2002 00:23:14 +0200 Message-Id: <1028154195.816.10.camel@sector17.home.at> Mime-Version: 1.0 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm just evaluating the best fs for my purposes and tried xfs under power failure conditions. Booted into linux with xfs as root partition and copied a linux kernel source tree into another directory on the same partition. While it was copying i just switched off the power and tried to get it up again. This is what i did get: Jul 31 23:33:30 (none) kernel: XFS mounting filesystem ide2(33,4) Jul 31 23:33:30 (none) kernel: Starting XFS recovery on filesystem: ide2(33,4) (dev: 33/4) Jul 31 23:33:31 (none) kernel: cmn_err level 1 Filesystem "ide2(33,4)": xfs_inode_recover: Bad inode magic number, dino ptr = 0xddc01100, dino bp = 0xddc33c80, ino = 25766753 Jul 31 23:33:31 (none) kernel: XFS: log mount/recovery failed Jul 31 23:33:31 (none) kernel: XFS: log mount failed I could only mount this partition again after doing `xfs_repair -L'. Is there a way to have a xfs root partition and to get the machine up again, in most cases, without user interaction? Regards. TWISTI From owner-linux-xfs@oss.sgi.com Wed Jul 31 18:58:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g711wRRw017453 for ; Wed, 31 Jul 2002 18:58:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g711wRLM017452 for linux-xfs-outgoing; Wed, 31 Jul 2002 18:58:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g711wJRw017421 for ; Wed, 31 Jul 2002 18:58:19 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA33465; Wed, 31 Jul 2002 20:59:47 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-15.corp.sgi.com [134.15.64.15]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id UAA33279; Wed, 31 Jul 2002 20:59:46 -0500 (CDT) Subject: Re: recovery failed after power off From: Stephen Lord To: Christian Thalinger Cc: linux-xfs@oss.sgi.com In-Reply-To: <1028154195.816.10.camel@sector17.home.at> References: <1028154195.816.10.camel@sector17.home.at> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 31 Jul 2002 20:57:26 -0500 Message-Id: <1028167048.1122.7.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-07-31 at 17:23, Christian Thalinger wrote: > I'm just evaluating the best fs for my purposes and tried xfs under > power failure conditions. Booted into linux with xfs as root partition > and copied a linux kernel source tree into another directory on the same > partition. While it was copying i just switched off the power and tried > to get it up again. This is what i did get: > > Jul 31 23:33:30 (none) kernel: XFS mounting filesystem ide2(33,4) > Jul 31 23:33:30 (none) kernel: Starting XFS recovery on filesystem: > ide2(33,4) (dev: 33/4) > Jul 31 23:33:31 (none) kernel: cmn_err level 1 Filesystem "ide2(33,4)": > xfs_inode_recover: Bad inode magic number, dino ptr = 0xddc01100, dino > bp = 0xddc33c80, ino = 25766753 > Jul 31 23:33:31 (none) kernel: XFS: log mount/recovery failed > Jul 31 23:33:31 (none) kernel: XFS: log mount failed > > I could only mount this partition again after doing `xfs_repair -L'. > > Is there a way to have a xfs root partition and to get the machine up > again, in most cases, without user interaction? > > Regards. > > TWISTI > So are you running IDE with write caching turned on? Any journaled filesystem is going to have issues with a write cache enabled drive if you drop the power on it. In order to work a journaled file system has ordering constraints between log writes and metadata writes. A drive write cache can cause these constraints to be broken - a metadata write was probably still in cache and the relevant log space was overwritten on disk. Steve From owner-linux-xfs@oss.sgi.com Wed Jul 31 22:49:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g715nbRw019770 for ; Wed, 31 Jul 2002 22:49:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g715nbB8019769 for linux-xfs-outgoing; Wed, 31 Jul 2002 22:49:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g715nQRw019737 for ; Wed, 31 Jul 2002 22:49:26 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.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 WAA06666 for ; Wed, 31 Jul 2002 22:50:57 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g715nopx16825646 for ; Wed, 31 Jul 2002 22:49:51 -0700 (PDT) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g715me920590; Thu, 1 Aug 2002 15:48:40 +1000 Date: Thu, 1 Aug 2002 15:48:40 +1000 From: Keith Owens Message-Id: <200208010548.g715me920590@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to 2.4.19-rc4 X-Spam-Status: No, hits=2.2 required=5.0 tests=MAY_BE_FORGED,MISSING_HEADERS version=2.20 X-Spam-Level: ** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade to 2.4.19-rc4 Date: Wed Jul 31 22:46:10 PDT 2002 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:124110a linux/net/ipv4/route.c - 1.34 linux/include/linux/module.h - 1.32 linux/include/asm-i386/processor.h - 1.33 linux/include/asm-i386/bugs.h - 1.15 linux/fs/proc/generic.c - 1.24 linux/fs/namei.c - 1.45 linux/fs/coda/file.c - 1.20 linux/drivers/video/fbcon.c - 1.25 linux/drivers/sbus/char/openprom.c - 1.12 linux/drivers/net/ewrk3.c - 1.21 linux/drivers/net/Config.in - 1.58 linux/drivers/char/Config.in - 1.57 linux/arch/i386/kernel/vm86.c - 1.12 linux/arch/i386/kernel/ptrace.c - 1.19 linux/arch/alpha/kernel/osf_sys.c - 1.29 linux/Makefile - 1.176 linux/drivers/usb/printer.c - 1.42 linux/drivers/usb/devices.c - 1.16 linux/drivers/ieee1394/raw1394.c - 1.16 linux/drivers/ieee1394/pcilynx.c - 1.19 linux/drivers/ieee1394/ieee1394_core.c - 1.20 linux/drivers/ieee1394/ohci1394.c - 1.22 linux/drivers/ieee1394/hosts.c - 1.13 linux/drivers/ieee1394/csr.c - 1.8 linux/drivers/ieee1394/Makefile - 1.11 linux/drivers/usb/rio500.c - 1.15 linux/drivers/ide/sis5513.c - 1.14 linux/drivers/ide/ide-pci.c - 1.23 linux/drivers/s390/block/dasd.c - 1.20 linux/include/asm-i386/i387.h - 1.5 linux/arch/i386/kernel/i387.c - 1.7 linux/drivers/ieee1394/video1394.c - 1.17 linux/drivers/net/natsemi.c - 1.22 linux/drivers/media/video/stradis.c - 1.9 linux/drivers/usb/catc.c - 1.5 linux/drivers/ieee1394/sbp2.c - 1.10 linux/drivers/ieee1394/sbp2.h - 1.8 linux/drivers/ieee1394/nodemgr.c - 1.11 linux/drivers/usb/usbvideo.c - 1.4 linux/fs/intermezzo/kml.c - 1.3 linux/fs/intermezzo/psdev.c - 1.6 linux/fs/intermezzo/super.c - 1.3 linux/fs/intermezzo/vfs.c - 1.6 linux/drivers/ieee1394/amdtp.c - 1.3 linux/drivers/ieee1394/amdtp.h - 1.2 linux/drivers/ieee1394/cmp.c - 1.2 linux/drivers/ieee1394/dv1394-private.h - 1.3 linux/drivers/ieee1394/dv1394.c - 1.3 linux/drivers/ieee1394/eth1394.c - 1.2