From owner-linux-xfs@oss.sgi.com Fri Sep 1 00:11:15 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 00:11:06 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26224 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 1 Sep 2000 00:10:42 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA03747 for ; Fri, 1 Sep 2000 00:17:07 -0700 (PDT) mail_from (tes@sherman.melbourne.sgi.com) Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id SAA28462 for linux-xfs@oss.sgi.com; Fri, 1 Sep 2000 18:10:35 +1100 Date: Fri, 1 Sep 2000 18:10:35 +1100 From: Tim Shimmin Message-Id: <200009010710.SAA28462@sherman.melbourne.sgi.com> Subject: TAKE - stress/xfsdump To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Aug 28 00:40:24 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73138a cmd/xfs/stress/common.rc - 1.20 - Add comment about tape device for xfsdump. cmd/xfs/stress/common.dump - 1.10 - Test for being able to status the tape device. If we cannot then we fake it and say so in the full file. Date: Fri Sep 1 00:09:06 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73486a cmd/xfs/stress/group - 1.31 - Make xfsdump tests part of the auto group. If no tape device can be mt stat'ed then the output will be faked. cmd/xfs/dump/invutil/invutil.c - 1.6 - Get rid of use of getdate(3) and replace by use of strptime(3). Also add hack to handle daylight savings time. This was discovered by stress/028 failing when we moved into daylight savings. cmd/xfs/man/man8/xfsinvutil.8 - 1.3 - Get rid of references to getdate(3) and DATEMSK. cmd/xfs/stress/common.dump - 1.11 - Added stuff to only do the tape check if required to do so. cmd/xfs/stress/026 - 1.2 cmd/xfs/stress/027 - 1.2 - Ensure that no check is made for TAPE_DEV as it does not need it. cmd/xfs/stress/028 - 1.2 - Change the test to do file dumps instead of tape dumps as an inventory will be created in both cases AND this way the test will be a lot faster and won't need a tape device to check if the xfsinvutil is working. cmd/xfs/stress/028.out - 1.2 - Output changed for dumping to file instead of tape. From owner-linux-xfs@oss.sgi.com Fri Sep 1 05:20:28 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 05:20:09 -0700 Received: from Cantor.suse.de ([194.112.123.193]:51210 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Fri, 1 Sep 2000 05:19:40 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 06DEB1E56C; Fri, 1 Sep 2000 14:19:38 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 7511710A081; Fri, 1 Sep 2000 14:19:37 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id E2FC32F300; Fri, 1 Sep 2000 14:19:36 +0200 (MEST) Date: Fri, 1 Sep 2000 14:19:36 +0200 From: "Andi Kleen" To: "Davida, Joe" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation Message-ID: <20000901141936.A10785@gruyere.muc.suse.de> References: <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com>; from Joe_Davida@Maxtor.com on Thu, Aug 31, 2000 at 03:44:34PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, Aug 31, 2000 at 03:44:34PM -0600, Davida, Joe wrote: > Is there any information on the 2 TBytes file system > limitation in Linux which is also inherited by the > linux port of xfs? What imposes this limitation? > Are the current efforts aimed at removing this > limitation? I hear ReiserFS has a 16 Terabyte > file system size. The 2TB limitation is caused by the interface between block drivers and file systems. On 32bit machines a 32bit value is used to pass the sector number, with the sector being in 512byte units. Limiting yourself to 31bits is probably safer to protect against signedness bugs in the driver. That gives you a 2^31 * 2^9 = 2^40bits block device size limit for all file systems and raw devices. On 64bit systems the limit is higher, assuming there are no 32bit limitations in the driver. -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 1 07:21:18 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 07:21:09 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:63500 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Fri, 1 Sep 2000 07:20:52 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e81EK5a55455; Fri, 1 Sep 2000 09:20:05 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39AFBB10.48C59783@thebarn.com> Date: Fri, 01 Sep 2000 09:20:01 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Davida, Joe" CC: "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation References: <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com> <20000901141936.A10785@gruyere.muc.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Andi Kleen wrote: > On Thu, Aug 31, 2000 at 03:44:34PM -0600, Davida, Joe wrote: > > Is there any information on the 2 TBytes file system > > limitation in Linux which is also inherited by the > > linux port of xfs? What imposes this limitation? > > Are the current efforts aimed at removing this > > limitation? I hear ReiserFS has a 16 Terabyte > > file system size. > > The 2TB limitation is caused by the interface between block drivers > and file systems. On 32bit machines a 32bit value is used to pass the > sector number, with the sector being in 512byte units. Limiting yourself > to 31bits is probably safer to protect against signedness bugs in the > driver. > > That gives you a 2^31 * 2^9 = 2^40bits block device size limit for all > file systems and raw devices. > > On 64bit systems the limit is higher, assuming there are no 32bit limitations > in the driver. > Also note the 16TB limit is true for all linux file systems at the moment. The block interface on linux indexes on the block size of the file system, in almost all cases it's the PAGE_SIZE aka 4k. 2^32 * 4096 / TB's = 16TB XFS has additional problems with inode numbers overflowing the standard 32bit container once the file system its self goes over 2TB. Fixing this either requires changing linux to support 64bit inode numbers not terribly difficult but time consuming in that the linux community has to all agree as to what needs to be done, or change the way XFS deals with inode numbers. This does require some fundamental changes in XFS... up until this point we have made very few fundamental changes to XFS internals. Which as worked out very well since we know the code base is solid. It is unclear as the best path at this point. It is one of the things to fix in one of the near future releases. For the moment we are concentrating on getting our first Beta finalized. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Fri Sep 1 07:36:38 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 07:36:28 -0700 Received: from Cantor.suse.de ([194.112.123.193]:29700 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Fri, 1 Sep 2000 07:36:03 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id BB2B51E6D4; Fri, 1 Sep 2000 16:36:01 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 6E6E010A117; Fri, 1 Sep 2000 16:35:58 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 3AAAE2F300; Fri, 1 Sep 2000 16:35:56 +0200 (MEST) Date: Fri, 1 Sep 2000 16:35:56 +0200 From: "Andi Kleen" To: Russell Cattelan Cc: "Davida, Joe" , "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation Message-ID: <20000901163556.A14222@gruyere.muc.suse.de> References: <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com> <20000901141936.A10785@gruyere.muc.suse.de> <39AFBB10.48C59783@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <39AFBB10.48C59783@thebarn.com>; from cattelan@thebarn.com on Fri, Sep 01, 2000 at 09:20:01AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, Sep 01, 2000 at 09:20:01AM -0500, Russell Cattelan wrote: > Andi Kleen wrote: > > > On Thu, Aug 31, 2000 at 03:44:34PM -0600, Davida, Joe wrote: > > > Is there any information on the 2 TBytes file system > > > limitation in Linux which is also inherited by the > > > linux port of xfs? What imposes this limitation? > > > Are the current efforts aimed at removing this > > > limitation? I hear ReiserFS has a 16 Terabyte > > > file system size. > > > > The 2TB limitation is caused by the interface between block drivers > > and file systems. On 32bit machines a 32bit value is used to pass the > > sector number, with the sector being in 512byte units. Limiting yourself > > to 31bits is probably safer to protect against signedness bugs in the > > driver. > > > > That gives you a 2^31 * 2^9 = 2^40bits block device size limit for all > > file systems and raw devices. > > > > On 64bit systems the limit is higher, assuming there are no 32bit limitations > > in the driver. > > > > Also note the 16TB limit is true for all linux file systems at the moment. > The block interface on linux indexes on the block size of the file system, in > almost all cases it's the PAGE_SIZE aka 4k. > 2^32 * 4096 / TB's = 16TB Internally in ll_rw_block() it always scales down to 512 byte blocks, and that is what the interface to the drivers uses. So it is always 2TB. > > Fixing this either requires changing linux to support 64bit inode numbers > not terribly difficult but time consuming in that the linux community > has to all agree as to what needs to be done, or change the way XFS > deals with inode numbers. This does require some fundamental changes > in XFS... up until this point we have made very few fundamental changes > to XFS internals. Which as worked out very well since we know the code > base is solid. Linux needs to do it generally for the NFSv3 client anyways, so it may make more sense to change Linux. -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 1 07:44:28 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 07:44:18 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47880 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 1 Sep 2000 07:44:09 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08907 for ; Fri, 1 Sep 2000 07:50:35 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA18412; Fri, 1 Sep 2000 09:42:51 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA24676; Fri, 1 Sep 2000 09:42:51 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA28903; Fri, 1 Sep 2000 09:42:42 -0500 Message-Id: <200009011442.JAA28903@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: cattelan@thebarn.com cc: "Davida, Joe" , "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation In-Reply-To: Message from Russell Cattelan of "Fri, 01 Sep 2000 09:20:01 CDT." <39AFBB10.48C59783@thebarn.com> Date: Fri, 01 Sep 2000 09:42:42 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Andi Kleen wrote: > > > On Thu, Aug 31, 2000 at 03:44:34PM -0600, Davida, Joe wrote: > > > Is there any information on the 2 TBytes file system > > > limitation in Linux which is also inherited by the > > > linux port of xfs? What imposes this limitation? > > > Are the current efforts aimed at removing this > > > limitation? I hear ReiserFS has a 16 Terabyte > > > file system size. > > > > The 2TB limitation is caused by the interface between block drivers > > and file systems. On 32bit machines a 32bit value is used to pass the > > sector number, with the sector being in 512byte units. Limiting yourself > > to 31bits is probably safer to protect against signedness bugs in the > > driver. > > > > That gives you a 2^31 * 2^9 = 2^40bits block device size limit for all > > file systems and raw devices. > > > > On 64bit systems the limit is higher, assuming there are no 32bit limitatio ns > > in the driver. > > > > Also note the 16TB limit is true for all linux file systems at the moment. > The block interface on linux indexes on the block size of the file system, i n > almost all cases it's the PAGE_SIZE aka 4k. > 2^32 * 4096 / TB's = 16TB I would have to disagree with Russell here - the lower layers of the I/O path map all addresses to 512 byte units, this line in ll_rw_block is the starting point: bh->b_rsector = bh->b_blocknr * (bh->b_size>>9); and b_rsector is defined as unsigned long b_rsector; /* Real buffer location on disk */ The kiobuf based I/O path also moves the disk address through a 32 bit variable which is in terms of 512 byte sectors. So to break the 2 Tbyte limit (or possibly 1 Tbyte if there are signed variables used somewhere) on device addressability on 32 bit platforms will take some work. [ So while I was writing this, Russell pointed out that LVM is mapping down to individual devices from the one logical device, so in theory it could concatenate smaller devices into a larger single logical device. There would still be some work involved here, but probably a smaller amount. ] > > XFS has additional problems with inode numbers overflowing the > standard 32bit container once the file system its self goes over 2TB. > > Fixing this either requires changing linux to support 64bit inode numbers > not terribly difficult but time consuming in that the linux community > has to all agree as to what needs to be done, or change the way XFS > deals with inode numbers. This does require some fundamental changes > in XFS... up until this point we have made very few fundamental changes > to XFS internals. Which as worked out very well since we know the code > base is solid. This is also not strictly true, the inode number visible out side of XFS is a 32 bit number, it is possible to rework the way XFS and iget are working together to avoid having the XFS inode number go through this 32 bit field. There are two caveats to this: 1. NFS will require work - it explicitly uses the 32 bit inode number in file handles. 2. Dealing with getting 64 bits of inode information up to user space, interfaces like stat64 are not quite doing the right thing, since they only pass 32 bits of inode number. Andi Kleen said: (excuse the formatting here!) >> > > Fixing this either requires changing linux to support 64bit inode >> numbers > not terribly difficult but time consuming in that the linux >> community > has to all agree as to what needs to be done, or change >> the way XFS > deals with inode numbers. This does require some >> fundamental changes > in XFS... up until this point we have made very >> few fundamental changes > to XFS internals. Which as worked out very >> well since we know the code > base is solid. >> Linux needs to do it generally for the NFSv3 client anyways, so it may >> make more sense to change Linux. >> I still think making the contents of the NFS file handle opaque to NFS itself is a better way to go. It has a length field, and the file systems can do the best they can with the space available. Steve From owner-linux-xfs@oss.sgi.com Fri Sep 1 07:54:38 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 07:54:18 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:25101 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Fri, 1 Sep 2000 07:53:58 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e81Ersa55505; Fri, 1 Sep 2000 09:53:54 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39AFC301.90EEC7D0@thebarn.com> Date: Fri, 01 Sep 2000 09:53:54 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: "Davida, Joe" , "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation References: <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com> <20000901141936.A10785@gruyere.muc.suse.de> <39AFBB10.48C59783@thebarn.com> <20000901163556.A14222@gruyere.muc.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Andi Kleen wrote: > On Fri, Sep 01, 2000 at 09:20:01AM -0500, Russell Cattelan wrote: > > Andi Kleen wrote: > > > > > On Thu, Aug 31, 2000 at 03:44:34PM -0600, Davida, Joe wrote: > > > > Is there any information on the 2 TBytes file system > > > > limitation in Linux which is also inherited by the > > > > linux port of xfs? What imposes this limitation? > > > > Are the current efforts aimed at removing this > > > > limitation? I hear ReiserFS has a 16 Terabyte > > > > file system size. > > > > > > The 2TB limitation is caused by the interface between block drivers > > > and file systems. On 32bit machines a 32bit value is used to pass the > > > sector number, with the sector being in 512byte units. Limiting yourself > > > to 31bits is probably safer to protect against signedness bugs in the > > > driver. > > > > > > That gives you a 2^31 * 2^9 = 2^40bits block device size limit for all > > > file systems and raw devices. > > > > > > On 64bit systems the limit is higher, assuming there are no 32bit limitations > > > in the driver. > > > > > > > Also note the 16TB limit is true for all linux file systems at the moment. > > The block interface on linux indexes on the block size of the file system, in > > almost all cases it's the PAGE_SIZE aka 4k. > > 2^32 * 4096 / TB's = 16TB > > Internally in ll_rw_block() it always scales down to 512 byte blocks, and > that is what the interface to the drivers uses. So it is always 2TB. > So I haven't gone and actually looked at code but given the only way to get to 16TB is through a volume manager, the process or re-mapping requests will bring any individual device under the 2^40 limit but still allow indexing at the ll_rw_block level up to 16TB. I'll have to go look to verify this. > > > > > Fixing this either requires changing linux to support 64bit inode numbers > > not terribly difficult but time consuming in that the linux community > > has to all agree as to what needs to be done, or change the way XFS > > deals with inode numbers. This does require some fundamental changes > > in XFS... up until this point we have made very few fundamental changes > > to XFS internals. Which as worked out very well since we know the code > > base is solid. > > Linux needs to do it generally for the NFSv3 client anyways, so it may make > more sense to change Linux. That is what we assuming will happen thus we have been punting on this issue until things are worked out. > > > -Andi -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Fri Sep 1 09:21:59 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 09:21:49 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:27722 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 1 Sep 2000 09:21:23 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA27535 for ; Fri, 1 Sep 2000 09:13:45 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA72051 for ; Fri, 1 Sep 2000 11:18:51 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id LAA97934 for ; Fri, 1 Sep 2000 11:18:51 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id LAA30873; Fri, 1 Sep 2000 11:18:41 -0500 Message-Id: <200009011618.LAA30873@jen.americas.sgi.com> Date: Fri, 1 Sep 2000 11:18:41 -0500 Subject: TAKE - Fix for running XFS on machines with more than 4Gbytes of RAM To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This change ensures that XFS metadata buffers - which must be directly accessable from kernel context, are not allocated from highmem pages. File data can be in highmem pages since the kernel never looks at it. If we do not use kiobuf I/O, then in theory we can cross the 4 Gbyte boundary now. This is entirely untested since I have only 1/32 the required memory! Date: Fri Sep 1 09:15:47 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73501a linux/fs/xfs/xfs_buf.h - 1.60 - define PBF_MAPPABLE linux/include/linux/page_buf.h - 1.64 - Use PBF_MAPPABLE on metadata pagebuf calls linux/fs/pagebuf/page_buf.c - 1.27 - Use PBF_MAPPABLE to indicate which types of pages are allowed in a pagebuf From owner-linux-xfs@oss.sgi.com Fri Sep 1 09:24:28 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 09:24:19 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:13538 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 1 Sep 2000 09:24:09 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id LAA17755; Fri, 1 Sep 2000 11:23:32 -0500 (CDT) Message-Id: <4.2.0.58.20000901112356.022a8de0@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 01 Sep 2000 11:25:41 -0500 To: cattelan@thebarn.com, "Davida, Joe" From: "William L. Jones" Subject: Re: 2 Terabyte File System Size Limitation Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <39AFBB10.48C59783@thebarn.com> References: <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com> <20000901141936.A10785@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 09:20 AM 9/1/00 -0500, Russell Cattelan wrote: >Andi Kleen wrote: > > > On Thu, Aug 31, 2000 at 03:44:34PM -0600, Davida, Joe wrote: > > > Is there any information on the 2 TBytes file system > > > limitation in Linux which is also inherited by the > > > linux port of xfs? What imposes this limitation? > > > Are the current efforts aimed at removing this > > > limitation? I hear ReiserFS has a 16 Terabyte > > > file system size. > > > > The 2TB limitation is caused by the interface between block drivers > > and file systems. On 32bit machines a 32bit value is used to pass the > > sector number, with the sector being in 512byte units. Limiting yourself > > to 31bits is probably safer to protect against signedness bugs in the > > driver. > > > > That gives you a 2^31 * 2^9 = 2^40bits block device size limit for all > > file systems and raw devices. > > > > On 64bit systems the limit is higher, assuming there are no 32bit > limitations > > in the driver. > > > >Also note the 16TB limit is true for all linux file systems at the moment. >The block interface on linux indexes on the block size of the file system, in >almost all cases it's the PAGE_SIZE aka 4k. >2^32 * 4096 / TB's = 16TB > >XFS has additional problems with inode numbers overflowing the >standard 32bit container once the file system its self goes over 2TB. I was wondering about that. It seem like you should be able to control this with mkfs.xfs by setting agcont and setting the agsize instead of letting mkfs.xfs set them. I don't think that many people need a file system that can contain a billion files. Just a few hundred million will due. The only down side in doing this is that the inode info may not be splattered across all of the file system like it would if you used the mkfs.xfs defaults. >Fixing this either requires changing linux to support 64bit inode numbers >not terribly difficult but time consuming in that the linux community >has to all agree as to what needs to be done, or change the way XFS >deals with inode numbers. This does require some fundamental changes >in XFS... up until this point we have made very few fundamental changes >to XFS internals. Which as worked out very well since we know the code >base is solid. > >It is unclear as the best path at this point. >It is one of the things to fix in one of the near future releases. >For the moment we are concentrating on getting our first Beta >finalized. > > > > >-- >Russell Cattelan >cattelan@thebarn.com > From owner-linux-xfs@oss.sgi.com Fri Sep 1 09:48:09 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 09:47:59 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:60496 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 1 Sep 2000 09:47:43 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA00836 for ; Fri, 1 Sep 2000 09:40:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA68831; Fri, 1 Sep 2000 11:45:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id LAA60808; Fri, 1 Sep 2000 11:45:09 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id LAA30940; Fri, 1 Sep 2000 11:44:59 -0500 Message-Id: <200009011644.LAA30940@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "William L. Jones" cc: cattelan@thebarn.com, "Davida, Joe" , "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation In-Reply-To: Message from "William L. Jones" of "Fri, 01 Sep 2000 11:25:41 CDT." <4.2.0.58.20000901112356.022a8de0@127.0.0.1> Date: Fri, 01 Sep 2000 11:44:59 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > >XFS has additional problems with inode numbers overflowing the > >standard 32bit container once the file system its self goes over 2TB. > > I was wondering about that. It seem like you should be able to control > this with mkfs.xfs by setting agcont and setting the > agsize instead of letting mkfs.xfs set them. I don't think that many people > need a file system that can contain a billion files. Just a few > hundred million will due. The only down side in doing this > is that the inode info may not be splattered across all of the file system > like it would if you used the mkfs.xfs defaults. > > The problem is not the number of inodes the system will allow you to create, it is where they are created. An XFS inode number is actually a disk address, once the filesystem goes beyond the 2Tbyte limit inodes can have addresses which are beyond this boundary and hence over flow the 32 bit inode field. At the moment there is no way of restricting inodes to specific allocation groups, but I suppose it would be possible to do this. In fact it might be a simpler solution than anything else. The consequences are : 1. moving an existing filesystem from Irix will still potentially leave us with inodes beyond the boundary. 2. it will change the distribution of inodes in the filesystem, which will in turn change how data is distributed. There is a danger that the first 2 Tbytes would have to become fairly full and hence potentially fragmented before much data made it into the rest of the filesystem. This will take some thinking about. Steve From owner-linux-xfs@oss.sgi.com Fri Sep 1 11:00:50 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 11:00:39 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:14310 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 1 Sep 2000 11:00:15 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id MAA18763; Fri, 1 Sep 2000 12:59:57 -0500 (CDT) Message-Id: <4.2.0.58.20000901124606.02229390@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 01 Sep 2000 13:02:04 -0500 To: Steve Lord , "William L. Jones" From: "William L. Jones" Subject: Re: 2 Terabyte File System Size Limitation Cc: cattelan@thebarn.com, "Davida, Joe" , "'linux-xfs@oss.sgi.com'" In-Reply-To: <200009011644.LAA30940@jen.americas.sgi.com> References: <4.2.0.58.20000901112356.022a8de0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 11:44 AM 9/1/00 -0500, Steve Lord wrote: > > > > > >XFS has additional problems with inode numbers overflowing the > > >standard 32bit container once the file system its self goes over 2TB. > > > > I was wondering about that. It seem like you should be able to control > > this with mkfs.xfs by setting agcont and setting the > > agsize instead of letting mkfs.xfs set them. I don't think that many > people > > need a file system that can contain a billion files. Just a few > > hundred million will due. The only down side in doing this > > is that the inode info may not be splattered across all of the file system > > like it would if you used the mkfs.xfs defaults. > > > > > > >The problem is not the number of inodes the system will allow you to create, >it is where they are created. An XFS inode number is actually a disk address, >once the filesystem goes beyond the 2Tbyte limit inodes can have addresses >which are beyond this boundary and hence over flow the 32 bit inode field. > >At the moment there is no way of restricting inodes to specific allocation >groups, but I suppose it would be possible to do this. In fact it might be >a simpler solution than anything else. The consequences are : > >1. moving an existing filesystem from Irix will still potentially leave > us with inodes beyond the boundary. > >2. it will change the distribution of inodes in the filesystem, which will > in turn change how data is distributed. There is a danger that the first > 2 Tbytes would have to become fairly full and hence potentially fragmented > before much data made it into the rest of the filesystem. This will take > some thinking about. > >Steve > > It really is very simple. XFS just the inode shifted down by the by the log2(number of inodes per disk block)+log(agsize) to find the ag group that the inode is in. The the maxima inode is just: agcount<; Fri, 1 Sep 2000 17:45:50 -0700 Received: from Cantor.suse.de ([194.112.123.193]:51727 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Fri, 1 Sep 2000 17:45:38 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 42A421E4BB; Sat, 2 Sep 2000 02:45:37 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id A282610A029; Sat, 2 Sep 2000 02:45:36 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id C0B1D2F300; Sat, 2 Sep 2000 02:45:35 +0200 (MEST) Date: Sat, 2 Sep 2000 02:45:35 +0200 From: "Andi Kleen" To: Steve Lord Cc: cattelan@thebarn.com, "Davida, Joe" , "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation Message-ID: <20000902024535.A23502@gruyere.muc.suse.de> References: <200009011442.JAA28903@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200009011442.JAA28903@jen.americas.sgi.com>; from lord@sgi.com on Fri, Sep 01, 2000 at 09:42:42AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, Sep 01, 2000 at 09:42:42AM -0500, Steve Lord wrote: > >> > > Fixing this either requires changing linux to support 64bit inode > >> numbers > not terribly difficult but time consuming in that the linux > >> community > has to all agree as to what needs to be done, or change > >> the way XFS > deals with inode numbers. This does require some > >> fundamental changes > in XFS... up until this point we have made very > >> few fundamental changes > to XFS internals. Which as worked out very > >> well since we know the code > base is solid. > > >> Linux needs to do it generally for the NFSv3 client anyways, so it may > >> make more sense to change Linux. > >> > > I still think making the contents of the NFS file handle opaque to NFS > itself is a better way to go. It has a length field, and the file systems > can do the best they can with the space available. That is being planned (e.g. see the patch set from Neil Brown) I was talking about the v3 client not the server, sorry for being unclear. For it the file handle is opaque anyways. It just has to support 64bit fileid and readdir cookies, upto userland. -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 1 21:53:23 2000 Received: by oss.sgi.com id ; Fri, 1 Sep 2000 21:53:13 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:33808 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Fri, 1 Sep 2000 21:52:55 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e824qka56325 for ; Fri, 1 Sep 2000 23:52:48 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39B0879E.F4C6C44B@thebarn.com> Date: Fri, 01 Sep 2000 23:52:46 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [Fwd: Performance: dbench] Content-Type: multipart/mixed; boundary="------------C19DB27A2CD9A93869D908D5" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------C19DB27A2CD9A93869D908D5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Russell Cattelan cattelan@thebarn.com --------------C19DB27A2CD9A93869D908D5 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e81ITNE77493 for ; Fri, 1 Sep 2000 13:29:25 -0500 (CDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02530; Fri, 1 Sep 2000 11:29:19 -0700 (PDT) mail_from (owner-slinx-xfs@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA47075 for slinx-xfs-list; Fri, 1 Sep 2000 11:29:18 -0700 (PDT) mail_from (owner-slinx-xfs@relay.engr.sgi.com) Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA79706 for ; Fri, 1 Sep 2000 11:29:17 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA40962 for ; Fri, 1 Sep 2000 11:25:36 -0700 (PDT) Message-ID: <39AFF5F5.A325C820@sgi.com> Date: Fri, 01 Sep 2000 11:31:17 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.15-3SGI_31 i686) X-Accept-Language: en MIME-Version: 1.0 To: slinx-xfs@cthulhu.engr.sgi.com Subject: Performance: dbench Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-slinx-xfs@cthulhu.engr.sgi.com Precedence: bulk Following are some numbers for ext2 & xfs on my 2P 64MB box. I still have problems running with 48 clients (vn_revalidate bug), so can't produce consistent numbers yet for 48 clients. This is fairly good results since XFS does well on medium->high workloads. Experiments consisted of 5 runs at each client number; since both ext2 & xfs show variations, I took the best 3 out of the 5 runs. ----------------------------------------------------------------- FS CLIENTS RUN1 RUN2 RUN3 AVERAGE % Difference MB/sec MB/sec MB/sec MB/sec ----------------------------------------------------------------- EXT2 1 21.0606 21.7978 21.8338 21.564067 XFS 1 13.6206 13.3493 13.7145 13.561467 -37.110812 % EXT2 2 27.3789 26.8325 26.7883 26.999900 XFS 2 22.223 22.0518 23.3991 22.557966 -16.451670 % EXT2 4 18.5587 18.7769 19.7357 19.023767 XFS 4 19.8324 20.5395 20.2117 20.194533 6.154222 % EXT2 8 16.8232 16.7258 14.8582 16.135733 XFS 8 18.8964 19.0119 18.8931 18.933800 17.340812 % EXT2 16 14.469 14.5848 14.8714 14.641733 XFS 16 16.551 15.4399 15.7445 15.911467 8.672037 % EXT2 32 13.7791 11.6484 12.1279 12.518467 XFS 32 12.6676 13.164 12.4833 12.771633 2.022342 % -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- --------------C19DB27A2CD9A93869D908D5-- From owner-linux-xfs@oss.sgi.com Sun Sep 3 12:18:26 2000 Received: by oss.sgi.com id ; Sun, 3 Sep 2000 12:18:16 -0700 Received: from smtp1.cern.ch ([137.138.128.38]:6916 "EHLO smtp1.cern.ch") by oss.sgi.com with ESMTP id ; Sun, 3 Sep 2000 12:18:01 -0700 Received: from pcrd10.cern.ch (pcrd10.cern.ch [137.138.29.237]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id VAA19828 for ; Sun, 3 Sep 2000 21:17:58 +0200 (MET DST) Received: (from fuji@localhost) by pcrd10.cern.ch (8.9.3/8.9.3) id VAA04840 for linux-xfs@oss.sgi.com; Sun, 3 Sep 2000 21:17:28 +0200 Date: Sun, 3 Sep 2000 21:17:28 +0200 From: Peter.Kelemen@cern.ch To: linux-xfs@oss.sgi.com Subject: XFS assertion failed: vp->v_bh.bh_first != NULL Message-ID: <20000903211728.C3797@pcrd10.cern.ch> Reply-To: Peter.Kelemen@cern.ch Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i X-Beat: @845 Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --gKMricLos+KVdGMg Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, I've been playing around with XFS (among ReiserFS and JFS) and hit a bug while running 8 parallel bonnie++ processes on a dual Pentium III 500Mhz machine with 256M memory. Two bonnies triggered an assertion failure somewhere around vnode handling; those processes were killed immediately by the kernel. The filesystem the test was running on was 36GB in size, each bonnie++ using 3x3G files for block IO test and 30000 files for metadata testing. The kernel is 2.4.0-test5 patched[1] with xfs (CVS version 20000829), reiserfs (3.6.13) and jfs (0.0.10) in this order and merged. Attached is the syslog excerpt as well as the oops processed by ksymoops. I'll try to answer any upcoming questions and willing to try out fixes for two weeks from now on, but after then I won't have access to the test machine. Peter [1] The patch is available: http://home.cern.ch/fuji/patches/jumbofs-2.4.0-test5-B1.bz2 -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' --gKMricLos+KVdGMg Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from fuji.mailbox.cern.ch [137.138.131.156] by localhost with POP3 (fetchmail-5.4.1) for fuji@localhost (single-drop); Fri, 01 Sep 2000 16:13:46 +0200 (CEST) Received: via tmail-4.1(10) for fuji; Fri, 1 Sep 2000 16:11:44 +0200 (MET DST) Return-Path: Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by mail5.cern.ch (8.9.3/8.9.3) with ESMTP id QAA20721 for ; Fri, 1 Sep 2000 16:11:43 +0200 (MET DST) Received: from pcrd18.cern.ch (pcrd18.cern.ch [137.138.181.240]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id QAA03167 for ; Fri, 1 Sep 2000 16:11:43 +0200 (MET DST) Received: (from root@localhost) by pcrd18.cern.ch (8.9.3/8.9.3) id QAA32045 for Peter.Kelemen@cern.ch; Fri, 1 Sep 2000 16:11:43 +0200 Date: Fri, 1 Sep 2000 16:11:43 +0200 From: root Message-Id: <200009011411.QAA32045@pcrd18.cern.ch> To: Peter.Kelemen@cern.ch Subject: oops.xfs_8 MIME-Version: 1.0 Sep 1 11:23:08 pcrd18 kernel: xfs_iget_core: ambiguous vns: vp/0xc6a8e620, invp/0xc8b51a40 Sep 1 11:23:08 pcrd18 kernel: XFS assertion failed: vp->v_bh.bh_first != NULL, file: xfs_vnode.c, line: 488 Sep 1 11:23:08 pcrd18 kernel: kernel BUG at xfs_debug.c:50! Sep 1 11:23:08 pcrd18 kernel: invalid operand: 0000 Sep 1 11:23:08 pcrd18 kernel: CPU: 1 Sep 1 11:23:08 pcrd18 kernel: EIP: 0010:[assfail+45/52] Sep 1 11:23:08 pcrd18 kernel: EFLAGS: 00010246 Sep 1 11:23:08 pcrd18 kernel: eax: 0000001e ebx: c8b51a40 ecx: c030720c edx: 00000000 Sep 1 11:23:08 pcrd18 kernel: esi: c8b51a40 edi: c8b51a40 ebp: c8defb88 esp: c8defb7c Sep 1 11:23:08 pcrd18 kernel: ds: 0018 es: 0018 ss: 0018 Sep 1 11:23:08 pcrd18 kernel: Process bonnie++ (pid: 31645, stackpage=c8def000) Sep 1 11:23:08 pcrd18 kernel: Stack: c02d045a c02d044e 00000032 c8defc18 c01eb3e8 c02d39a0 c02d3759 000001e8 Sep 1 11:23:08 pcrd18 kernel: 00000009 c8b51a40 c8b51a40 14003fff c1474400 00000001 00000286 c8b51a40 Sep 1 11:23:08 pcrd18 kernel: c8b51a40 c8b51a40 c8defc14 c01eb86b c78095b8 00000002 c02c69b1 00000000 Sep 1 11:23:08 pcrd18 kernel: Call Trace: [extflag.506+33298/115032] [extflag.506+33286/115032] [vn_revalidate+72/276] [extflag.506+46936/115032] [extflag.506+46353/115032] [vn_trace_exit+87/96] [offsets.238+689/6976] Sep 1 11:23:08 pcrd18 kernel: [xfs_vn_iget+46/56] [xfs_iget_core+616/2140] [xfs_iget_core+2104/2140] [xfs_dir2_data_check+958/1552] [xfs_vn_iget+46/56] [vn_initialize+301/424] [linvfs_read_inode+32/72] [get_new_inode+229/380] Sep 1 11:23:08 pcrd18 kernel: [iget4+221/232] [vn_get+40/240] [xfs_iget_core+482/2140] [xfs_iget+45/56] [xfs_dir_lookup_int+633/1284] [vn_trace_entry+87/96] [extflag.506+27397/115032] [xfs_lookup+224/388] Sep 1 11:23:08 pcrd18 kernel: [xfs_trans_unlocked_item+35/64] [linvfs_lookup+147/296] [real_lookup+125/292] [path_walk+1615/2224] [__user_walk+60/92] [sys_newstat+23/108] [system_call+52/56] [stext+43/204] Sep 1 11:23:08 pcrd18 kernel: Code: 0f 0b 89 ec 5d c3 90 55 89 e5 81 ec 00 01 00 00 56 53 8b 45 Sep 1 13:08:00 pcrd18 kernel: xfs_iget_core: ambiguous vns: vp/0xcf020ac0, invp/0xc7576ea0 Sep 1 13:08:00 pcrd18 kernel: XFS assertion failed: vp->v_bh.bh_first != NULL, file: xfs_vnode.c, line: 488 Sep 1 13:08:00 pcrd18 kernel: kernel BUG at xfs_debug.c:50! Sep 1 13:08:00 pcrd18 kernel: invalid operand: 0000 Sep 1 13:08:00 pcrd18 kernel: CPU: 0 Sep 1 13:08:00 pcrd18 kernel: EIP: 0010:[assfail+45/52] Sep 1 13:08:00 pcrd18 kernel: EFLAGS: 00010246 Sep 1 13:08:00 pcrd18 kernel: eax: 0000001e ebx: c7576ea0 ecx: c030720c edx: 00000000 Sep 1 13:08:00 pcrd18 kernel: esi: c7576ea0 edi: c7576ea0 ebp: c23b1b88 esp: c23b1b7c Sep 1 13:08:00 pcrd18 kernel: ds: 0018 es: 0018 ss: 0018 Sep 1 13:08:00 pcrd18 kernel: Process bonnie++ (pid: 31648, stackpage=c23b1000) Sep 1 13:08:00 pcrd18 kernel: Stack: c02d045a c02d044e 00000032 c23b1c18 c01eb3e8 c02d39a0 c02d3759 000001e8 Sep 1 13:08:00 pcrd18 kernel: 00000009 c7576ea0 c7576ea0 14003fff c1474400 00000001 00000286 c7576ea0 Sep 1 13:08:00 pcrd18 kernel: c7576ea0 c7576ea0 c23b1c14 c01eb86b c2ea7e78 00000002 c02c69b1 00000000 Sep 1 13:08:00 pcrd18 kernel: Call Trace: [extflag.506+33298/115032] [extflag.506+33286/115032] [vn_revalidate+72/276] [extflag.506+46936/115032] [extflag.506+46353/115032] [vn_trace_exit+87/96] [offsets.238+689/6976] Sep 1 13:08:00 pcrd18 kernel: [xfs_vn_iget+46/56] [xfs_iget_core+616/2140] [xfs_iget_core+2104/2140] [xfs_dir2_data_check+656/1552] [xfs_vn_iget+46/56] [vn_initialize+301/424] [linvfs_read_inode+32/72] [get_new_inode+229/380] Sep 1 13:08:00 pcrd18 kernel: [iget4+221/232] [vn_get+40/240] [xfs_iget_core+482/2140] [xfs_iget+45/56] [xfs_dir_lookup_int+633/1284] [vn_trace_entry+87/96] [extflag.506+27397/115032] [xfs_lookup+224/388] Sep 1 13:08:00 pcrd18 kernel: [xfs_trans_unlocked_item+35/64] [linvfs_lookup+147/296] [real_lookup+125/292] [path_walk+1615/2224] [__user_walk+60/92] [sys_newstat+23/108] [system_call+52/56] [stext+43/204] Sep 1 13:08:00 pcrd18 kernel: Code: 0f 0b 89 ec 5d c3 90 55 89 e5 81 ec 00 01 00 00 56 53 8b 45 --gKMricLos+KVdGMg Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from fuji.mailbox.cern.ch [137.138.131.156] by localhost with POP3 (fetchmail-5.4.1) for fuji@localhost (single-drop); Sun, 03 Sep 2000 21:08:03 +0200 (CEST) Received: via tmail-4.1(10) for fuji; Sun, 3 Sep 2000 21:01:45 +0200 (MET DST) Return-Path: Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by mail5.cern.ch (8.9.3/8.9.3) with ESMTP id VAA21204 for ; Sun, 3 Sep 2000 21:01:45 +0200 (MET DST) Received: from pcrd18.cern.ch (pcrd18.cern.ch [137.138.181.240]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id VAA21482 for ; Sun, 3 Sep 2000 21:01:45 +0200 (MET DST) Received: (from fuji@localhost) by pcrd18.cern.ch (8.9.3/8.9.3) id VAA01345 for Peter.Kelemen@cern.ch; Sun, 3 Sep 2000 21:01:19 +0200 Date: Sun, 3 Sep 2000 21:01:19 +0200 From: KELEMEN Peter Message-Id: <200009031901.VAA01345@pcrd18.cern.ch> To: Peter.Kelemen@cern.ch MIME-Version: 1.0 ksymoops 2.3.4 on i686 2.4.0-test5-jumbofs. Options used -v /w/fuji/build/cvs/linux-2.4-xfs/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test5-jumbofs/ (default) -m /boot/System.map-2.4.0-test5-jumbofs (specified) No modules in ksyms, skipping objects Sep 1 11:23:08 pcrd18 kernel: invalid operand: 0000 Sep 1 11:23:08 pcrd18 kernel: CPU: 1 Sep 1 11:23:08 pcrd18 kernel: EIP: 0010:[assfail+45/52] Sep 1 11:23:08 pcrd18 kernel: EFLAGS: 00010246 Sep 1 11:23:08 pcrd18 kernel: eax: 0000001e ebx: c8b51a40 ecx: c030720c edx: 00000000 Sep 1 11:23:08 pcrd18 kernel: esi: c8b51a40 edi: c8b51a40 ebp: c8defb88 esp: c8defb7c Sep 1 11:23:08 pcrd18 kernel: ds: 0018 es: 0018 ss: 0018 Sep 1 11:23:08 pcrd18 kernel: Process bonnie++ (pid: 31645, stackpage=c8def000) Sep 1 11:23:08 pcrd18 kernel: Stack: c02d045a c02d044e 00000032 c8defc18 c01eb3e8 c02d39a0 c02d3759 000001e8 Sep 1 11:23:08 pcrd18 kernel: 00000009 c8b51a40 c8b51a40 14003fff c1474400 00000001 00000286 c8b51a40 Sep 1 11:23:08 pcrd18 kernel: c8b51a40 c8b51a40 c8defc14 c01eb86b c78095b8 00000002 c02c69b1 00000000 Sep 1 11:23:08 pcrd18 kernel: Call Trace: [extflag.506+33298/115032] [extflag.506+33286/115032] [vn_revalidate+72/276] [extflag.506+46936/115032] [extflag.506+46353/115032] [vn_trace_exit+87/96] [offsets.238+689/6976] Sep 1 11:23:08 pcrd18 kernel: Code: 0f 0b 89 ec 5d c3 90 55 89 e5 81 ec 00 01 00 00 56 53 8b 45 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 0f 0b ud2a Code; 00000002 Before first symbol 2: 89 ec movl %ebp,%esp Code; 00000004 Before first symbol 4: 5d popl %ebp Code; 00000005 Before first symbol 5: c3 ret Code; 00000006 Before first symbol 6: 90 nop Code; 00000007 Before first symbol 7: 55 pushl %ebp Code; 00000008 Before first symbol 8: 89 e5 movl %esp,%ebp Code; 0000000a Before first symbol a: 81 ec 00 01 00 00 subl $0x100,%esp Code; 00000010 Before first symbol 10: 56 pushl %esi Code; 00000011 Before first symbol 11: 53 pushl %ebx Code; 00000012 Before first symbol 12: 8b 45 00 movl 0x0(%ebp),%eax Sep 1 13:08:00 pcrd18 kernel: invalid operand: 0000 Sep 1 13:08:00 pcrd18 kernel: CPU: 0 Sep 1 13:08:00 pcrd18 kernel: EIP: 0010:[assfail+45/52] Sep 1 13:08:00 pcrd18 kernel: EFLAGS: 00010246 Sep 1 13:08:00 pcrd18 kernel: eax: 0000001e ebx: c7576ea0 ecx: c030720c edx: 00000000 Sep 1 13:08:00 pcrd18 kernel: esi: c7576ea0 edi: c7576ea0 ebp: c23b1b88 esp: c23b1b7c Sep 1 13:08:00 pcrd18 kernel: ds: 0018 es: 0018 ss: 0018 Sep 1 13:08:00 pcrd18 kernel: Process bonnie++ (pid: 31648, stackpage=c23b1000) Sep 1 13:08:00 pcrd18 kernel: Stack: c02d045a c02d044e 00000032 c23b1c18 c01eb3e8 c02d39a0 c02d3759 000001e8 Sep 1 13:08:00 pcrd18 kernel: 00000009 c7576ea0 c7576ea0 14003fff c1474400 00000001 00000286 c7576ea0 Sep 1 13:08:00 pcrd18 kernel: c7576ea0 c7576ea0 c23b1c14 c01eb86b c2ea7e78 00000002 c02c69b1 00000000 Sep 1 13:08:00 pcrd18 kernel: Call Trace: [extflag.506+33298/115032] [extflag.506+33286/115032] [vn_revalidate+72/276] [extflag.506+46936/115032] [extflag.506+46353/115032] [vn_trace_exit+87/96] [offsets.238+689/6976] Sep 1 13:08:00 pcrd18 kernel: Code: 0f 0b 89 ec 5d c3 90 55 89 e5 81 ec 00 01 00 00 56 53 8b 45 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 0f 0b ud2a Code; 00000002 Before first symbol 2: 89 ec movl %ebp,%esp Code; 00000004 Before first symbol 4: 5d popl %ebp Code; 00000005 Before first symbol 5: c3 ret Code; 00000006 Before first symbol 6: 90 nop Code; 00000007 Before first symbol 7: 55 pushl %ebp Code; 00000008 Before first symbol 8: 89 e5 movl %esp,%ebp Code; 0000000a Before first symbol a: 81 ec 00 01 00 00 subl $0x100,%esp Code; 00000010 Before first symbol 10: 56 pushl %esi Code; 00000011 Before first symbol 11: 53 pushl %ebx Code; 00000012 Before first symbol 12: 8b 45 00 movl 0x0(%ebp),%eax --gKMricLos+KVdGMg-- From owner-linux-xfs@oss.sgi.com Sun Sep 3 14:57:46 2000 Received: by oss.sgi.com id ; Sun, 3 Sep 2000 14:57:37 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:23306 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Sun, 3 Sep 2000 14:57:16 -0700 Received: (qmail 19797 invoked from network); 3 Sep 2000 21:57:09 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 3 Sep 2000 21:57:09 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Peter.Kelemen@cern.ch cc: linux-xfs@oss.sgi.com Subject: Re: XFS assertion failed: vp->v_bh.bh_first != NULL In-reply-to: Your message of "Sun, 03 Sep 2000 21:17:28 +0200." <20000903211728.C3797@pcrd10.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Sep 2000 08:57:09 +1100 Message-ID: <17574.968018229@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, 3 Sep 2000 21:17:28 +0200, Peter.Kelemen@cern.ch wrote: >Attached is the syslog excerpt as well as the >oops processed by ksymoops. >Sep 1 11:23:08 pcrd18 kernel: Call Trace: [extflag.506+33298/115032] [extflag.506+33286/115032] [vn_revalidate+72/276] [extflag.506+46936/115032] [extflag.506+46353/115032] [vn_trace_exit+87/96] [offsets.238+689/6976] klogd has got in first and stamped on the trace, got it wrong and left no useful trace data for ksymoops. Can you change klogd to run as "klogd -x" and reproduce the problem? -x stops klogd attempting to translate the oops log, I change it in /etc/rc.d/init.d/syslog then /etc/rc.d/init.d/syslog restart. From owner-linux-xfs@oss.sgi.com Sun Sep 3 19:48:02 2000 Received: by oss.sgi.com id ; Sun, 3 Sep 2000 19:47:52 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21776 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 3 Sep 2000 19:47:29 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA03894 for ; Sun, 3 Sep 2000 19:53:57 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA93866 for linux-xfs@oss.sgi.com; Mon, 4 Sep 2000 13:44:53 +1100 (EST) Date: Mon, 4 Sep 2000 13:44:53 +1100 (EST) From: Daniel Moore Message-Id: <200009040244.NAA93866@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_db fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73573a Date: Sun Sep 3 19:44:41 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/input.c - 1.15 - another fix for efence From owner-linux-xfs@oss.sgi.com Sun Sep 3 19:49:42 2000 Received: by oss.sgi.com id ; Sun, 3 Sep 2000 19:49:32 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23312 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 3 Sep 2000 19:49:17 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA08707; Sun, 3 Sep 2000 19:55:47 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA63258; Sun, 3 Sep 2000 19:48:46 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA23876; Sun, 3 Sep 2000 19:47:30 -0700 (PDT) Date: Sun, 3 Sep 2000 19:47:30 -0700 (PDT) Message-Id: <200009040247.TAA23876@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: UPDATE 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: tduffy@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 *CC List : tduffy@sgi.com Status : open Priority : 2 Assigned Engineer : lord Submitter : ananth Opened Date : 08/29/00 *Modified User : ananth *Modified User Domain : engr *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (UPDATE) From: ananth@engr (BugWorks) Date: Sep 03 2000 07:47:29PM ========================== Console is available through "telnet b30-3c-linux-annex 5002". Also add Tom Duffy to cc: list. ananth. From owner-linux-xfs@oss.sgi.com Sun Sep 3 19:53:12 2000 Received: by oss.sgi.com id ; Sun, 3 Sep 2000 19:53:02 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:32820 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 3 Sep 2000 19:52:53 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA05822 for ; Sun, 3 Sep 2000 19:45:12 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA02061 for linux-xfs@oss.sgi.com; Mon, 4 Sep 2000 13:51:33 +1100 (EST) Date: Mon, 4 Sep 2000 13:51:33 +1100 (EST) From: Daniel Moore Message-Id: <200009040251.NAA02061@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_db fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73574a Date: Sun Sep 3 19:51:23 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/mount.c - 1.21 - access freed mem From owner-linux-xfs@oss.sgi.com Sun Sep 3 22:22:24 2000 Received: by oss.sgi.com id ; Sun, 3 Sep 2000 22:22:14 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:1857 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 3 Sep 2000 22:21:39 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA12667; Sun, 3 Sep 2000 22:13:20 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA06655; Sun, 3 Sep 2000 22:20:56 -0700 (PDT) Date: Sun, 3 Sep 2000 22:20:56 -0700 (PDT) Message-Id: <200009040520.WAA06655@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 800850 - XFS + CONFIG_HIGHMEM4GB bug To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 Submitter : dxm Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xf6eedd6c [0]kdb> bt EBP EIP Function(args) 0xf6eeddb4 0xc013077b kunmap_high+0x6f kernel .text 0xc0100000 0xc013070c 0xc01307a0 0xf6eedde8 0xf882041f [pagebuf]__pagebuf_do_delwri+0x1cb (0xf6f3e0a0, 0x0, 0x0, 0x10000, 0x4010e000) pagebuf .text 0xf881c060 0xf8820254 0xf88204cc 0xf6eede64 0xf88205f2 [pagebuf]_pagebuf_file_write+0x126 (0xf6f619e0, 0x4010e000, 0x10000, 0xf6eedecc, 0x2) pagebuf .text 0xf881c060 0xf88204cc 0xf882062c 0xf6eedef0 0xf882080f [pagebuf]pagebuf_generic_file_write+0x1e3 (0xf6f619e0, 0x4010e000, 0x10000, 0xf6eedf90) pagebuf .text 0xf881c060 0xf882062c 0xf8820a48 0xf6eedf14 0xf8993572 [xfs]xfs_rdwr+0x72 (0xf6f66908, 0xf6f619e0, 0x4010e000, 0x10000, 0xf6eedf90) xfs .text 0xf8921060 0xf8993500 0xf8993580 0xf6eedf60 0xf8994338 [xfs]xfs_write+0x158 (0xf6f66908, 0xf6f619e0, 0x4010e000, 0x10000, 0xf6eedf90) xfs .text 0xf8921060 0xf89941e0 0xf89943e4 0xf6eedf98 0xf898fbb0 [xfs]linvfs_write+0xec (0xf6f619e0, 0x4010e000, 0x10000, 0xf6f61a00, 0xf6eec000) xfs .text 0xf8921060 0xf898fac4 0xf898fbdc 0xf6eedfbc 0xc01326d8 sys_write+0xa8 (0x3, 0x4010e000, 0x10000, 0x10000, 0x8049b10) kernel .text 0xc0100000 0xc0132630 0xc01326f0 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [0]kdb> ps ... 0xf6eec000 00001187 00001178 1 000 run 0xf6eec340*fill From owner-linux-xfs@oss.sgi.com Sun Sep 3 23:09:35 2000 Received: by oss.sgi.com id ; Sun, 3 Sep 2000 23:09:25 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2837 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 3 Sep 2000 23:09:02 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA09362; Sun, 3 Sep 2000 23:15:02 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id XAA24259; Sun, 3 Sep 2000 23:08:01 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA01249; Sun, 3 Sep 2000 23:06:45 -0700 (PDT) Date: Sun, 3 Sep 2000 23:06:45 -0700 (PDT) Message-Id: <200009040606.XAA01249@info.engr.sgi.com> X-Pv-Incident: 800293 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 800293 - repair can corrupt directories To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800293 Status : open Priority : 2 Assigned Engineer : nathans Submitter : nathans *Modified User : nathans *Modified User Domain : engr *Description : Test 031 reproduces this one - it runs mkfs and then repairs numerous different combinations of directory version and directory size ... repair seems to get itself into trouble without even mounting these filesystems (created using mkfs prototype files). To exercise this bug (use the sim mkfs/repair binaries, cos we seem to trip an assert in libxfs-mkfs before completing): $ cd cmd/xfs/sim $ make ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Sep 03 2000 11:06:44PM ========================== OK, so I've investigated the first part of this bug now, i.e. the "rebuilding directory inode 128" message. It turns out that this is simply the way its designed to work... this message comes about as a side effect of us deleting the existing lost+found entry in the root directory (inode 128 in this QA test), and that message is printed unconditionally later when we find we need to fix some directory. This is the case for all non-shortform v2 directories, and is not a real problem after all. Onto the "# of bmap records" error message next... From owner-linux-xfs@oss.sgi.com Sun Sep 3 23:12:55 2000 Received: by oss.sgi.com id ; Sun, 3 Sep 2000 23:12:44 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:42565 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 3 Sep 2000 23:12:21 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA15274 for ; Sun, 3 Sep 2000 23:04:10 -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 RAA61365 for linux-xfs@oss.sgi.com; Mon, 4 Sep 2000 17:10:31 +1100 (EST) Date: Mon, 4 Sep 2000 17:10:31 +1100 (EST) From: Nathan Scott Message-Id: <200009040610.RAA61365@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - misc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73575a Date: Sun Sep 3 23:10:04 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/Makefile - 1.31 - ensure realclean gets LDIRT too. cmd/xfs/configure.in - 1.14 cmd/xfs/libxfs/Makefile - 1.6 - fiddle with the way -g & -DDEBUG are set to assist libxfs/repair build. cmd/xfs/repair/phase6.c - 1.58 - cosmetic. cmd/xfs/stress/031 - 1.5 cmd/xfs/stress/031.out - 1.2 - rebuilding directory inode is not a problem in this test (lost+found). cmd/xfs/stress/src/Makefile - 1.13 - rework to ensure the test programs are also linked with any malloc debugging lib in use. From owner-linux-xfs@oss.sgi.com Sun Sep 3 23:59:45 2000 Received: by oss.sgi.com id ; Sun, 3 Sep 2000 23:59:35 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16406 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 3 Sep 2000 23:58:55 -0700 Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA09914 for ; Mon, 4 Sep 2000 00:04:44 -0700 (PDT) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.9.3/8.9.3) id UAA14044; Sun, 3 Sep 2000 20:57:50 -0700 Date: Sun, 3 Sep 2000 20:57:50 -0700 From: Ananth Ananthanarayanan Message-Id: <200009040357.UAA14044@waco.engr.sgi.com> Subject: TAKE 80050 - use kmap properly To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel, I don't have access to a m/c with > 1GB. Please let me know if this fixes your problem. Also, note that "kio" and "kiocluster" mount options don't work on a highmem system (see bug #800061) ... Date: Sun Sep 3 23:52:57 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73576a linux/fs/pagebuf/page_buf_io.c - 1.28 - Use kmap to accomodate highmem pages. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Sep 4 00:54:25 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 00:54:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:46416 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 00:53:47 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA20139 for ; Mon, 4 Sep 2000 00:45:26 -0700 (PDT) mail_from (tes@sherman.melbourne.sgi.com) Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id SAA20015 for linux-xfs@oss.sgi.com; Mon, 4 Sep 2000 18:52:42 +1100 Date: Mon, 4 Sep 2000 18:52:42 +1100 From: Tim Shimmin Message-Id: <200009040752.SAA20015@sherman.melbourne.sgi.com> Subject: TAKE - xfs/stress To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel, This should hopefully fix 028 on bruce. I have added tkdiff to stress/check so that I can use check visually on the our qa host. I've changed your auto-qa script to use -l so that the normal diff is used. I'll p_tupdate your auto-qa so hopefully things work tonight. --Tim Date: Mon Sep 4 00:46:33 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73577a cmd/xfs/stress/common - 1.2 - Let diff be tkdiff if available. cmd/xfs/stress/028 - 1.3 - Use hostname(1) instead of the fqdn. cmd/xfs/tools/auto-qa - 1.4 - Should use "-l" option to check. This will become vital now there is the chance of using tkdiff. From owner-linux-xfs@oss.sgi.com Mon Sep 4 09:39:38 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 09:39:28 -0700 Received: from dukat.scot.redhat.com ([195.89.149.246]:47368 "EHLO dukat.scot.redhat.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 09:39:00 -0700 Received: (from sct@localhost) by dukat.scot.redhat.com (8.9.3/8.9.3) id RAA16084; Mon, 4 Sep 2000 17:37:02 +0100 Date: Mon, 4 Sep 2000 17:37:02 +0100 From: "Stephen C. Tweedie" To: Russell Cattelan Cc: Andi Kleen , "Davida, Joe" , "'linux-xfs@oss.sgi.com'" , Stephen Tweedie Subject: Re: 2 Terabyte File System Size Limitation Message-ID: <20000904173702.K12913@redhat.com> References: <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com> <20000901141936.A10785@gruyere.muc.suse.de> <39AFBB10.48C59783@thebarn.com> <20000901163556.A14222@gruyere.muc.suse.de> <39AFC301.90EEC7D0@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39AFC301.90EEC7D0@thebarn.com>; from cattelan@thebarn.com on Fri, Sep 01, 2000 at 09:53:54AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, On Fri, Sep 01, 2000 at 09:53:54AM -0500, Russell Cattelan wrote: > So I haven't gone and actually looked at code but given the only way to get to > 16TB is through a volume manager, the process or re-mapping requests > will bring any individual device under the 2^40 limit but still allow indexing at > the ll_rw_block level up to 16TB. No. LVMs still get passed 512-byte indexed requests. A LVM exports a block device, and that block device is just as much subject to the 2TB limit as the physical block devices underneath it are. The fact that the LVM device is a virtual device, not a physical one, does not make a difference, sadly. Cheers, Stephen From owner-linux-xfs@oss.sgi.com Mon Sep 4 13:04:39 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 13:04:29 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:51158 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 13:04:14 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id PAA24058; Mon, 4 Sep 2000 15:03:32 -0500 (CDT) Message-Id: <4.2.0.58.20000904122220.021ca800@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 04 Sep 2000 15:05:47 -0500 To: Steve Lord , "William L. Jones" From: "William L. Jones" Subject: Re: 2 Terabyte File System Size Limitation - More like 16TB?? Cc: cattelan@thebarn.com, "Davida, Joe" , "'linux-xfs@oss.sgi.com'" In-Reply-To: <200009011644.LAA30940@jen.americas.sgi.com> References: <4.2.0.58.20000901112356.022a8de0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I should have looked closer at mkfs.xfs. You have only control over agcount or agsize not both. Fortunately their is one other nob that can be turned with mkfs.xfs the size of an inode. So, if an inode size of 256 gets you to 2TB then setting the inode size to 512 should get you to 4TB. Since you can set the indoe to a maxium 2048 you should be able to create a 16TB file system on linux using xfs and LVM. Assuming that LVM will allow you to address a 16TB logical volume. Bill Jones From owner-linux-xfs@oss.sgi.com Mon Sep 4 14:17:09 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 14:16:59 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:19928 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 14:16:41 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id QAA24585; Mon, 4 Sep 2000 16:15:53 -0500 (CDT) Message-Id: <4.2.0.58.20000904161519.02249ae0@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 04 Sep 2000 16:18:07 -0500 To: "Stephen C. Tweedie" , Russell Cattelan From: "William L. Jones" Subject: Re: 2 Terabyte File System Size Limitation Cc: Andi Kleen , "Davida, Joe" , "'linux-xfs@oss.sgi.com'" , Stephen Tweedie In-Reply-To: <20000904173702.K12913@redhat.com> References: <39AFC301.90EEC7D0@thebarn.com> <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com> <20000901141936.A10785@gruyere.muc.suse.de> <39AFBB10.48C59783@thebarn.com> <20000901163556.A14222@gruyere.muc.suse.de> <39AFC301.90EEC7D0@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 05:37 PM 9/4/00 +0100, Stephen C. Tweedie wrote: >Hi, > >On Fri, Sep 01, 2000 at 09:53:54AM -0500, Russell Cattelan wrote: > > > So I haven't gone and actually looked at code but given the only way to > get to > > 16TB is through a volume manager, the process or re-mapping requests > > will bring any individual device under the 2^40 limit but still allow > indexing at > > the ll_rw_block level up to 16TB. > >No. LVMs still get passed 512-byte indexed requests. A LVM exports a >block device, and that block device is just as much subject to the 2TB >limit as the physical block devices underneath it are. The fact that >the LVM device is a virtual device, not a physical one, does not make >a difference, sadly. > >Cheers, > Stephen My haed hurts. Your are right. Just when I figured out how make a large XFS file system. Bill Jones From owner-linux-xfs@oss.sgi.com Mon Sep 4 14:24:49 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 14:24:39 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:42761 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 14:24:16 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e84LNZa15403; Mon, 4 Sep 2000 16:23:35 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39B412D6.DC808174@thebarn.com> Date: Mon, 04 Sep 2000 16:23:34 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "William L. Jones" CC: "Stephen C. Tweedie" , Andi Kleen , "Davida, Joe" , "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation References: <39AFC301.90EEC7D0@thebarn.com> <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com> <20000901141936.A10785@gruyere.muc.suse.de> <39AFBB10.48C59783@thebarn.com> <20000901163556.A14222@gruyere.muc.suse.de> <39AFC301.90EEC7D0@thebarn.com> <4.2.0.58.20000904161519.02249ae0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "William L. Jones" wrote: > At 05:37 PM 9/4/00 +0100, Stephen C. Tweedie wrote: > >Hi, > > > >On Fri, Sep 01, 2000 at 09:53:54AM -0500, Russell Cattelan wrote: > > > > > So I haven't gone and actually looked at code but given the only way to > > get to > > > 16TB is through a volume manager, the process or re-mapping requests > > > will bring any individual device under the 2^40 limit but still allow > > indexing at > > > the ll_rw_block level up to 16TB. > > > >No. LVMs still get passed 512-byte indexed requests. A LVM exports a > >block device, and that block device is just as much subject to the 2TB > >limit as the physical block devices underneath it are. The fact that > >the LVM device is a virtual device, not a physical one, does not make > >a difference, sadly. > > > >Cheers, > > Stephen > > My haed hurts. Your are right. Just when I figured out how make a large > XFS file system. I'll join you in the aspirin cocktail. It's incredibly frustrating to find things that obviously should have been implemented correctly in the first place. I would say it shouldn't be much trouble fixing LVM to index up to 16TB. I think time would be better spent working on the kiobuf I/O, since the 2 TB isn't the only thing wrong with the current buffer head I/O implementation. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Sep 4 16:29:59 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 16:29:49 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:31546 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 16:29:34 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00773; Mon, 4 Sep 2000 16:35:34 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA35515; Mon, 4 Sep 2000 16:29:01 -0700 (PDT) Date: Mon, 4 Sep 2000 16:29:01 -0700 (PDT) Message-Id: <200009042329.QAA35515@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 800850 - XFS + CONFIG_HIGHMEM4GB bug To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 Status : open Priority : 2 Assigned Engineer : nb Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 04 2000 04:29:01PM ========================== Anath, with your change we get a lot further through a QA run, but eventually end up in kdb during QA 009. Let me know if you need more info or want more tests done on this machine. NMI Watchdog detected LOCKUP on CPU1, registers: CPU: 1 EIP: 0010:[] EFLAGS: 00000086 eax: 00000001 ebx: c2100034 ecx: 00000001 edx: 00000000 esi: f61812c0 edi: f6e677a0 ebp: c2119e04 esp: c2119d64 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c2119000) Stack: c2100010 f61812c0 f6e677a0 c2119d80 00000000 f7970000 00000202 f7ddc980 00000246 f7c7c400 f7b43da0 f79a0000 00000202 00000000 00000001 00000000 00000001 ffffffff 00000246 f79a0000 f7970000 00000013 00000001 00000013 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 80 3b 00 f3 90 7e f9 e9 18 fa f1 ff 80 3d 00 b4 30 c0 00 f3 Entering kdb (0xc2118000) on processor 1 due to WatchDog Interrupt @ 0xc01f7db1 eax = 0x00000001 ebx = 0xc2100034 ecx = 0x00000001 edx = 0x00000000 esi = 0xf61812c0 edi = 0xf6e677a0 esp = 0xc2119d64 eip = 0xc01f7db1 ebp = 0xc2119e04 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000086 ds = 0xf79a0018 es = 0xf79a0018 origeax = 0x00000001 ®s = 0xc2119d30 [1]kdb> bt EBP EIP Function(args) 0xc01f7db1 stext_lock+0x829 kernel .text.lock 0xc01f7588 0xc01f7588 0xc01fd320 0xc2119e04 0xc01177d5 __wake_up+0x55 kernel .text 0xc0100000 0xc0117780 0xc0118040 0xc2119e20 0xf881d307 [pagebuf]_end_pagebuf_page_io+0x127 (0xf6e677a0, 0x1) pagebuf .text 0xf881c060 0xf881d1e0 0xf881d330 0xc2119e34 0xc01307b4 bounce_end_io_write+0x14 (0xf6e24980, 0x1) kernel .text 0xc0100000 0xc01307a0 0xc01307d4 0xc2119e74 0xc01b1956 __scsi_end_request+0xc2 (0xf7c7c400, 0x1, 0x80, 0x1) kernel .text 0xc0100000 0xc01b1894 0xc01b1b78 0xc2119eb4 0xc01b1dbc scsi_io_completion+0x160 (0xf7c7c400, 0x80, 0x1) kernel .text 0xc0100000 0xc01b1c5c 0xc01b1f88 0xc2119ed4 0xc01a3640 rw_intr+0x16c (0xf7c7c400) kernel .text 0xc0100000 0xc01a34d4 0xc01a364c 0xc2119f08 0xc01b4e2b scsi_old_done+0x5bb (0xf7c7c400) kernel .text 0xc0100000 0xc01b4870 0xc01b4e4c 0xc2119f20 0xc01ab9f1 sym53c8xx_intr+0x85 (0x39, 0xf7dbe000, 0xc2119f70, 0x720, 0xc0309f20) kernel .text 0xc0100000 0xc01ab96c 0xc01aba0c 0xc2119f40 0xc010ab39 handle_IRQ_event+0x4d (0x39, 0xc2119f70, 0xf7ddfb00, 0xc01071d0, 0xc2118000) kernel .text 0xc0100000 0xc010aaec 0xc010ab68 0xc2119f68 0xc010ad39 do_IRQ+0x99 (0xc01071d0, 0x0, 0xc2118000, 0xc2118000, 0xc01071d0) kernel .text 0xc0100000 0xc010aca0 0xc010ad8c [1]more> 0xc0109100 ret_from_intr kernel .text 0xc0100000 0xc0109100 0xc0109120 Interrupt registers: eax = 0x00000000 ebx = 0xc01071d0 ecx = 0x00000000 edx = 0xc2118000 esi = 0xc2118000 edi = 0xc01071d0 esp = 0xc2119fa4 eip = 0xc0107200 ebp = 0xc2119fa4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000246 ds = 0xc0100018 es = 0xc2110018 origeax = 0xffffff39 ®s = 0xc2119f70 0xc0107200 default_idle+0x30 kernel .text 0xc0100000 0xc01071d0 0xc0107208 0xc2119fb8 0xc0107272 cpu_idle+0x42 kernel .text 0xc0100000 0xc0107230 0xc0107288 0xc2119fc0 0xc02d4745 start_secondary+0x21 kernel .text.init 0xc02d0000 0xc02d4724 0xc02d474c [1]kdb> cpu 0 Entering kdb (0xc02ce000) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xc02cffd0 0xc0107200 default_idle+0x30 kernel .text 0xc0100000 0xc01071d0 0xc0107208 0xc02cffe4 0xc0107272 cpu_idle+0x42 (0x0) kernel .text 0xc0100000 0xc0107230 0xc0107288 0xc02cfff8 0xc02d0c7f start_kernel+0x18f kernel .text.init 0xc02d0000 0xc02d0af0 0xc02d0c88 (no processes in run state) From owner-linux-xfs@oss.sgi.com Mon Sep 4 16:42:20 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 16:42:10 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39994 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 16:41:43 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00605 for ; Mon, 4 Sep 2000 16:47:33 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA80765 for linux-xfs@oss.sgi.com; Tue, 5 Sep 2000 10:39:44 +1100 (EST) Date: Tue, 5 Sep 2000 10:39:44 +1100 (EST) From: Daniel Moore Message-Id: <200009042339.KAA80765@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - auto-qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing more clean-ups Modid: 2.4.0-test1-xfs:slinx:73580a Date: Mon Sep 4 16:39:28 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/tools/auto-qa - 1.5 - more tidyups From owner-linux-xfs@oss.sgi.com Mon Sep 4 17:58:40 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 17:58:30 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:62988 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 17:58:12 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e850vca29759; Mon, 4 Sep 2000 19:57:38 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39B44502.FF980323@thebarn.com> Date: Mon, 04 Sep 2000 19:57:38 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Martin K. Petersen" CC: linux-xfs@oss.sgi.com Subject: Re: LVM vs. buffer_heads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Martin K. Petersen" wrote: > I've done some test runs of LVM with the legacy I/O path over the > weekend. No corruption except one minor caveat, that I'll get back to > below. > > Russell/Steve: Did you ever experience *runtime* corruption? > > Reason I ask is that I've had a box running for 4 days on a 5 disk > striped LV doing bonnie++, repetetive kernel builds and postmark > without any corruption whatsoever. > > Until I unmounted the filesystem, that is. At which point at least > the log got completely garbled (Subsequent mount attempts yielded > BUG() in xfs_log_recover.c:2655). Hmm still not making it through a glibc build. I'm seeing corruption in .d files (dependency files). I'm running doio at the moment to see if it turns up anything. > > I will investigate. > > ``Quick! To the electron microscope''... > > -- > Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. > http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Sep 4 18:16:50 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 18:16:40 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2365 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 18:16:32 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA03002 for ; Mon, 4 Sep 2000 18:23:03 -0700 (PDT) mail_from (ananth@waco.engr.sgi.com) Received: from waco.engr.sgi.com ([163.154.18.95]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA32464 for ; Mon, 4 Sep 2000 18:16:01 -0700 (PDT) Received: (from ananth@localhost) by waco.engr.sgi.com (8.9.3/8.9.3) id PAA24581; Mon, 4 Sep 2000 15:13:21 -0700 Date: Mon, 4 Sep 2000 15:13:21 -0700 From: Ananth Ananthanarayanan Message-Id: <200009042213.PAA24581@waco.engr.sgi.com> Subject: TAKE 800850 - make end_*_io highmem clean To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Sep 4 18:13:03 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73584a linux/fs/pagebuf/page_buf.c - 1.28 - Avoid ambiguous use of page_address in end_*_io. This can be revisited when non-page-sized blocks are made to work. From owner-linux-xfs@oss.sgi.com Mon Sep 4 18:20:40 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 18:20:30 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7997 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 18:20:24 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA09649 for ; Mon, 4 Sep 2000 18:26:54 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA44409; Mon, 4 Sep 2000 18:14:41 -0700 (PDT) Message-ID: <39B448FE.5E9DC613@sgi.com> Date: Mon, 04 Sep 2000 18:14:38 -0700 From: Rajagopal Ananthanarayanan Reply-To: linux-xfs@oss.sgi.com X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: cattelan@thebarn.com CC: "Martin K. Petersen" , linux-xfs@oss.sgi.com Subject: Re: LVM vs. buffer_heads References: <39B44502.FF980323@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Hmm still not making it through a glibc build. > I'm seeing corruption in .d files (dependency files). > > I'm running doio at the moment to see if it turns up anything. > Are these problems seen _only_ with lvm, or are you having problems with glibc build in general? -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Sep 4 18:23:30 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 18:23:20 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:50245 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 18:23:11 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA21391; Mon, 4 Sep 2000 18:15:32 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA99160; Mon, 4 Sep 2000 18:22:40 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA85740; Mon, 4 Sep 2000 18:20:03 -0700 (PDT) Date: Mon, 4 Sep 2000 18:20:03 -0700 (PDT) Message-Id: <200009050120.SAA85740@feature.engr.sgi.com> X-Pv-Incident: 800850 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (ananth@engr.sgi.com) Subject: TAKE 800850 - XFS + CONFIG_HIGHMEM4GB bug To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : dxm *Status : closed Assigned Engineer : nb *Fixed By : ananth *Fixed By Domain : engr *Closed Date : 09/04/00 Priority : 2 *Modified Date : 09/04/00 *Modified User : ananth *Modified User Domain : engr *Fix Description : From: ananth ananthanarayanan (TAKE) Date: Sep 04 2000 06:20:03PM [pvnews version: 1.71] ---------------------------- Date: Mon Sep 4 18:13:03 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73584a linux/fs/pagebuf/page_buf.c - 1.28 - Avoid ambiguous use of page_address in end_*_io. This can be revisited when non-page-sized blocks are made to work. Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 04 2000 04:29:01PM ========================== Anath, with your change we get a lot further through a QA run, but eventually end up in kdb during QA 009. Let me know if you need more info or want more tests done on this machine. NMI Watchdog detected LOCKUP on CPU1, registers: CPU: 1 EIP: 0010:[] EFLAGS: 00000086 eax: 00000001 ebx: c2100034 ecx: 00000001 edx: 00000000 esi: f61812c0 edi: f6e677a0 ebp: c2119e04 esp: c2119d64 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c2119000) Stack: c2100010 f61812c0 f6e677a0 c2119d80 00000000 f7970000 00000202 f7ddc980 00000246 f7c7c400 f7b43da0 f79a0000 00000202 00000000 00000001 00000000 00000001 ffffffff 00000246 f79a0000 f7970000 00000013 00000001 00000013 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 80 3b 00 f3 90 7e f9 e9 18 fa f1 ff 80 3d 00 b4 30 c0 00 f3 Entering kdb (0xc2118000) on processor 1 due to WatchDog Interrupt @ 0xc01f7db1 eax = 0x00000001 ebx = 0xc2100034 ecx = 0x00000001 edx = 0x00000000 esi = 0xf61812c0 edi = 0xf6e677a0 esp = 0xc2119d64 eip = 0xc01f7db1 ebp = 0xc2119e04 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000086 ds = 0xf79a0018 es = 0xf79a0018 origeax = 0x00000001 ®s = 0xc2119d30 [1]kdb> bt EBP EIP Function(args) 0xc01f7db1 stext_lock+0x829 kernel .text.lock 0xc01f7588 0xc01f7588 0xc01fd320 0xc2119e04 0xc01177d5 __wake_up+0x55 kernel .text 0xc0100000 0xc0117780 0xc0118040 0xc2119e20 0xf881d307 [pagebuf]_end_pagebuf_page_io+0x127 (0xf6e677a0, 0x1) pagebuf .text 0xf881c060 0xf881d1e0 0xf881d330 0xc2119e34 0xc01307b4 bounce_end_io_write+0x14 (0xf6e24980, 0x1) kernel .text 0xc0100000 0xc01307a0 0xc01307d4 0xc2119e74 0xc01b1956 __scsi_end_request+0xc2 (0xf7c7c400, 0x1, 0x80, 0x1) kernel .text 0xc0100000 0xc01b1894 0xc01b1b78 0xc2119eb4 0xc01b1dbc scsi_io_completion+0x160 (0xf7c7c400, 0x80, 0x1) kernel .text 0xc0100000 0xc01b1c5c 0xc01b1f88 0xc2119ed4 0xc01a3640 rw_intr+0x16c (0xf7c7c400) kernel .text 0xc0100000 0xc01a34d4 0xc01a364c 0xc2119f08 0xc01b4e2b scsi_old_done+0x5bb (0xf7c7c400) kernel .text 0xc0100000 0xc01b4870 0xc01b4e4c 0xc2119f20 0xc01ab9f1 sym53c8xx_intr+0x85 (0x39, 0xf7dbe000, 0xc2119f70, 0x720, 0xc0309f20) kernel .text 0xc0100000 0xc01ab96c 0xc01aba0c 0xc2119f40 0xc010ab39 handle_IRQ_event+0x4d (0x39, 0xc2119f70, 0xf7ddfb00, 0xc01071d0, 0xc2118000) kernel .text 0xc0100000 0xc010aaec 0xc010ab68 0xc2119f68 0xc010ad39 do_IRQ+0x99 (0xc01071d0, 0x0, 0xc2118000, 0xc2118000, 0xc01071d0) kernel .text 0xc0100000 0xc010aca0 0xc010ad8c [1]more> 0xc0109100 ret_from_intr kernel .text 0xc0100000 0xc0109100 0xc0109120 Interrupt registers: eax = 0x00000000 ebx = 0xc01071d0 ecx = 0x00000000 edx = 0xc2118000 esi = 0xc2118000 edi = 0xc01071d0 esp = 0xc2119fa4 eip = 0xc0107200 ebp = 0xc2119fa4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000246 ds = 0xc0100018 es = 0xc2110018 origeax = 0xffffff39 ®s = 0xc2119f70 0xc0107200 default_idle+0x30 kernel .text 0xc0100000 0xc01071d0 0xc0107208 0xc2119fb8 0xc0107272 cpu_idle+0x42 kernel .text 0xc0100000 0xc0107230 0xc0107288 0xc2119fc0 0xc02d4745 start_secondary+0x21 kernel .text.init 0xc02d0000 0xc02d4724 0xc02d474c [1]kdb> cpu 0 Entering kdb (0xc02ce000) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xc02cffd0 0xc0107200 default_idle+0x30 kernel .text 0xc0100000 0xc01071d0 0xc0107208 0xc02cffe4 0xc0107272 cpu_idle+0x42 (0x0) kernel .text 0xc0100000 0xc0107230 0xc0107288 0xc02cfff8 0xc02d0c7f start_kernel+0x18f kernel .text.init 0xc02d0000 0xc02d0af0 0xc02d0c88 (no processes in run state) From owner-linux-xfs@oss.sgi.com Mon Sep 4 18:31:50 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 18:31:40 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:7949 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 18:31:33 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e851VUa29797; Mon, 4 Sep 2000 20:31:30 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39B44CF2.EC2ED66@thebarn.com> Date: Mon, 04 Sep 2000 20:31:30 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: "Martin K. Petersen" Subject: Re: LVM vs. buffer_heads References: <39B44502.FF980323@thebarn.com> <39B448FE.5E9DC613@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Rajagopal Ananthanarayanan wrote: > > > > Hmm still not making it through a glibc build. > > I'm seeing corruption in .d files (dependency files). > > > > I'm running doio at the moment to see if it turns up anything. > > > > Are these problems seen _only_ with lvm, or > are you having problems with glibc build in general? Right now I am only running the build on a lvm volume It's unclear who's problem this might be XFS? LVM? or FC. I'll try a single FC drive next to eliminate some of the variables. > > > -------------------------------------------------------------------------- > Rajagopal Ananthanarayanan ("ananth") > Member Technical Staff, SGI. > -------------------------------------------------------------------------- -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Sep 4 22:13:21 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 22:13:11 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:60226 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 22:12:56 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA04637 for ; Mon, 4 Sep 2000 22:19: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 QAA17583 for linux-xfs@oss.sgi.com; Tue, 5 Sep 2000 16:11:35 +1100 (EST) Date: Tue, 5 Sep 2000 16:11:35 +1100 (EST) From: Nathan Scott Message-Id: <200009050511.QAA17583@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - stress Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73598a Date: Mon Sep 4 22:11:20 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/030 - 1.4 - make sure there are no valid secondary superblocks within the 1st AG, otherwise we can pick the wrong one when recovering the primary. cmd/xfs/stress/common.repair - 1.2 - tighten filter regex. cmd/xfs/stress/group - 1.32 - bring 030 and 031 into auto-qa runs. From owner-linux-xfs@oss.sgi.com Mon Sep 4 22:58:04 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 22:57:53 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7748 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 22:57:37 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA08993; Mon, 4 Sep 2000 23:04:07 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA42922; Mon, 4 Sep 2000 22:57:35 -0700 (PDT) Date: Mon, 4 Sep 2000 22:57:35 -0700 (PDT) Message-Id: <200009050557.WAA42922@info.engr.sgi.com> X-Pv-Incident: 800293 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: WONTFIX 800293 - repair can corrupt directories To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800293 *Status : wontfix Priority : 2 Assigned Engineer : nathans Submitter : nathans Opened Date : 08/27/00 *Closed Date : 09/04/00 *Fixed By : nathans *Fixed By Domain : engr *Modified Date : 09/04/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (WONTFIX) From: nathans@engr (BugWorks) Date: Sep 04 2000 10:57:34PM ========================== Oh my - this one's a corker... I've finally figured out why test 031 is failing for me. It isn't a libxfs, libsim, repair or mkfs bug ... all work just the way they were intended. The problem arises because at the point when we run this test in our QA suite (from 1 thru 33 sequentially), we have previously created a small - 3 allocation group - XFS filesystem on the scratch device. Now, we _do_ actually do a mkfs in test 031, the problem arises because we use the whole device. In my case, this means I create an 8 allocation group filesystem with relatively large allocation groups (the previous, small filesystem fits entirely within my new first AG). So, the test now blows away the primary superblock ... and runs repair. This does the right thing - realises the primary superblock is useless, and starts hunting for secondaries. It finds two valid superblocks in short time which seem to agree with each other and with the fact that there should be only three allocation groups. Again repair does the right thing, and thinking it has a good SB promotes the contents of the first secondary into the primary SB. Of course, at this point we're completely hosed. Even if we did proceed onward looking for other superblocks on the rest of the device - there's not alot we could do with them... we'd just have two valid, conflicting sets of superblocks. We could possibly eventually decide which set was consistent with the rest of the AG data structures, but it seems to me that this is such an unlikely situation to ever happen in practice that its not worth the effort, nor the pain of going through and initializing the entire data device to something known to be good (at mkfs time). Its also never bitten anyone before in IRIX, afaik, so I'm inclined to simply WONTFIX this "bug". cheers. From owner-linux-xfs@oss.sgi.com Tue Sep 5 04:20:44 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 04:20:34 -0700 Received: from [62.81.31.73] ([62.81.31.73]:15485 "EHLO smtp4s.retemail.es") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 04:20:20 -0700 Received: from BE-198-MALA-X2.red.retevision.es ([62.82.238.198]) by smtp4s.retemail.es (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000905112014.HVLV6257.smtp4s@BE-198-MALA-X2.red.retevision.es> for ; Tue, 5 Sep 2000 13:20:14 +0200 Date: Tue, 5 Sep 2000 13:31:54 +0200 From: krypto X-Mailer: The Bat! (v1.42f) UNREG / CD5BF9353B3B7091 Reply-To: krypto X-Priority: 3 (Normal) Message-ID: <231379678.20000905133154@elrancho.com> To: linux-xfs@oss.sgi.com Subject: newbie Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi all... I am new to this list. Excuse me if the question is somehow off-topic. I know you're all busy, so I'll try not to disturb you much. I am trying to design several tests to run with different file systems for a linux gazette article. Since all of them are journal file systems, I would like to measure the time to recover for each file system once a crash occurs. My question is the following: is there anyway (from user space) to crash a partition, I mean unmount it uncleanly as it happens when you power off the computer without unmounting. I would like to unmount uncleanly just the partition I choose, in order not to crash the root partition too. If not, is it possible to do that writing a user app?...not hacking the modules code... because I need the buffers not to be flushed to disk. Suggestions and ideas for tests are welcome. Thanx in advance. -- Ta luegoz _ __ _______ __ ___ _____ ___ | / /( |\ \/ /| _)|_ _|| | |_\_\/_/|_| |__| |_| |_| |___| krypto mailto:krypto@elrancho.com From owner-linux-xfs@oss.sgi.com Tue Sep 5 07:47:45 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 07:47:35 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:25951 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 07:47:16 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA07278 for ; Tue, 5 Sep 2000 07:53:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA87896; Tue, 5 Sep 2000 09:45:58 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA05781; Tue, 5 Sep 2000 09:45:58 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA08658; Tue, 5 Sep 2000 09:45:09 -0500 Message-Id: <200009051445.JAA08658@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: krypto cc: linux-xfs@oss.sgi.com Subject: Re: newbie In-Reply-To: Message from krypto of "Tue, 05 Sep 2000 13:31:54 +0200." <231379678.20000905133154@elrancho.com> Date: Tue, 05 Sep 2000 09:45:09 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing You are attempting a fairly hard task, the time to recover is probably going to be a function of how much data was dirty at the time of crash, you need a fairly deterministic test setup to get any sort of reliable results. For instance, in XFS, 300 changes to the same inode one after the other will be a lot cheaper to recover from than 300 changes to different inodes, and with different inodes it would depend on where those inodes were allocated, they could all end up in 10 inode clusters (i.e. 10 disk reads and writes) or 300 different inode clusters. So lots of test runs and averaged results (+ standard deviation etc). That aside, there is really no simple way to simulate a failed unmount without modifying the kernel code. In XFS you would have to modify the linvfs_put_super() function in fs/xfs/linux/xfs_super.c so that it just returned immediately rather than executing any code. Steve > Hi all... > > I am new to this list. Excuse me if the question > is somehow off-topic. I know you're all busy, so > I'll try not to disturb you much. > > I am trying to design several tests to run with > different file systems for a linux gazette article. > Since all of them are journal file systems, > I would like to measure the time to recover for > each file system once a crash occurs. > My question is the following: > is there anyway (from user space) to crash a > partition, I mean unmount it uncleanly as it > happens when you power off the computer without > unmounting. I would like to unmount uncleanly just > the partition I choose, in order not to crash the > root partition too. > If not, is it possible to do that writing a > user app?...not hacking the modules code... > because I need the buffers not to be flushed to > disk. > > Suggestions and ideas for tests are welcome. > > Thanx in advance. > > > -- > Ta luegoz > > _ __ _______ __ ___ _____ ___ > | / /( |\ \/ /| _)|_ _|| | > |_\_\/_/|_| |__| |_| |_| |___| > > krypto mailto:krypto@elrancho.com > From owner-linux-xfs@oss.sgi.com Tue Sep 5 07:58:35 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 07:58:25 -0700 Received: from Cantor.suse.de ([194.112.123.193]:14862 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Tue, 5 Sep 2000 07:58:04 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 381701E378; Tue, 5 Sep 2000 16:57:59 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 0C42B10A029; Tue, 5 Sep 2000 16:57:59 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 323812F300; Tue, 5 Sep 2000 16:57:58 +0200 (MEST) Date: Tue, 5 Sep 2000 16:57:58 +0200 From: "Andi Kleen" To: krypto Cc: linux-xfs@oss.sgi.com Subject: Re: newbie Message-ID: <20000905165758.A21368@gruyere.muc.suse.de> References: <231379678.20000905133154@elrancho.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <231379678.20000905133154@elrancho.com>; from krypto@elrancho.com on Tue, Sep 05, 2000 at 01:31:54PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Sep 05, 2000 at 01:31:54PM +0200, krypto wrote: > If not, is it possible to do that writing a > user app?...not hacking the modules code... > because I need the buffers not to be flushed to > disk. The only easy way to do it from user space I could imagine is to port XFS to UML (http://user-mode-linux.sourceforge.net) and try it there by killing the linux processes. It is probably still not a very meaningfull benchmark. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 5 08:20:25 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 08:20:15 -0700 Received: from [134.6.67.21] ([134.6.67.21]:12298 "EHLO mcoexc03.mlm.maxtor.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 08:19:57 -0700 Received: by mcoexc03.mlm.maxtor.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Sep 2000 09:17:50 -0600 Message-ID: <09D1E9BD9C30D311919200A0C9DD5C2C02536F87@mcaexc01.msj.maxtor.com> From: "Davida, Joe" To: "'linux-xfs@oss.sgi.com'" Subject: RE: 2 Terabyte File System Size Limitation Date: Tue, 5 Sep 2000 09:18:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Is what Bill Jones is saying correct? I am just starting on XFS, and dont have enough familiarity with it's architecture. Cheers, Joe >-----Original Message----- >From: William L. Jones [mailto:jones@tacc.cc.utexas.edu] >Sent: Friday, September 01, 2000 11:02 AM >To: Steve Lord; William L. Jones >Cc: cattelan@thebarn.com; Davida, Joe; 'linux-xfs@oss.sgi.com' >Subject: Re: 2 Terabyte File System Size Limitation > > >At 11:44 AM 9/1/00 -0500, Steve Lord wrote: > >> > > >> > >XFS has additional problems with inode numbers overflowing the >> > >standard 32bit container once the file system its self >goes over 2TB. >> > >> > I was wondering about that. It seem like you should be >able to control >> > this with mkfs.xfs by setting agcont and setting the >> > agsize instead of letting mkfs.xfs set them. I don't >think that many >> people >> > need a file system that can contain a billion files. Just a few >> > hundred million will due. The only down side in doing this >> > is that the inode info may not be splattered across all of >the file system >> > like it would if you used the mkfs.xfs defaults. >> > >> > >> >> >>The problem is not the number of inodes the system will allow >you to create, >>it is where they are created. An XFS inode number is actually >a disk address, >>once the filesystem goes beyond the 2Tbyte limit inodes can >have addresses >>which are beyond this boundary and hence over flow the 32 bit >inode field. >> >>At the moment there is no way of restricting inodes to >specific allocation >>groups, but I suppose it would be possible to do this. In >fact it might be >>a simpler solution than anything else. The consequences are : >> >>1. moving an existing filesystem from Irix will still >potentially leave >> us with inodes beyond the boundary. >> >>2. it will change the distribution of inodes in the >filesystem, which will >> in turn change how data is distributed. There is a danger >that the first >> 2 Tbytes would have to become fairly full and hence >potentially fragmented >> before much data made it into the rest of the filesystem. >This will take >> some thinking about. >> >>Steve >> >> > > >It really is very simple. XFS just the inode shifted down >by the by the log2(number of inodes per disk block)+log(agsize) to find >the ag group that the inode is in. > >The the maxima inode is just: > > agcount<in blocks) > >Inodes on xfs are restricted to a specific allocation group. Each >allocation group can only contain agsize/(inodes per disk >block) inodes. > >For any xfs file system with mkfs.xfs we can choose agcount >and agsize to >insure that that the maxium inode less then 32 bits for any >size of an xfs >file system. > >Like I said the only draw back is that the inode regions will not cover >be spread over all the disk systems which is what mkfs.xfs does by its >chose of agcount and agsize. > >It looks like you should be able to make 16TB xfs file system with lVM, >if LVM really allows you to address 16TB of disk in a partation, >on linux so long as you don't use the mkfs.xfs defaults. > >I could live with that. > >Bill Jones > > From owner-linux-xfs@oss.sgi.com Tue Sep 5 08:26:35 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 08:26:25 -0700 Received: from Cantor.suse.de ([194.112.123.193]:14353 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Tue, 5 Sep 2000 08:26:17 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 778881E37F; Tue, 5 Sep 2000 17:26:15 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 4346110A029; Tue, 5 Sep 2000 17:26:15 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 7634E2F300; Tue, 5 Sep 2000 17:26:14 +0200 (MEST) Date: Tue, 5 Sep 2000 17:26:14 +0200 From: "Andi Kleen" To: "Davida, Joe" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation Message-ID: <20000905172614.A21975@gruyere.muc.suse.de> References: <09D1E9BD9C30D311919200A0C9DD5C2C02536F87@mcaexc01.msj.maxtor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <09D1E9BD9C30D311919200A0C9DD5C2C02536F87@mcaexc01.msj.maxtor.com>; from Joe_Davida@Maxtor.com on Tue, Sep 05, 2000 at 09:18:04AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Sep 05, 2000 at 09:18:04AM -0600, Davida, Joe wrote: > Is what Bill Jones is saying correct? > I am just starting on XFS, and dont > have enough familiarity with it's > architecture. The LVM trick he proposes will not work on current Linux or Linux/XFS (at least not without changes to LVM). So you have a 2TB limit. 1TB may be safer due to possible driver signedness bugs. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 5 08:41:55 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 08:41:46 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:19960 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 08:41:21 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id KAA04437; Tue, 5 Sep 2000 10:41:16 -0500 (CDT) Message-Id: <4.2.0.58.20000905102736.02255a00@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 05 Sep 2000 10:43:32 -0500 To: "Davida, Joe" , "'linux-xfs@oss.sgi.com'" From: "William L. Jones" Subject: RE: 2 Terabyte File System Size Limitation In-Reply-To: <09D1E9BD9C30D311919200A0C9DD5C2C02536F87@mcaexc01.msj.maxt or.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Sigh, It was only speculations! When I tried to specify agcount and agsize mkfs.xfs complained. It will not allow you to change both agcount and agsize at the same time. Given one it choose the other based on the size of the file system. Their is one other nob that can be turned with mkfs.xfs that will allow you to create large file system and keep the inode size smaller then 32 bits. You can increase the size of a inode with mkfs.xfs up to a maxima of 2048 so in theory you could create a file systems up to 16 TB and keep the size of the inodes to the 32 bit linux limit. It turns that the real limitation is the 32 bit scoter offset in the disk drivers. Russell Cattelan has pointed out that LVM acts just like another disk driver so it has the same limitations. I belive that number is 2TB. Bill Jones At 09:18 AM 9/5/00 -0600, Davida, Joe wrote: >Is what Bill Jones is saying correct? >I am just starting on XFS, and dont >have enough familiarity with it's >architecture. > >Cheers, > >Joe > > > >-----Original Message----- > >From: William L. Jones [mailto:jones@tacc.cc.utexas.edu] > >Sent: Friday, September 01, 2000 11:02 AM > >To: Steve Lord; William L. Jones > >Cc: cattelan@thebarn.com; Davida, Joe; 'linux-xfs@oss.sgi.com' > >Subject: Re: 2 Terabyte File System Size Limitation > > > > > >At 11:44 AM 9/1/00 -0500, Steve Lord wrote: > > > >> > > > >> > >XFS has additional problems with inode numbers overflowing the > >> > >standard 32bit container once the file system its self > >goes over 2TB. > >> > > >> > I was wondering about that. It seem like you should be > >able to control > >> > this with mkfs.xfs by setting agcont and setting the > >> > agsize instead of letting mkfs.xfs set them. I don't > >think that many > >> people > >> > need a file system that can contain a billion files. Just a few > >> > hundred million will due. The only down side in doing this > >> > is that the inode info may not be splattered across all of > >the file system > >> > like it would if you used the mkfs.xfs defaults. > >> > > >> > > >> > >> > >>The problem is not the number of inodes the system will allow > >you to create, > >>it is where they are created. An XFS inode number is actually > >a disk address, > >>once the filesystem goes beyond the 2Tbyte limit inodes can > >have addresses > >>which are beyond this boundary and hence over flow the 32 bit > >inode field. > >> > >>At the moment there is no way of restricting inodes to > >specific allocation > >>groups, but I suppose it would be possible to do this. In > >fact it might be > >>a simpler solution than anything else. The consequences are : > >> > >>1. moving an existing filesystem from Irix will still > >potentially leave > >> us with inodes beyond the boundary. > >> > >>2. it will change the distribution of inodes in the > >filesystem, which will > >> in turn change how data is distributed. There is a danger > >that the first > >> 2 Tbytes would have to become fairly full and hence > >potentially fragmented > >> before much data made it into the rest of the filesystem. > >This will take > >> some thinking about. > >> > >>Steve > >> > >> > > > > > >It really is very simple. XFS just the inode shifted down > >by the by the log2(number of inodes per disk block)+log(agsize) to find > >the ag group that the inode is in. > > > >The the maxima inode is just: > > > > agcount< >in blocks) > > > >Inodes on xfs are restricted to a specific allocation group. Each > >allocation group can only contain agsize/(inodes per disk > >block) inodes. > > > >For any xfs file system with mkfs.xfs we can choose agcount > >and agsize to > >insure that that the maxium inode less then 32 bits for any > >size of an xfs > >file system. > > > >Like I said the only draw back is that the inode regions will not cover > >be spread over all the disk systems which is what mkfs.xfs does by its > >chose of agcount and agsize. > > > >It looks like you should be able to make 16TB xfs file system with lVM, > >if LVM really allows you to address 16TB of disk in a partation, > >on linux so long as you don't use the mkfs.xfs defaults. > > > >I could live with that. > > > >Bill Jones > > > > From owner-linux-xfs@oss.sgi.com Tue Sep 5 10:07:56 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 10:07:46 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:64344 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 10:07:37 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA03078 for ; Tue, 5 Sep 2000 09:59:57 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id MAA92303; Tue, 5 Sep 2000 12:05:03 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id MAA74199; Tue, 5 Sep 2000 12:05:03 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id MAA08816; Tue, 5 Sep 2000 12:04:13 -0500 Message-Id: <200009051704.MAA08816@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Andi Kleen" cc: "Davida, Joe" , "'linux-xfs@oss.sgi.com'" Subject: Re: 2 Terabyte File System Size Limitation In-Reply-To: Message from "Andi Kleen" of "Tue, 05 Sep 2000 17:26:14 +0200." <20000905172614.A21975@gruyere.muc.suse.de> Date: Tue, 05 Sep 2000 12:04:08 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Tue, Sep 05, 2000 at 09:18:04AM -0600, Davida, Joe wrote: > > Is what Bill Jones is saying correct? > > I am just starting on XFS, and dont > > have enough familiarity with it's > > architecture. > > The LVM trick he proposes will not work on current Linux > or Linux/XFS (at least not without changes to LVM). So you > have a 2TB limit. 1TB may be safer due to possible > driver signedness bugs. > > > -Andi I think the safest comment to make at the moment is that the path of least resistence to getting above the 2 Tbyte limit is probably a kiobuf enabled version of LVM, this path too has 2 Tbyte limits in it at the moment. ll_rw_block and generic_make_request are the places where the across the volume limit is getting imposed. If we could make it to a remapping request function without having to map a disk address through a 32 bit sector number then it should be doable. The other end of the pipe is the XFS inode number, and I am still not convinced that mkfs options can tune the filesystem to get above the 2 Tbyte boundary, a mount option which restricts inode placement to within the first 2 Tbytes of allocation groups should not be too hard. Steve From owner-linux-xfs@oss.sgi.com Tue Sep 5 11:57:35 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 11:57:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:42757 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 11:56:57 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA21709 for ; Tue, 5 Sep 2000 11:49:16 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA23446 for ; Tue, 5 Sep 2000 13:55:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA02884 for ; Tue, 5 Sep 2000 13:55:38 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA09867; Tue, 5 Sep 2000 13:54:47 -0500 Message-Id: <200009051854.NAA09867@jen.americas.sgi.com> Date: Tue, 5 Sep 2000 13:54:47 -0500 Subject: TAKE - speed up hole filling when writing beyond of file To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Sep 5 11:37:51 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73647a linux/fs/xfs/linux/xfs_lrw.c - 1.54 - Make zero_eof I/O requests async instead of sync - we will still probably end up waiting for one of the pages in here shortly after this, but some cases will get faster. From owner-linux-xfs@oss.sgi.com Tue Sep 5 13:30:26 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 13:30:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58402 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 13:29:59 -0700 Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA05143 for ; Tue, 5 Sep 2000 13:22:18 -0700 (PDT) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.9.3/8.9.3) id KAA04579; Tue, 5 Sep 2000 10:27:15 -0700 Date: Tue, 5 Sep 2000 10:27:15 -0700 From: Ananth Ananthanarayanan Message-Id: <200009051727.KAA04579@waco.engr.sgi.com> Subject: TAKE 800850 - another fix for highmem To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Sep 5 13:27:56 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73669a linux/fs/pagebuf/page_buf.c - 1.30 - Fix highmem problem in end_*_io. This change allows glibc rpm to be built ... From owner-linux-xfs@oss.sgi.com Tue Sep 5 13:31:56 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 13:31:36 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:34595 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 13:31:24 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA05380; Tue, 5 Sep 2000 13:23:44 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA12848; Tue, 5 Sep 2000 13:30:04 -0700 (PDT) Date: Tue, 5 Sep 2000 13:30:04 -0700 (PDT) Message-Id: <200009052030.NAA12848@feature.engr.sgi.com> X-Pv-Incident: 800850 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (ananth@engr.sgi.com) Subject: TAKE 800850 - XFS + CONFIG_HIGHMEM4GB bug To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : dxm *Status : closed Assigned Engineer : nb *Fixed By : ananth *Fixed By Domain : engr *Closed Date : 09/05/00 Priority : 2 *Modified Date : 09/05/00 *Modified User : ananth *Modified User Domain : engr *Fix Description : From: ananth ananthanarayanan (TAKE) Date: Sep 04 2000 06:20:03PM [pvnews version: 1.71] ---------------------------- Date: Mon Sep 4 18:13:03 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs ..... ========================== ADDITIONAL INFORMATION (TAKE) From: ananth ananthanarayanan Date: Sep 05 2000 01:30:04PM [pvnews version: 1.71] ========================== Date: Tue Sep 5 13:27:56 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73669a linux/fs/pagebuf/page_buf.c - 1.30 - Fix highmem problem in end_*_io. This change allows glibc rpm to be built ... Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 04 2000 04:29:01PM ========================== Anath, with your change we get a lot further through a QA run, but eventually end up in kdb during QA 009. Let me know if you need more info or want more tests done on this machine. NMI Watchdog detected LOCKUP on CPU1, registers: CPU: 1 EIP: 0010:[] EFLAGS: 00000086 eax: 00000001 ebx: c2100034 ecx: 00000001 edx: 00000000 esi: f61812c0 edi: f6e677a0 ebp: c2119e04 esp: c2119d64 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c2119000) Stack: c2100010 f61812c0 f6e677a0 c2119d80 00000000 f7970000 00000202 f7ddc980 00000246 f7c7c400 f7b43da0 f79a0000 00000202 00000000 00000001 00000000 00000001 ffffffff 00000246 f79a0000 f7970000 00000013 00000001 00000013 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 80 3b 00 f3 90 7e f9 e9 18 fa f1 ff 80 3d 00 b4 30 c0 00 f3 Entering kdb (0xc2118000) on processor 1 due to WatchDog Interrupt @ 0xc01f7db1 eax = 0x00000001 ebx = 0xc2100034 ecx = 0x00000001 edx = 0x00000000 esi = 0xf61812c0 edi = 0xf6e677a0 esp = 0xc2119d64 eip = 0xc01f7db1 ebp = 0xc2119e04 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000086 ds = 0xf79a0018 es = 0xf79a0018 origeax = 0x00000001 ®s = 0xc2119d30 [1]kdb> bt EBP EIP Function(args) 0xc01f7db1 stext_lock+0x829 kernel .text.lock 0xc01f7588 0xc01f7588 0xc01fd320 0xc2119e04 0xc01177d5 __wake_up+0x55 kernel .text 0xc0100000 0xc0117780 0xc0118040 0xc2119e20 0xf881d307 [pagebuf]_end_pagebuf_page_io+0x127 (0xf6e677a0, 0x1) pagebuf .text 0xf881c060 0xf881d1e0 0xf881d330 0xc2119e34 0xc01307b4 bounce_end_io_write+0x14 (0xf6e24980, 0x1) kernel .text 0xc0100000 0xc01307a0 0xc01307d4 0xc2119e74 0xc01b1956 __scsi_end_request+0xc2 (0xf7c7c400, 0x1, 0x80, 0x1) kernel .text 0xc0100000 0xc01b1894 0xc01b1b78 0xc2119eb4 0xc01b1dbc scsi_io_completion+0x160 (0xf7c7c400, 0x80, 0x1) kernel .text 0xc0100000 0xc01b1c5c 0xc01b1f88 0xc2119ed4 0xc01a3640 rw_intr+0x16c (0xf7c7c400) kernel .text 0xc0100000 0xc01a34d4 0xc01a364c 0xc2119f08 0xc01b4e2b scsi_old_done+0x5bb (0xf7c7c400) kernel .text 0xc0100000 0xc01b4870 0xc01b4e4c 0xc2119f20 0xc01ab9f1 sym53c8xx_intr+0x85 (0x39, 0xf7dbe000, 0xc2119f70, 0x720, 0xc0309f20) kernel .text 0xc0100000 0xc01ab96c 0xc01aba0c 0xc2119f40 0xc010ab39 handle_IRQ_event+0x4d (0x39, 0xc2119f70, 0xf7ddfb00, 0xc01071d0, 0xc2118000) kernel .text 0xc0100000 0xc010aaec 0xc010ab68 0xc2119f68 0xc010ad39 do_IRQ+0x99 (0xc01071d0, 0x0, 0xc2118000, 0xc2118000, 0xc01071d0) kernel .text 0xc0100000 0xc010aca0 0xc010ad8c [1]more> 0xc0109100 ret_from_intr kernel .text 0xc0100000 0xc0109100 0xc0109120 Interrupt registers: eax = 0x00000000 ebx = 0xc01071d0 ecx = 0x00000000 edx = 0xc2118000 esi = 0xc2118000 edi = 0xc01071d0 esp = 0xc2119fa4 eip = 0xc0107200 ebp = 0xc2119fa4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000246 ds = 0xc0100018 es = 0xc2110018 origeax = 0xffffff39 ®s = 0xc2119f70 0xc0107200 default_idle+0x30 kernel .text 0xc0100000 0xc01071d0 0xc0107208 0xc2119fb8 0xc0107272 cpu_idle+0x42 kernel .text 0xc0100000 0xc0107230 0xc0107288 0xc2119fc0 0xc02d4745 start_secondary+0x21 kernel .text.init 0xc02d0000 0xc02d4724 0xc02d474c [1]kdb> cpu 0 Entering kdb (0xc02ce000) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xc02cffd0 0xc0107200 default_idle+0x30 kernel .text 0xc0100000 0xc01071d0 0xc0107208 0xc02cffe4 0xc0107272 cpu_idle+0x42 (0x0) kernel .text 0xc0100000 0xc0107230 0xc0107288 0xc02cfff8 0xc02d0c7f start_kernel+0x18f kernel .text.init 0xc02d0000 0xc02d0af0 0xc02d0c88 (no processes in run state) From owner-linux-xfs@oss.sgi.com Tue Sep 5 15:45:46 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 15:45:36 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32048 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 15:45:23 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA08623 for ; Tue, 5 Sep 2000 15:50:13 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07139; Wed, 6 Sep 2000 09:41:22 +1100 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA16324; Wed, 6 Sep 2000 09:40:34 +1100 (EST) Message-Id: <200009052240.JAA16324@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: krypto cc: linux-xfs@oss.sgi.com Subject: Re: newbie In-reply-to: Your message of "Tue, 05 Sep 2000 13:31:54 +0200." <231379678.20000905133154@elrancho.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Sep 2000 09:40:34 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing krypto writes: => Hi all... => is there anyway (from user space) to crash a => partition, I mean unmount it uncleanly as it => happens when you power off the computer without => unmounting. I would like to unmount uncleanly just => the partition I choose, in order not to crash the => root partition too. You can simulate a crash with "reboot -fn" as root. This will reboot the machine immediately. I've set up my test box so that the root partition is mounted read-only, with symlinks into a ramdisk where all the read-write stuff lives. The ramdisk is initialized on boot. Since the root is mounted read-only I can crash my machine and never need to fsck. I wrote some instructions on how to do this to a redhat box and they're in the xfs crash test directory which is part of the xfs release. YMMV - AFAIK there's no really simple way of getting this configuration going. Regards, ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Sep 5 17:00:36 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 17:00:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:19036 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 17:00:08 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA03580; Tue, 5 Sep 2000 16:52:29 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA35489; Tue, 5 Sep 2000 17:00:05 -0700 (PDT) Date: Tue, 5 Sep 2000 17:00:05 -0700 (PDT) Message-Id: <200009060000.RAA35489@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: REOPEN 800850 - XFS + CONFIG_HIGHMEM4GB bug To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 *Status : open Priority : 2 Assigned Engineer : nb Submitter : dxm Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/03/00 *Closed Date : *Fixed By : *Fixed By Domain : *Verified Date : *Modified User : dxm *Modified User Domain : engr *Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (REOPEN) From: dxm@engr (BugWorks) Date: Sep 05 2000 05:00:05PM ========================== We now fail in QA 013. I've run this test several times this morning, and only seen this bug with CONFIG_HIGHMEM4GB on. Looks like xfs_buf_offset in xfs_itobp is returning NULL. Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: f8973033 *pde = 00000000 Entering kdb (0xf6370000) on processor 0 Panic: Oops due to panic @ 0xf8973033 eax = 0x00000000 ebx = 0xf7587800 ecx = 0x00000000 edx = 0x00000000 esi = 0x00000000 edi = 0x00000000 esp = 0xf6371e7c eip = 0xf8973033 ebp = 0xf6371eb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010282 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xf6371e48 [0]kdb> bt EBP EIP Function(args) 0xf6371eb4 0xf8973033 [xfs]xfs_itobp+0x197 (0xf7587800, 0x0, 0xf6de00a0, 0xf6371f34, 0xf6371f38) xfs .text 0xf8932060 0xf8972e9c 0xf8973124 0xf6371f50 0xf89954fb [xfs]xfs_syncsub+0x6c7 (0xf7587800, 0x31, 0x0, 0x0, 0xf7587800) xfs .text 0xf8932060 0xf8994e34 0xf8995fbc 0xf6371f70 0xf8994e2b [xfs]xfs_sync+0x1b (0xf7587800, 0x31, 0xf89c38a0) xfs .text 0xf8932060 0xf8994e10 0xf8994e34 0xf6371f88 0xf89a975a [xfs]linvfs_write_super+0x2a (0xf7c77000) xfs .text 0xf8932060 0xf89a9730 0xf89a9768 0xf6371f9c 0xc0137898 sync_supers+0x6c (0x0) kernel .text 0xc0100000 0xc013782c 0xc01378c0 0xf6371fb0 0xc0133884 fsync_dev+0x3c (0x0) kernel .text 0xc0100000 0xc0133848 0xc01338dc 0xf6371fbc 0xc01338e6 sys_sync+0xa (0x804ec08, 0x7a40020c, 0x7a40020c, 0x4000ae60, 0xbffffd34) kernel .text 0xc0100000 0xc01338dc 0xc01338ec 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [0]kdb> cpu 1 Entering kdb (0xf78c6000) on processor 1 due to cpu switch [1]kdb> bt EBP EIP Function(args) 0xc01fa2fe stext_lock+0x2d76 kernel .text.lock 0xc01f7588 0xc01f7588 0xc01fd320 0xf78c7f98 0xc01526e4 ext2_sync_file+0x2c (0xf7924d80, 0xf78cf7e0, 0x0, 0xf78c6000) kernel .text 0xc0100000 0xc01526b8 0xc01527c0 0xf78c7fbc 0xc01339f8 sys_fsync+0x54 (0x1, 0xbffff018, 0x0, 0xbffff040, 0x8051b58) kernel .text 0xc0100000 0xc01339a4 0xc0133a1c 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [1]kdb> [1]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command ... 0xf78c6000 00000468 00000001 1 001 run 0xf78c6340*syslogd 0xf791e000 00000477 00000001 0 001 run 0xf791e340 klogd ... 0xf5f7c000 00005071 00005010 0 000 stop 0xf5f7c340 fsstress 0xf6370000 00005072 00005071 1 000 run 0xf6370340 fsstress 0xf6386000 00005073 00005071 0 001 stop 0xf6386340 fsstress 0xf636e000 00005074 00005071 0 000 stop 0xf636e340 fsstress 0xf62f4000 00005075 00005071 0 001 stop 0xf62f4340 fsstress 0xf63b8000 00005076 00005071 0 001 stop 0xf63b8340 fsstress From owner-linux-xfs@oss.sgi.com Tue Sep 5 17:03:07 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 17:02:46 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39735 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 17:02:39 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA05853; Tue, 5 Sep 2000 17:09:11 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA19312; Tue, 5 Sep 2000 17:02:37 -0700 (PDT) Date: Tue, 5 Sep 2000 17:02:37 -0700 (PDT) Message-Id: <200009060002.RAA19312@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: REASSIGN 800850 - XFS + CONFIG_HIGHMEM4GB bug To: ananth@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 Status : open Priority : 2 *Assigned Engineer : ananth *Assigned Domain : engr Submitter : dxm Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/03/00 *Modified User : dxm *Modified User Domain : engr *Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: dxm@engr (BugWorks) Date: Sep 05 2000 05:02:36PM ========================== From owner-linux-xfs@oss.sgi.com Tue Sep 5 17:20:36 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 17:20:17 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:19552 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 17:19:48 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA05587; Tue, 5 Sep 2000 17:12:07 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA70506; Tue, 5 Sep 2000 17:19:15 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA70252; Tue, 5 Sep 2000 17:17:58 -0700 (PDT) Date: Tue, 5 Sep 2000 17:17:58 -0700 (PDT) Message-Id: <200009060017.RAA70252@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: REASSIGN 800850 - XFS + CONFIG_HIGHMEM4GB bug To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 Status : open Priority : 2 *Assigned Engineer : lord *Assigned Domain : sgi.com Submitter : dxm Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/03/00 *Modified User : ananth *Modified User Domain : engr *Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: ananth@engr (BugWorks) Date: Sep 05 2000 05:17:58PM ========================== This looks like a problem Steve should be able to spot easily. Besides, I'll likely break something if I muck with this part of the code ;-) ananth. From owner-linux-xfs@oss.sgi.com Tue Sep 5 17:23:37 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 17:23:17 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:60256 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 17:23:01 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA05946; Tue, 5 Sep 2000 17:15:21 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA59222; Tue, 5 Sep 2000 17:22:59 -0700 (PDT) Date: Tue, 5 Sep 2000 17:22:59 -0700 (PDT) Message-Id: <200009060022.RAA59222@info.engr.sgi.com> X-Pv-Incident: 797457 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: ADD 797457 - Swap deadlock bug To: ananth@engr.sgi.com Cc: linux-xfs@oss.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797457 Status : open Priority : 2 Assigned Engineer : ananth Submitter : ananth *Modified User : ananth *Modified User Domain : engr *Description : In general, the kernel shouldn't be swapping a page from a file on which a write is in progress ... following is a old backtrace but doio-2threads can reproduce the problem at will on a 64MB system. ------------- [1]kdb> btp 569 EBP EIP Function(args) ..... ========================== ADDITIONAL INFORMATION (ADD) From: ananth@engr (BugWorks) Date: Sep 05 2000 05:22:58PM ========================== Following is a workaround for this bug: basically the scheme uses the fact that writepage can return failure in the swapcase. I'll do some more testing and check-in later. ----------- =========================================================================== linux/fs/xfs/linux/xfs_iops.c =========================================================================== 802c802 < int --- > STATIC int 805c805,806 < struct page *page) --- > struct page *page, > int wait) 821a823,825 > if (!wait) > return -EBUSY; > 832a837,852 > int > linvfs_write_full_page_sync( > struct file *filp, > struct page *page) > { > return(linvfs_write_full_page(filp, page, 1)); > } > > int > linvfs_write_full_page_async( > struct file *filp, > struct page *page) > { > return(linvfs_write_full_page(filp, page, 0)); > } > 910c930 < writepage: linvfs_write_full_page, --- > writepage: linvfs_write_full_page_sync, 913a934 > writepage_async: linvfs_write_full_page_async, =========================================================================== linux/include/linux/fs.h =========================================================================== 364a365 > int (*writepage_async)(struct file *, struct page *); =========================================================================== linux/mm/filemap.c =========================================================================== 1592c1592,1605 < return page->mapping->a_ops->writepage(file, page); --- > if (wait) { > return page->mapping->a_ops->writepage(file, page); > } else { > int (*wpf)(struct file *, struct page *); > > /* > * If async write is supported call that > * otherwise use synchronous write. > */ > wpf = page->mapping->a_ops->writepage_async; > if (!wpf) > wpf = page->mapping->a_ops->writepage; > return(wpf(file, page)); > } =========================================================================== linux/mm/vmscan.c =========================================================================== 414c414,419 < if (!ret) --- > /* > * Kludge for XFS: if swap_out's write page > * returned EBUSY due to filesystem locking > * issues, be forgiving. > */ > if (!ret || ret == -EBUSY) ----------------- From owner-linux-xfs@oss.sgi.com Tue Sep 5 20:29:47 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 20:29:27 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:56131 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 20:29:00 -0700 Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA05473 for ; Tue, 5 Sep 2000 20:35:32 -0700 (PDT) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.9.3/8.9.3) id RAA02354; Tue, 5 Sep 2000 17:27:46 -0700 Date: Tue, 5 Sep 2000 17:27:46 -0700 From: Ananth Ananthanarayanan Message-Id: <200009060027.RAA02354@waco.engr.sgi.com> Subject: TAKE 797457 - avoid swap deadlock To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Sep 5 20:26:55 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73739a linux/mm/vmscan.c - 1.35 linux/mm/filemap.c - 1.53 linux/include/linux/fs.h - 1.57 linux/fs/xfs/linux/xfs_iops.c - 1.66 - Workaround for swap deadlock problem. From owner-linux-xfs@oss.sgi.com Tue Sep 5 20:31:47 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 20:31:27 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:60483 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 20:31:22 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA02013; Tue, 5 Sep 2000 20:37:54 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA22980; Tue, 5 Sep 2000 20:30:03 -0700 (PDT) Date: Tue, 5 Sep 2000 20:30:03 -0700 (PDT) Message-Id: <200009060330.UAA22980@feature.engr.sgi.com> X-Pv-Incident: 797457 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (ananth@engr.sgi.com) Subject: TAKE 797457 - Swap deadlock bug To: ananth@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : ananth *Status : closed Assigned Engineer : ananth *Fixed By : ananth *Fixed By Domain : engr *Closed Date : 09/05/00 Priority : 2 *Modified Date : 09/05/00 *Modified User : ananth *Modified User Domain : engr *Fix Description : From: ananth ananthanarayanan (TAKE) Date: Sep 05 2000 08:30:03PM [pvnews version: 1.71] ---------------------------- Date: Tue Sep 5 20:26:55 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73739a linux/mm/vmscan.c - 1.35 linux/mm/filemap.c - 1.53 linux/include/linux/fs.h - 1.57 linux/fs/xfs/linux/xfs_iops.c - 1.66 - Workaround for swap deadlock problem. Description : In general, the kernel shouldn't be swapping a page from a file on which a write is in progress ... following is a old backtrace but doio-2threads can reproduce the problem at will on a 64MB system. ------------- [1]kdb> btp 569 EBP EIP Function(args) ..... ========================== ADDITIONAL INFORMATION (ADD) From: ananth@engr (BugWorks) Date: Sep 05 2000 05:22:58PM ========================== Following is a workaround for this bug: basically the scheme uses the fact that writepage can return failure in the swapcase. I'll do some more testing and check-in later. ----------- =========================================================================== linux/fs/xfs/linux/xfs_iops.c =========================================================================== 802c802 < int --- > STATIC int 805c805,806 < struct page *page) --- > struct page *page, > int wait) 821a823,825 > if (!wait) > return -EBUSY; > 832a837,852 > int > linvfs_write_full_page_sync( > struct file *filp, > struct page *page) > { > return(linvfs_write_full_page(filp, page, 1)); > } > > int > linvfs_write_full_page_async( > struct file *filp, > struct page *page) > { > return(linvfs_write_full_page(filp, page, 0)); > } > 910c930 < writepage: linvfs_write_full_page, --- > writepage: linvfs_write_full_page_sync, 913a934 > writepage_async: linvfs_write_full_page_async, =========================================================================== linux/include/linux/fs.h =========================================================================== 364a365 > int (*writepage_async)(struct file *, struct page *); =========================================================================== linux/mm/filemap.c =========================================================================== 1592c1592,1605 < return page->mapping->a_ops->writepage(file, page); --- > if (wait) { > return page->mapping->a_ops->writepage(file, page); > } else { > int (*wpf)(struct file *, struct page *); > > /* > * If async write is supported call that > * otherwise use synchronous write. > */ > wpf = page->mapping->a_ops->writepage_async; > if (!wpf) > wpf = page->mapping->a_ops->writepage; > return(wpf(file, page)); > } =========================================================================== linux/mm/vmscan.c =========================================================================== 414c414,419 < if (!ret) --- > /* > * Kludge for XFS: if swap_out's write page > * returned EBUSY due to filesystem locking > * issues, be forgiving. > */ > if (!ret || ret == -EBUSY) ----------------- From owner-linux-xfs@oss.sgi.com Tue Sep 5 20:36:17 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 20:35:57 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3908 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 20:35:52 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA05973; Tue, 5 Sep 2000 20:42:24 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA58459; Tue, 5 Sep 2000 20:35:48 -0700 (PDT) Date: Tue, 5 Sep 2000 20:35:48 -0700 (PDT) Message-Id: <200009060335.UAA58459@info.engr.sgi.com> X-Pv-Incident: 800992 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 800992 - pagebuf_init call to kmem_cache_create BUG() To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800992 Submitter : dxm Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : T Priority : 4 Project : xfs-linux Status : open Description : On my test box, I'd been playing with xfs, then umounted, rmmoded and insmoded the modules. When pagebuf was insmoded, this kernel BUG() was tripped. I'll see if I can get some more info on this one. kmem_cache_destroy: Can't free all objects c116d764 kernel BUG at slab.c:806! Entering kdb (0xc215e000) Panic: invalid operand due to panic @ 0xc0125dce eax = 0x0000001a ebx = 0xc116d7c0 ecx = 0xc02a2ccc edx = 0x00000000 esi = 0xc116d7b7 edi = 0xc4813fa2 esp = 0xc215fec0 eip = 0xc0125dce ebp = 0xc215ff00 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xc215fe8c kdb> bt EBP EIP Function(args) 0xc215ff00 0xc0125dce kmem_cache_create+0x35a (0xc4813f97, 0xa0, 0x20, 0x2000, 0x0) kernel .text 0xc0100000 0xc0125a74 0xc0125e18 0xc215ff20 0xc4810657 [pagebuf]pagebuf_init+0x77 (0xc4813fc0) pagebuf .text 0xc480e060 0xc48105e0 0xc4810670 0xc215ff30 0xc48106d3 [pagebuf]init_module+0x13 (0xc215e000, 0x80606d8) pagebuf .text 0xc480e060 0xc48106c0 0xc4810708 0xc215ffbc 0xc0117459 sys_init_module+0x429 (0x805a4d8, 0x807e4d0, 0x80857f0, 0x80606d8, 0xc480e000) kernel .text 0xc0100000 0xc0117030 0xc01174d4 kdb: Bad kernel address 0xc480dffb 0xc0108f08 system_call+0x34 kernel .text 0xc0100000 0xc0108ed4 0xc0108f0c kdb> From owner-linux-xfs@oss.sgi.com Tue Sep 5 20:50:47 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 20:50:37 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42820 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 20:50:23 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA07423 for ; Tue, 5 Sep 2000 20:56:53 -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 OAA52830 for linux-xfs@oss.sgi.com; Wed, 6 Sep 2000 14:47:48 +1100 (EST) Date: Wed, 6 Sep 2000 14:47:48 +1100 (EST) From: Nathan Scott Message-Id: <200009060347.OAA52830@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mkfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Fixes a qa failure from last night: 032 1s ... - output mismatch (see 032.out.bad) 2a3 > Failed - overwrote fs type msdos! Modid: 2.4.0-test1-xfs:slinx:73740a Date: Tue Sep 5 20:45:22 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/mkfs/mountinfo.c - 1.2 cmd/xfs/mkfs/mountinfo.h - 1.2 - sync up with current mount source changes, esp. to detect filesystems of type "msdos" ... caught by test 032. From owner-linux-xfs@oss.sgi.com Tue Sep 5 21:33:18 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 21:33:07 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:34572 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 21:32:46 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA26373 for ; Tue, 5 Sep 2000 21:25:04 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA78947 for linux-xfs@oss.sgi.com; Wed, 6 Sep 2000 15:31:23 +1100 (EST) Date: Wed, 6 Sep 2000 15:31:23 +1100 (EST) From: Daniel Moore Message-Id: <200009060431.PAA78947@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73743a Date: Tue Sep 5 21:31:13 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/check - 1.6 - check TEST_DEV FS consistency before tests and after each test cmd/xfs/stress/common.rc - 1.26 - fix up _check_fs cmd/xfs/stress/group - 1.33 - remove 027 from auto group due to TEST_DEV corruption (temporary) cmd/xfs/stress/soak - 1.2 - working soak test From owner-linux-xfs@oss.sgi.com Tue Sep 5 22:49:08 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 22:48:47 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17992 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 22:48:18 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA06814 for ; Tue, 5 Sep 2000 22:54:48 -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 QAA65234 for linux-xfs@oss.sgi.com; Wed, 6 Sep 2000 16:45:42 +1100 (EST) Date: Wed, 6 Sep 2000 16:45:42 +1100 (EST) From: Nathan Scott Message-Id: <200009060545.QAA65234@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cmds Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Fixes a bunch of compiler warnings in the user tools with -O2 (mostly benign, but a couple in repair were actually bugs) - dump/restore remain to be done. Also, remove silliness in the configure script handling of missing uuid.h. cheers. Modid: 2.4.0-test1-xfs:slinx:73747a Date: Tue Sep 5 22:40:30 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/configure.in - 1.15 - rework logic for dealing with missing uuid.h - die immediately rather than risk a dodgey state check later (fixes: make; install uuid.h; make problem). cmd/xfs/db/check.c - 1.57 cmd/xfs/growfs/xfs_growfs.c - 1.4 - fix compiler warnings with optimization switched on. cmd/xfs/include/libxfs.h - 1.13 cmd/xfs/include/platform_defs.h.in - 1.11 - rework logic for dealing with missing uuid.h. cmd/xfs/libxfs/Makefile - 1.7 - fix compiler warnings with optimization switched on. cmd/xfs/man/man4/xfs.4 - 1.2 - fix obvious (porting) issues. cmd/xfs/mkfs/proto.c - 1.2 cmd/xfs/mkfs/xfs_mkfs.c - 1.175 cmd/xfs/repair/dino_chunks.c - 1.41 cmd/xfs/repair/dinode.c - 1.81 cmd/xfs/repair/dir2.c - 1.14 cmd/xfs/repair/incore_ext.c - 1.21 cmd/xfs/repair/phase2.c - 1.29 cmd/xfs/repair/phase4.c - 1.49 cmd/xfs/repair/phase5.c - 1.43 cmd/xfs/repair/phase6.c - 1.59 cmd/xfs/repair/rt.c - 1.19 cmd/xfs/repair/sb.c - 1.34 - fix compiler warnings with optimization switched on. From owner-linux-xfs@oss.sgi.com Wed Sep 6 06:37:57 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 06:37:48 -0700 Received: from bsd.debis.spb.ru ([195.68.156.134]:16400 "EHLO debis.debis.spb.ru") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 06:37:23 -0700 X-Class: Fast X-Priority: 1 Received: from debis.spb.ru (rsp211.debis.spb.ru [195.68.156.211]) by debis.debis.spb.ru (8.9.3/8.9.1) with ESMTP id RAA26045 for ; Wed, 6 Sep 2000 17:26:32 +0400 (MSD) (envelope-from gdb@debis.spb.ru) Message-ID: <39B648E5.77149AD1@debis.spb.ru> Date: Wed, 06 Sep 2000 17:38:45 +0400 From: Dmitri Gromov X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: linux-XFS: state and perspectives? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, Sorry if it is off-topic, but I can't find _current_ information on the subject. I am interested, if someone can tell, when one can expect production (or beta) linux-XFS to be released? SGI Web site hase some statment from the last spring about end-of-summer, but this seems to be too optimistic. But is the next spring more realistic time? Thanks in advance - Dima Gromov -- Dmitri Gromov, Ph.D. debis Systemhaus, St.Petersburg From owner-linux-xfs@oss.sgi.com Wed Sep 6 08:09:28 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 08:09:18 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:4713 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 08:09:02 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA17135; Wed, 6 Sep 2000 08:01:22 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA97178; Wed, 6 Sep 2000 08:07:15 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA02116; Wed, 6 Sep 2000 08:05:58 -0700 (PDT) Date: Wed, 6 Sep 2000 08:05:58 -0700 (PDT) Message-Id: <200009061505.IAA02116@info.engr.sgi.com> X-Pv-Incident: 800992 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800992 - pagebuf_init call to kmem_cache_create BUG() To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800992 Status : open Priority : 4 Assigned Engineer : dxm Submitter : dxm *Modified User : lord *Modified User Domain : sgi.com *Description : On my test box, I'd been playing with xfs, then umounted, rmmoded and insmoded the modules. When pagebuf was insmoded, this kernel BUG() was tripped. I'll see if I can get some more info on this one. kmem_cache_destroy: Can't free all objects c116d764 kernel BUG at slab.c:806! Entering kdb (0xc215e000) Panic: invalid operand ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 06 2000 08:05:57AM ========================== This BUG in slab.c is a new introduction - this used to function in that it let you reuse a slab name if the old one was still out there. The real problem is that we failed to delete all the old entries in the cache when doing the rmmod of pagebuf. kmem_cache_destroy returns a value - 1 if it failed, 0 if it worked. define PB_TRACKING in page_buf.c and make it call BUG if kmem_cache_destroy returns 1. This will result in a panic where pb_array should be an array of pointers to all existing page_bufs. Turning on page buf tracing might also help determine where the pagebufs came from, although typically this gives you only a very short term history. Determining what is in the remaining pagebufs will certainly help a lot in figuring out the reason for this. From owner-linux-xfs@oss.sgi.com Wed Sep 6 09:45:38 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 09:45:29 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:50698 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 09:45:14 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA01244; Wed, 6 Sep 2000 09:37:34 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA96561; Wed, 6 Sep 2000 09:45:11 -0700 (PDT) Date: Wed, 6 Sep 2000 09:45:11 -0700 (PDT) Message-Id: <200009061645.JAA96561@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800850 - XFS + CONFIG_HIGHMEM4GB bug To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 Status : open Priority : 2 Assigned Engineer : lord Submitter : dxm *Modified User : lord *Modified User Domain : sgi.com *Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 06 2000 09:45:10AM ========================== In theory I though I had dealt with this, in the latest code base, when we ask for a metadata pagebuf, we pass the MAPPABLE flag into pagebuf, this translates into it asking for a page which is not highmem by controlling the gfp_mask passed into alloc_pages. There must be some way we are getting around this, possibly there are some calls getting through without this flag, but I do not see it right now. Also this particular call is not the creation of an inode cluster - i.e. we have used this location as an inode cluster before, if we are recreating the page due to flush activity then it looks like the gfp_mask is not a guarantee - which I doubt. Try with this code in page_buf.c and see if this goes off first: =========================================================================== Index: linux/fs/pagebuf/page_buf.c =========================================================================== --- /usr/tmp/TmpDir.15256-0/linux/fs/pagebuf/page_buf.c_1.30 Wed Sep 6 11:44:53 2000 +++ linux/fs/pagebuf/page_buf.c Wed Sep 6 11:43:33 2000 @@ -573,6 +573,11 @@ all_mapped = 0; continue; } + +if ((flags & PBF_MAPPABLE) && (page_address(cached_page) == NULL)) { + printk("Unexpected highmem page 0x%p\n, cached_page); + BUG(); +} } cp = cached_page; if (add_to_page_cache_unique(cp, From owner-linux-xfs@oss.sgi.com Wed Sep 6 12:50:48 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 12:50:38 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:51266 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 12:50:28 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA28724 for ; Wed, 6 Sep 2000 12:42:48 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA67653 for ; Wed, 6 Sep 2000 14:47:56 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA29131 for ; Wed, 6 Sep 2000 14:47:56 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA18355; Wed, 6 Sep 2000 14:46:55 -0500 Message-Id: <200009061946.OAA18355@jen.americas.sgi.com> Date: Wed, 6 Sep 2000 14:46:55 -0500 Subject: TAKE - fix an external log bug To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This caused problems in log debug code, and probably a number of other issues too. Date: Wed Sep 6 12:47:00 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73794a linux/fs/xfs/xfs_log_recover.c - 1.188 - When removing the block containing the log footer from the external log size, do not remove the size of the iclog, this is the size of an internal memory buffer, not a disk structure. From owner-linux-xfs@oss.sgi.com Wed Sep 6 14:20:30 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 14:20:20 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:63777 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 14:20:08 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA02934; Wed, 6 Sep 2000 14:26:41 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA04156; Wed, 6 Sep 2000 14:20:07 -0700 (PDT) Date: Wed, 6 Sep 2000 14:20:07 -0700 (PDT) Message-Id: <200009062120.OAA04156@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: jen.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: BUG 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Submitter : lord Submitter Domain : sgi.com Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 realtime =none extsz=65536 blocks=0, rtextents=0 mkfs.xfs: write failed: No space left on device The sequence of events was as follows: 1. mounted partition as xfs, ran some tests, unmounted 2. mkfs as ext2 using e2fsprogs-1.18-5 based commands 3. mount as ext2 and run some tests, unmount 4. do mkfs as xfs and fail. This happens with top of trunk code and it is the write into the last block of the device which fails. fdisk says this about the device partition table: Device Boot Start End Blocks Id System /dev/sda1 * 1 66 530113+ 83 Linux /dev/sda2 67 83 136552+ 82 Linux swap /dev/sda3 84 512 3445942+ 83 Linux /dev/sda4 513 1106 4771305 83 Linux sda4 is the target. Here is the strace output from the failure: _llseek(4, 4885815296, [4885815296], SEEK_SET) = 0 write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = -1 ENOSPC (No space left on device) From owner-linux-xfs@oss.sgi.com Wed Sep 6 14:26:49 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 14:26:30 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:34082 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 14:26:22 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07267; Wed, 6 Sep 2000 14:32:54 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA50259; Wed, 6 Sep 2000 14:25:03 -0700 (PDT) Date: Wed, 6 Sep 2000 14:25:03 -0700 (PDT) Message-Id: <200009062125.OAA50259@feature.engr.sgi.com> X-Pv-Incident: 801063 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (nb@sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 09/06/00 *Modified User : nb *Modified User Domain : sgi.com *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: neil bannister Date: Sep 06 2000 02:25:03PM [pvnews version: 1.71] ========================== Hello, I will be out of the office from 09/07 onwards and back in the office 09/18. In my abscence please contaact Troy McCorkell @ vnet 233-5760 or 651-683-5760 or tdm@sgi.com. Thanks Neil Bannister From owner-linux-xfs@oss.sgi.com Wed Sep 6 14:31:30 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 14:31:19 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59426 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 14:31:06 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA08887; Wed, 6 Sep 2000 14:37:39 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA90985; Wed, 6 Sep 2000 14:31:05 -0700 (PDT) Date: Wed, 6 Sep 2000 14:31:05 -0700 (PDT) Message-Id: <200009062131.OAA90985@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: REASSIGN 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Status : open Priority : 3 *Assigned Engineer : nathans *Assigned Domain : engr Submitter : lord Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/06/00 *Modified User : lord *Modified User Domain : sgi.com *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Sep 06 2000 02:31:04PM ========================== Arbitrarily sending this Nathan's way. From owner-linux-xfs@oss.sgi.com Wed Sep 6 14:33:50 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 14:33:30 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:27748 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 14:33:18 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA13768; Wed, 6 Sep 2000 14:25:38 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA98555; Wed, 6 Sep 2000 14:33:15 -0700 (PDT) Date: Wed, 6 Sep 2000 14:33:15 -0700 (PDT) Message-Id: <200009062133.OAA98555@info.engr.sgi.com> X-Pv-Incident: 801066 webPV: jen.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: BUG 801066 - Extra unneeded endian flipping in XFS code To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801066 Submitter : lord Submitter Domain : sgi.com Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : Capturing some old email state into a PV I was digging through the code trying to figure out why the power pc is getting zero inode numbers and I came across this code in xfs_inobt_get_rec INT_SET(*ino, arch, INT_GET(rec->ir_startino, ARCH_CONVERT)); INT_SET(*fcnt, arch, INT_GET(rec->ir_freecount, ARCH_CONVERT)); INT_SET(*free, arch, INT_GET(rec->ir_free, ARCH_CONVERT)); Places like xfs_dialloc are calling xfs_inobt_get_rec() several times with ARCH_CONVERT in the arguments, and the proceeding to always use statements like INT_GET(rec.ir_freecount, ARCH_CONVERT) to extract fields from the results. I think we could just skip all the conversion in this case, in fact I was hard pressed to find a call to xfs_inobt_get_rec where the output was ever used as metadata, it always appeared to be a local variable which was always converted again before being used. xfs_difree appears to go through even more gyrations. Am I missing something, or are we just byte swapping for the fun of it in these functions? => Yes, I think so. Daniel knows more about this than I, but I think => this may have been left in so we knew all the places that had been => touched by endian work in case there was further work to be done => later (i.e. if we didn't go the non-bigendian-only route). => => We should go through and remove all these (I think) - Daniel has => scripts for finding this sort of thing, so I'll leave it for him => to qualify further/fix. He's also not in this morning, so it may => be a little while. Well not for fun as such - more out of force of habit. A lot of these cases exist because the code was converted automagically, and a lot because the sizes of the types is non-obvious. I actually wrote another script to remove all the INT_SET(x, ARCH_CONVERT, INT_GET(y, ARCH_CONVERT)) from the code, but this is actually quite dangerous because the macros _are_ needed if x & y are different sized types. We probably need is to make a new macro which copies disk-endian values between variables, doing the conversions if the sizes are different. From owner-linux-xfs@oss.sgi.com Wed Sep 6 14:50:21 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 14:50:01 -0700 Received: from smtp1.cern.ch ([137.138.128.38]:61190 "EHLO smtp1.cern.ch") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 14:49:51 -0700 Received: from pcrd10.cern.ch (pcrd10.cern.ch [137.138.29.237]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id WAA21921; Wed, 6 Sep 2000 22:48:27 +0200 (MET DST) Received: (from fuji@localhost) by pcrd10.cern.ch (8.9.3/8.9.3) id WAA16124; Wed, 6 Sep 2000 22:47:53 +0200 Date: Wed, 6 Sep 2000 22:47:53 +0200 From: Peter.Kelemen@cern.ch To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: xfs_repair dumps core on damaged filesystem (was: Re: XFS assertion failed: vp->v_bh.bh_first != NULL) Message-ID: <20000906224753.A16092@pcrd10.cern.ch> Reply-To: Peter.Kelemen@cern.ch References: <20000903211728.C3797@pcrd10.cern.ch> <17574.968018229@ocs3.ocs-net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i X-Beat: @908 In-Reply-To: <17574.968018229@ocs3.ocs-net>; from kaos@melbourne.sgi.com on Mon, Sep 04, 2000 at 08:57:09AM +1100 Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --azLHFNyN32YCQGCU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, 2000-09-04 08:57:09 +1100, Keith Owens wrote: > klogd has got in first and stamped on the trace, got it wrong > and left no useful trace data for ksymoops. Geez. I noticed it too late. Meanwhile I hit another nice one while trying to reproduce the vnode-crash. The kernel crashed so badly that syslogd/klogd didn't have time to log the oops---no console copy either since a reboot occured. What I could recover from the filesystem follows: Sep 6 19:17:56 pcrd18 kernel: XFS assertion failed:xfs_bmbt_get_startoff(r1) + xfs_bmbt_get_blockcount(r1) <= xfs_bmbt_get_startoff(r2), file: xfs_btree.c, line: 300 Sep 6 19:17:57 pcrd18 kernel: kernel BUG at xfs_debug.c:50! Sep 6 19:17:57 pcrd18 kernel: invalid operand: 0000 Sep 6 19:17:57 pcrd18 kernel: CPU: 1 ...and that's it. After reboot, the kernel was able to mount the (obviously) damaged XFS filesystem, but running xfs_repair dumped core (backtrace attached). Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gdb.xfs_repair" [root@pcrd18 repair]# ldd xfs_repair libc.so.6 => /lib/libc.so.6 (0x40015000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [root@pcrd18 repair]# gdb -c /root/core.xfs_repair.20000906 /usr/sbin/xfs_repair GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `xfs_repair -V /dev/hdc1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x808e60e in scanfunc_bmap (ablock=0x819a280, level=1, type=5, whichfork=0, bno=3669497, ino=148, tot=0xbffff7f8, nex=0xbffff7cc, blkmapp=0xbffff7a8, bm_cursor=0xbffff584, isroot=1, check_dups=0, dirty=0xbffff4e8) at scan.c:457 457 bm_cursor->level[level].last_key = (gdb) bt #0 0x808e60e in scanfunc_bmap (ablock=0x819a280, level=1, type=5, whichfork=0, bno=3669497, ino=148, tot=0xbffff7f8, nex=0xbffff7cc, blkmapp=0xbffff7a8, bm_cursor=0xbffff584, isroot=1, check_dups=0, dirty=0xbffff4e8) at scan.c:457 #1 0x808c505 in scan_lbtree (root=3669497, nlevels=2, func=0x808c57c , type=5, whichfork=0, ino=148, tot=0xbffff7f8, nex=0xbffff7cc, blkmapp=0xbffff7a8, bm_cursor=0xbffff584, isroot=1, check_dups=0) at scan.c:131 #2 0x8059e8c in process_btinode (mp=0xbffffa94, agno=0, ino=148, dip=0x8197660, type=5, dirty=0xbffff968, tot=0xbffff7f8, nex=0xbffff7cc, blkmapp=0xbffff7a8, whichfork=0, check_dups=0) at dinode.c:1194 #3 0x805db97 in process_dinode_int (mp=0xbffffa94, dino=0x8197660, agno=0, ino=148, was_free=0, dirty=0xbffff968, cleared=0xbffff950, used=0xbffff974, verify_mode=0, uncertain=0, ino_discovery=0, check_dups=1, extra_attr_check=0, isa_dir=0xbffff94c, parent=0xbffff98c) at dinode.c:2355 #4 0x805f4e1 in process_dinode (mp=0xbffffa94, dino=0x8197660, agno=0, ino=148, was_free=0, dirty=0xbffff968, cleared=0xbffff950, used=0xbffff974, ino_discovery=0, check_dups=1, extra_attr_check=0, isa_dir=0xbffff94c, parent=0xbffff98c) at dinode.c:2856 #5 0x8053da4 in process_inode_chunk (mp=0xbffffa94, agno=0, num_inos=64, first_irec=0x8161ff4, ino_discovery=0, check_dups=1, extra_attr_check=0, bogus=0xbffff9c8) at dino_chunks.c:738 #6 0x8055655 in process_aginodes (mp=0xbffffa94, agno=0, ino_discovery=0, check_dups=1, extra_attr_check=0) at dino_chunks.c:952 #7 0x8077af6 in phase4 (mp=0xbffffa94) at phase4.c:1310 #8 0x8093c75 in main (argc=3, argv=0xbffffd64) at xfs_repair.c:487 (gdb) --azLHFNyN32YCQGCU-- From owner-linux-xfs@oss.sgi.com Wed Sep 6 15:32:12 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 15:31:52 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17780 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 15:31:30 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA21919 for ; Wed, 6 Sep 2000 15:23:49 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id RAA97793; Wed, 6 Sep 2000 17:30:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id RAA85355; Wed, 6 Sep 2000 17:30:11 -0500 (CDT) From: Steve Lord Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id RAA25306; Wed, 6 Sep 2000 17:29:09 -0500 Message-Id: <200009062229.RAA25306@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Peter.Kelemen@cern.ch Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair dumps core on damaged filesystem (was: Re: XFS assertion failed: vp->v_bh.bh_first != NULL) In-reply-to: Your message of "Wed, 06 Sep 2000 22:47:53 +0200 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Wed, 06 Sep 2000 17:29:09 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing What sort of load were you putting on the system, also what is your configuration : memory disks used for XFS cpus Could you also run xfs_growfs -n /xxx where /xxx is the mount point of the filesystem in question. This will dump out some filesystem parameters. I would like to be able to duplicate this crash, or at least establish if it is a setup which we know has problems. The vnode crash is being worked on, all I have managed to do so far is make it harder to hit. It is basically top of the list at the moment. The repair problem looks related to an already reported problem. Thanks for trying XFS! Steve > = > --azLHFNyN32YCQGCU > Content-Type: text/plain; charset=3Diso-8859-1 > Content-Disposition: inline > Content-Transfer-Encoding: 8bit > = > On Mon, 2000-09-04 08:57:09 +1100, Keith Owens wrote: > = > > klogd has got in first and stamped on the trace, got it wrong > > and left no useful trace data for ksymoops. > = > Geez. I noticed it too late. Meanwhile I hit another nice one > while trying to reproduce the vnode-crash. The kernel crashed so > badly that syslogd/klogd didn't have time to log the oops---no > console copy either since a reboot occured. What I could recover > from the filesystem follows: > = > Sep 6 19:17:56 pcrd18 kernel: XFS assertion failed:xfs_bmbt_get_starto= ff(r1) + xfs_bmbt_get_blockcount(r1) <=3D > xfs_bmbt_get_startoff(r2), file: xfs_btree.c, line: 300 > Sep 6 19:17:57 pcrd18 kernel: kernel BUG at xfs_debug.c:50! > Sep 6 19:17:57 pcrd18 kernel: invalid operand: 0000 > Sep 6 19:17:57 pcrd18 kernel: CPU: 1 > = > ...and that's it. After reboot, the kernel was able to mount the > (obviously) damaged XFS filesystem, but running xfs_repair dumped > core (backtrace attached). > = > Peter > = > -- = > .+'''+. .+'''+. .+'''+. .+'''+. .+'= ' > Kelemen P=E9ter / \ / \ Peter.Kelemen@cern.c= h > .+' `+...+' `+...+' `+...+' `+...+' > = > --azLHFNyN32YCQGCU > Content-Type: text/plain; charset=3Dus-ascii > Content-Disposition: attachment; filename=3D"gdb.xfs_repair" > = > [root@pcrd18 repair]# ldd xfs_repair > libc.so.6 =3D> /lib/libc.so.6 (0x40015000) > /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000) > [root@pcrd18 repair]# gdb -c /root/core.xfs_repair.20000906 /usr/sbin/x= fs_rep air > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and yo= u are > welcome to change it and/or distribute copies of it under certain condi= tions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > This GDB was configured as "i386-redhat-linux"... > Core was generated by `xfs_repair -V /dev/hdc1'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libc.so.6...done. > Reading symbols from /lib/ld-linux.so.2...done. > #0 0x808e60e in scanfunc_bmap (ablock=3D0x819a280, level=3D1, type=3D5= , whichfork=3D 0, bno=3D3669497, ino=3D148, tot=3D0xbffff7f8, > nex=3D0xbffff7cc, blkmapp=3D0xbffff7a8, bm_cursor=3D0xbffff584, isr= oot=3D1, check _dups=3D0, dirty=3D0xbffff4e8) at scan.c:457 > 457 bm_cursor->level[level].last_key =3D > (gdb) bt > #0 0x808e60e in scanfunc_bmap (ablock=3D0x819a280, level=3D1, type=3D5= , whichfork=3D 0, bno=3D3669497, ino=3D148, tot=3D0xbffff7f8, > nex=3D0xbffff7cc, blkmapp=3D0xbffff7a8, bm_cursor=3D0xbffff584, isr= oot=3D1, check _dups=3D0, dirty=3D0xbffff4e8) at scan.c:457 > #1 0x808c505 in scan_lbtree (root=3D3669497, nlevels=3D2, func=3D0x808= c57c , type=3D5, whichfork=3D0, ino=3D148, > tot=3D0xbffff7f8, nex=3D0xbffff7cc, blkmapp=3D0xbffff7a8, bm_cursor= =3D0xbffff584, isroot=3D1, check_dups=3D0) at scan.c:131 > #2 0x8059e8c in process_btinode (mp=3D0xbffffa94, agno=3D0, ino=3D148,= dip=3D0x81976 60, type=3D5, dirty=3D0xbffff968, tot=3D0xbffff7f8, > nex=3D0xbffff7cc, blkmapp=3D0xbffff7a8, whichfork=3D0, check_dups=3D= 0) at dinode. c:1194 > #3 0x805db97 in process_dinode_int (mp=3D0xbffffa94, dino=3D0x8197660,= agno=3D0, i no=3D148, was_free=3D0, dirty=3D0xbffff968, > cleared=3D0xbffff950, used=3D0xbffff974, verify_mode=3D0, uncertain= =3D0, ino_disc overy=3D0, check_dups=3D1, extra_attr_check=3D0, > isa_dir=3D0xbffff94c, parent=3D0xbffff98c) at dinode.c:2355 > #4 0x805f4e1 in process_dinode (mp=3D0xbffffa94, dino=3D0x8197660, agn= o=3D0, ino=3D1 48, was_free=3D0, dirty=3D0xbffff968, cleared=3D0xbffff950, > used=3D0xbffff974, ino_discovery=3D0, check_dups=3D1, extra_attr_ch= eck=3D0, isa_d ir=3D0xbffff94c, parent=3D0xbffff98c) at dinode.c:2856 > #5 0x8053da4 in process_inode_chunk (mp=3D0xbffffa94, agno=3D0, num_in= os=3D64, fir st_irec=3D0x8161ff4, ino_discovery=3D0, check_dups=3D1, > extra_attr_check=3D0, bogus=3D0xbffff9c8) at dino_chunks.c:738 > #6 0x8055655 in process_aginodes (mp=3D0xbffffa94, agno=3D0, ino_disco= very=3D0, ch eck_dups=3D1, extra_attr_check=3D0) at dino_chunks.c:952 > #7 0x8077af6 in phase4 (mp=3D0xbffffa94) at phase4.c:1310 > #8 0x8093c75 in main (argc=3D3, argv=3D0xbffffd64) at xfs_repair.c:487= > (gdb) > = > --azLHFNyN32YCQGCU-- From owner-linux-xfs@oss.sgi.com Wed Sep 6 15:33:22 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 15:33:12 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:41844 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 15:32:50 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA22143 for ; Wed, 6 Sep 2000 15:25:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id RAA97030; Wed, 6 Sep 2000 17:31:31 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id RAA06479; Wed, 6 Sep 2000 17:31:29 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id RAA25317; Wed, 6 Sep 2000 17:30:27 -0500 Message-Id: <200009062230.RAA25317@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dmitri Gromov cc: linux-xfs@oss.sgi.com Subject: Re: linux-XFS: state and perspectives? In-Reply-To: Message from Dmitri Gromov of "Wed, 06 Sep 2000 17:38:45 +0400." <39B648E5.77149AD1@debis.spb.ru> Date: Wed, 06 Sep 2000 17:30:27 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hello, > > Sorry if it is off-topic, but I can't find _current_ information on the > subject. I am interested, if someone can tell, when one can expect > production (or beta) linux-XFS to be released? SGI Web site hase some > statment from the last spring about end-of-summer, but this seems to be > too optimistic. But is the next spring more realistic time? > > Thanks in advance - > Dima Gromov > -- > Dmitri Gromov, Ph.D. > debis Systemhaus, St.Petersburg No next spring is way too late. We are currently trying to nail down 3 or 4 bugs, at which point, unless something else comes up in testing, we are going to call it a beta. There will be caveats about what is known not to work, and what has not been tested, but we are pretty close now. Current thinking is that we will continue to fix problems as they come up, and continue to pare down the caveats and to complete the XFS feature set. The beta will stick with the 2.4.0-test5 kernel base for now, we do not want to introduce the variables of bumping kernel versions every few weeks at the moment. We have two parallel (and slightly conflicting) goals here. One is to eventually get XFS into the main Linux tree, probably a post 2.4 thing, since we perturb too much out side of xfs itself. The other is to produce something useable as part of SGI Linux based hardware products. Steve From owner-linux-xfs@oss.sgi.com Wed Sep 6 16:04:52 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 16:04:42 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:20092 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 16:04:20 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA26097; Wed, 6 Sep 2000 15:56:40 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA08920; Wed, 6 Sep 2000 16:03:49 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA57291; Wed, 6 Sep 2000 16:02:31 -0700 (PDT) Date: Wed, 6 Sep 2000 16:02:31 -0700 (PDT) Message-Id: <200009062302.QAA57291@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Status : open Priority : 3 Assigned Engineer : nathans Submitter : lord *Modified User : nathans *Modified User Domain : engr *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Sep 06 2000 04:02:31PM ========================== Hi Steve, Tried in vain a couple of times to produce this locally... can you send me the entire strace output from the failed run (if you still have it or can easily reproduce it?) The two most interesting things would be the result from the BLKGETSIZE ioctl and the line in xfs_mkfs.c where the writebuf fails (ltrace might help here, if you have that installed?). Also - has this volume ever had lvm stuff on it? (i.e. is the BLKGETSIZE gonna be answered by the lvm or the sd driver?) Once upon a time I saw mkfs on an lvm device fail like this but could never reproduce it (I was doing initial libxfs stuff at the time, so assumed I'd messed up somehow...) cheers. From owner-linux-xfs@oss.sgi.com Wed Sep 6 16:38:52 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 16:38:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38190 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 16:38:23 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA07894 for ; Wed, 6 Sep 2000 16:44:54 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA17354; Thu, 7 Sep 2000 10:37:03 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA05836; Thu, 7 Sep 2000 10:37:01 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009071037.ZM5823@wobbly.melbourne.sgi.com> Date: Thu, 7 Sep 2000 10:36:59 -0400 In-Reply-To: Steve Lord "Re: xfs_repair dumps core on damaged filesystem (was: Re: XFS assertion failed: vp->v_bh.bh_first != NULL)" (Sep 6, 5:29pm) References: <200009062229.RAA25306@jen.americas.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Peter.Kelemen@cern.ch Subject: Re: xfs_repair dumps core on damaged filesystem (was: Re: XFS assertion failed: vp->v_bh.bh_first != NULL) Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Sep 6, 5:29pm, Steve Lord wrote: > Subject: Re: xfs_repair dumps core on damaged filesystem > ... > I would like to be able to duplicate this crash, or at least establish > if it is a setup which we know has problems. > ... > The repair problem looks related to an already reported problem. > I think this is actually subtely different, although from the stack trace they do look very similar. That other bug (800752) seems to have been fixed in recent checkins - the QA test which previously tripped it every time no longer does. > > > > Sep 6 19:17:56 pcrd18 kernel: XFS assertion failed:xfs_bmbt_get_startoff(r1) > + xfs_bmbt_get_blockcount(r1) <= > > xfs_bmbt_get_startoff(r2), file: xfs_btree.c, line: 300 This is interesting - xfs_repair falls over in a place which also manipulates these same data structures, so I suspect repair may be making some assumptions about the ondisk data here... > > #0 0x808e60e in scanfunc_bmap (ablock=0x819a280, level=1, type=5, whichfork= > 0, bno=3669497, ino=148, tot=0xbffff7f8, > > nex=0xbffff7cc, blkmapp=0xbffff7a8, bm_cursor=0xbffff584, isroot=1, check > _dups=0, dirty=0xbffff4e8) at scan.c:457 > > 457 bm_cursor->level[level].last_key = > > (gdb) bt > > #0 0x808e60e in scanfunc_bmap (ablock=0x819a280, level=1, type=5, whichfork= > 0, bno=3669497, ino=148, tot=0xbffff7f8, > > nex=0xbffff7cc, blkmapp=0xbffff7a8, bm_cursor=0xbffff584, isroot=1, check > _dups=0, dirty=0xbffff4e8) at scan.c:457 /* * update cursor keys to reflect this block */ if (check_dups == 0) { bm_cursor->level[level].first_key = INT_GET(pkey[0].br_startoff, ARCH_CONVERT); bm_cursor->level[level].last_key = INT_GET(pkey[block->bb_numrecs-1].br_startoff, ARCH_CONVERT); } hmm - assuming my source matches Peters, its the second assignment (scan.c, line 457) there which is unhealthy. Peter, any chance you could tar+gzip the core file & repair binary and mail them to me? -- taa. Also, if you still have the bad filesystem handy, could you use xfs_db and dump out everything you can about inode 148 and send that to me too? That would be something like: # xfs_db -r /dev/hdc1 xfs_db: inode 148 xfs_db: print xfs_db: addr u.bmbt.ptrs[1] xfs_db: print ... to start with. Finally, "xfs_repair -n /dev/hdc1" output might help me too. (thats alot of stuff, could you send it just to me & not the list...) many thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Sep 6 17:47:03 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 17:46:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20786 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 17:46:35 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA01542; Wed, 6 Sep 2000 17:53:08 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA20116; Wed, 6 Sep 2000 17:46:33 -0700 (PDT) Date: Wed, 6 Sep 2000 17:46:33 -0700 (PDT) Message-Id: <200009070046.RAA20116@info.engr.sgi.com> X-Pv-Incident: 801095 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 801095 - xfs_repair sucks memory in phase7 To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801095 Submitter : dxm Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : xfs_repair -n phase7 seems to leak memory big time, chewing up over 100Mb on sagan and causing processes to get nuked. From owner-linux-xfs@oss.sgi.com Wed Sep 6 20:57:14 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 20:57:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:4146 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 20:56:44 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA21508; Wed, 6 Sep 2000 20:49:03 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA10892; Wed, 6 Sep 2000 20:56:41 -0700 (PDT) Date: Wed, 6 Sep 2000 20:56:41 -0700 (PDT) Message-Id: <200009070356.UAA10892@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Status : open Priority : 3 Assigned Engineer : nathans Submitter : lord *Modified User : nathans *Modified User Domain : engr *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Sep 06 2000 08:56:40PM ========================== Steve, Are you using tools built with -DDEBUG defined? There's an ASSERT in libxfs/rdwr.c, line 248, which I would have expected to have been tripped here ... a core file would be quite handy to diagnose this. I've added a couple more asserts (around lseeks) as well now, just in case. If you see this again & you get a good dump, pls send me a pointer to the binary & core file - I haven't been able to reproduce it at all. Seeing all the zeroes in the strace write line, I'd guess we're failing at one of (in xfs_mkfs.c): - line 1804 (touch last block, make fs the right size if it's a file) OR - line 1813 (splat a bunch of zeroes over the last potential EFS SB) this second one could probably be removed anyway? BUT, from your fdisk & strace output, we seek to byte offset: 4885815296 ( / 1024 = 4771304 blocks ) + fdisk tells us we have 4771305 blocks on sda4, + strace tells us we're writing 512 bytes, and that the lseek to the start of block 4771304 didn't fail; ... which all seems very much above board to me, so at the moment I'd suspect a driver bug (maybe an off by one somewhere?) causing a bad errno to be returned from the kernel. cheers. From owner-linux-xfs@oss.sgi.com Wed Sep 6 21:47:14 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 21:46:55 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17464 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 21:46:22 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA24829; Wed, 6 Sep 2000 21:38:43 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id VAA60327; Wed, 6 Sep 2000 21:45:04 -0700 (PDT) Date: Wed, 6 Sep 2000 21:45:04 -0700 (PDT) Message-Id: <200009070445.VAA60327@feature.engr.sgi.com> X-Pv-Incident: 801063 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (lord@sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord Status : open Assigned Engineer : nathans Priority : 3 *Modified Date : 09/06/00 *Modified User : lord *Modified User Domain : sgi.com *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: steve lord Date: Sep 06 2000 09:45:03PM [pvnews version: 1.71] ========================== > > Steve, > > Are you using tools built with -DDEBUG defined? > > There's an ASSERT in libxfs/rdwr.c, line 248, which I would have > expected to have been tripped here ... a core file would be quite > handy to diagnose this. I've added a couple more asserts (around > lseeks) as well now, just in case. > I don't think I am. I will try again with a debug version, I have hit this a few times, it might be specific to partition layout on my machine. Also, the strace output might still be there, or I can recreate, ltrace is a good idea, I forgot about that. From owner-linux-xfs@oss.sgi.com Wed Sep 6 21:48:45 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 21:48:25 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22332 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 21:48:09 -0700 Received: from kao1.melbourne.sgi.com (kao1.melbourne.sgi.com [134.14.55.179]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA01608 for ; Wed, 6 Sep 2000 21:54:41 -0700 (PDT) mail_from (kaos@kao1.melbourne.sgi.com) Received: (from kaos@localhost) by kao1.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA12342; Thu, 7 Sep 2000 15:46:51 +1100 (EST) Date: Thu, 7 Sep 2000 15:46:51 +1100 (EST) From: Keith Owens Message-Id: <200009070446.PAA12342@kao1.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE - kdb for XFS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Back port kdb fixes from 2.4.0-test8-pre5 Modid: 2.4.0-test1-xfs:slinx:73869a Date: Wed Sep 6 21:44:24 PDT 2000 Workarea: kao1.melbourne.sgi.com:/hosts/sherman/home/kaos/isms/slinx/2.4.0-test1-xfs Author: kaos The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/arch/i386/kdb/kdba_io.c - 1.6 linux/arch/i386/kdb/kdbasupport.c - 1.8 linux/include/linux/kdb.h - 1.7 linux/kdb/kdbmain.c - 1.9 linux/mm/vmalloc.c - 1.19 From owner-linux-xfs@oss.sgi.com Wed Sep 6 23:23:34 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 23:23:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:1605 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 23:22:51 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA01609; Wed, 6 Sep 2000 23:15:10 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA14089; Wed, 6 Sep 2000 23:22:48 -0700 (PDT) Date: Wed, 6 Sep 2000 23:22:48 -0700 (PDT) Message-Id: <200009070622.XAA14089@info.engr.sgi.com> X-Pv-Incident: 801066 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 801066 - Extra unneeded endian flipping in XFS code To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801066 Status : open Priority : 3 Assigned Engineer : dxm Submitter : lord *Modified User : nathans *Modified User Domain : engr *Description : Capturing some old email state into a PV I was digging through the code trying to figure out why the power pc is getting zero inode numbers and I came across this code in xfs_inobt_get_rec INT_SET(*ino, arch, INT_GET(rec->ir_startino, ARCH_CONVERT)); INT_SET(*fcnt, arch, INT_GET(rec->ir_freecount, ARCH_CONVERT)); INT_SET(*free, arch, INT_GET(rec->ir_free, ARCH_CONVERT)); Places like xfs_dialloc are calling xfs_inobt_get_rec() several times with ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Sep 06 2000 11:22:47PM ========================== Could you also look into fixing the compiler warnings which the endian macros sometimes generate when you get round to this one, Daniel? The warnings are of the form (e.g. from xfs_repair): attr_repair.c:268: warning: value computed is not used and dino_chunks.c:205: warning: left-hand operand of comma expression has no effect We'd only be a hop, skip & a jump away from a clean user tool build then... taa. From owner-linux-xfs@oss.sgi.com Wed Sep 6 23:57:05 2000 Received: by oss.sgi.com id ; Wed, 6 Sep 2000 23:56:45 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4417 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 6 Sep 2000 23:56:21 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA01861 for ; Thu, 7 Sep 2000 00:02:53 -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 RAA49191 for linux-xfs@oss.sgi.com; Thu, 7 Sep 2000 17:55:02 +1100 (EST) Date: Thu, 7 Sep 2000 17:55:02 +1100 (EST) From: Nathan Scott Message-Id: <200009070655.RAA49191@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - sim Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I've removed cmd/xfs/sim from the tree, and any pseudo-inc headers still depending on it. Also did a little cleaning of pseudo-inc to remove the sim dependencies still there. The remaining de-SIMing work (kernel, lots) will have to wait till after the beta starts, in the interests of code stability (not that anything should break). cheers. Modid: 2.4.0-test1-xfs:slinx:73871a Date: Wed Sep 6 23:52:23 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/pseudo-inc/sys/debug.h - 1.6 linux/fs/xfs/pseudo-inc/sys/file.h - 1.3 linux/fs/xfs/pseudo-inc/sys/kmem.h - 1.10 linux/fs/xfs/pseudo-inc/sys/param.h - 1.10 linux/fs/xfs/pseudo-inc/sys/sysmacros.h - 1.6 linux/fs/xfs/pseudo-inc/sys/systm.h - 1.8 linux/fs/xfs/pseudo-inc/sys/types.h - 1.19 linux/fs/xfs/pseudo-inc/sys/uio.h - 1.11 linux/fs/xfs/pseudo-inc/sys/uuid.h - 1.8 linux/fs/xfs/pseudo-inc/sys/vfs.h - 1.13 linux/fs/xfs/pseudo-inc/sys/vnode.h - 1.29 linux/fs/xfs/xfs_rw.c - 1.325 linux/fs/xfs/xfs_vfsops.c - 1.286 linux/fs/xfs/xfs_vnodeops.c - 1.472 - cleanse sim remnants, minor tidying, remove dead code/types/#defines. From owner-linux-xfs@oss.sgi.com Thu Sep 7 00:22:05 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 00:21:55 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:63819 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 00:21:40 -0700 Received: from kao1.melbourne.sgi.com (kao1.melbourne.sgi.com [134.14.55.179]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA05233 for ; Thu, 7 Sep 2000 00:13:59 -0700 (PDT) mail_from (kaos@kao1.melbourne.sgi.com) Received: (from kaos@localhost) by kao1.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA12516; Thu, 7 Sep 2000 18:20:20 +1100 (EST) Date: Thu, 7 Sep 2000 18:20:20 +1100 (EST) From: Keith Owens Message-Id: <200009070720.SAA12516@kao1.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE - kdb struct request kiobuf compatibility Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Trying to keep kdb code the same inside and outside the XFS tree. Needed to hack a bit to handle the XFS only kiobuf field in struct request. Remove all references to STRUCT_REQUEST_HAS_KIOBUF if the kiobuf changes are merged into base kernel. Modid: 2.4.0-test1-xfs:slinx:73872a Date: Thu Sep 7 00:17:57 PDT 2000 Workarea: kao1.melbourne.sgi.com:/hosts/sherman/home/kaos/isms/slinx/2.4.0-test1-xfs Author: kaos The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/include/linux/blkdev.h - 1.22 linux/kdb/modules/kdbm_pg.c - 1.15 From owner-linux-xfs@oss.sgi.com Thu Sep 7 00:31:35 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 00:31:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12610 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 00:30:56 -0700 Received: from kao1.melbourne.sgi.com (kao1.melbourne.sgi.com [134.14.55.179]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA00416 for ; Thu, 7 Sep 2000 00:37:26 -0700 (PDT) mail_from (kaos@kao1.melbourne.sgi.com) Received: (from kaos@localhost) by kao1.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA12558; Thu, 7 Sep 2000 18:29:34 +1100 (EST) Date: Thu, 7 Sep 2000 18:29:34 +1100 (EST) From: Keith Owens Message-Id: <200009070729.SAA12558@kao1.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE - spurious newline in kdbm_pg.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing spurious newline in kdbm_pg.c Modid: 2.4.0-test1-xfs:slinx:73873a Date: Thu Sep 7 00:28:59 PDT 2000 Workarea: kao1.melbourne.sgi.com:/hosts/sherman/home/kaos/isms/slinx/2.4.0-test1-xfs Author: kaos The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/kdb/modules/kdbm_pg.c - 1.16 From owner-linux-xfs@oss.sgi.com Thu Sep 7 03:00:16 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 02:59:56 -0700 Received: from smtp1.cern.ch ([137.138.128.38]:37126 "EHLO smtp1.cern.ch") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 02:59:25 -0700 Received: from pcrd10.cern.ch (pcrd10.cern.ch [137.138.29.237]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id LAA29082; Thu, 7 Sep 2000 11:59:23 +0200 (MET DST) Received: (from fuji@localhost) by pcrd10.cern.ch (8.9.3/8.9.3) id LAA18117; Thu, 7 Sep 2000 11:58:53 +0200 Date: Thu, 7 Sep 2000 11:58:53 +0200 From: Peter.Kelemen@cern.ch To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair dumps core on damaged filesystem (was: Re: XFS assertion failed: vp->v_bh.bh_first != NULL) Message-ID: <20000907115852.A18034@pcrd10.cern.ch> Reply-To: Peter.Kelemen@cern.ch References: <200009062229.RAA25306@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i X-Beat: @457 In-Reply-To: <200009062229.RAA25306@jen.americas.sgi.com>; from lord@sgi.com on Wed, Sep 06, 2000 at 05:29:09PM -0500 Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 2000-09-06 17:29:09 -0500, Steve Lord wrote: Steve, > What sort of load were you putting on the system, also what is > your configuration: The same machine I experienced the vnode-crash on. I was running 8 (eight) parallel bonnie++ processes w/3GB data files. Dual Pentium III 500Mhz, 256M RAM, 4x37.5GB IBM DeskStar disks. One of the disks contain one big 36GB XFS filesystem (created with default values of mkfs.xfs). [root@pcrd18 /root]# xfs_info /shift/pcrd18/data02 meta-data=/shift/pcrd18/data02 isize=256 agcount=35, agsize=261630 blks data = bsize=4096 blocks=9157042, 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 > The vnode crash is being worked on, all I have managed to do so > far is make it harder to hit. It is basically top of the list at > the moment. I'll update my CVS repository soon to see the changes (I'm using the cvs20000829 snapshot). Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Thu Sep 7 04:33:16 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 04:33:07 -0700 Received: from smtp1.cern.ch ([137.138.128.38]:64521 "EHLO smtp1.cern.ch") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 04:32:52 -0700 Received: from pcrd10.cern.ch (pcrd10.cern.ch [137.138.29.237]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id NAA24301; Thu, 7 Sep 2000 13:32:50 +0200 (MET DST) Received: (from fuji@localhost) by pcrd10.cern.ch (8.9.3/8.9.3) id NAA18434; Thu, 7 Sep 2000 13:32:20 +0200 Date: Thu, 7 Sep 2000 13:32:20 +0200 From: Peter.Kelemen@cern.ch To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair dumps core on damaged filesystem (was: Re: XFS assertion failed: vp->v_bh.bh_first != NULL) Message-ID: <20000907133220.B18034@pcrd10.cern.ch> Reply-To: Peter.Kelemen@cern.ch References: <200009062229.RAA25306@jen.americas.sgi.com> <10009071037.ZM5823@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i X-Beat: @522 In-Reply-To: <10009071037.ZM5823@wobbly.melbourne.sgi.com>; from nathans@wobbly.melbourne.sgi.com on Thu, Sep 07, 2000 at 10:36:59AM -0400 Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 2000-09-07 10:36:59 -0400, Nathan Scott wrote: Nathan, > hmm - assuming my source matches Peters, its the second > assignment (scan.c, line 457) there which is unhealthy. Indeed it is. > Also, if you still have the bad filesystem handy, could you use > xfs_db and dump out everything you can about inode 148 and send > that to me too? That would be something like: I expected such a request and I left the filesystem intact after the crash. The core file, xfs_repair binary, xfs_db and xfs_repair output can all be found at: http://home.cern.ch/fuji/xfs/nathan/ Peter PS: Beware, the core file is 19M uncompressed. -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Thu Sep 7 06:43:56 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 06:43:47 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:55376 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 06:43:41 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA07204 for ; Thu, 7 Sep 2000 06:50:14 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id IAA61139; Thu, 7 Sep 2000 08:42:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id IAA50426; Thu, 7 Sep 2000 08:42:23 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA26657; Thu, 7 Sep 2000 08:41:15 -0500 Message-Id: <200009071341.IAA26657@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Peter.Kelemen@cern.ch cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: xfs_repair dumps core on damaged filesystem (was: Re: XFS assertion failed: vp->v_bh.bh_first != NULL) In-Reply-To: Message from Peter.Kelemen@cern.ch of "Thu, 07 Sep 2000 11:58:53 +0200." <20000907115852.A18034@pcrd10.cern.ch> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Thu, 07 Sep 2000 08:41:14 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > = > Dual Pentium III 500Mhz, 256M RAM, 4x37.5GB IBM DeskStar disks. > One of the disks contain one big 36GB XFS filesystem (created > with default values of mkfs.xfs). > = > [root@pcrd18 /root]# xfs_info /shift/pcrd18/data02 > meta-data=3D/shift/pcrd18/data02 isize=3D256 agcount=3D35, agsize=3D= 261630 blks > data =3D bsize=3D4096 blocks=3D9157042, ima= xpct=3D25 > =3D sunit=3D0 swidth=3D0 blks, unwr= itten=3D0 > naming =3Dversion 2 bsize=3D4096 > log =3Dinternal bsize=3D4096 blocks=3D1200 > realtime =3Dnone extsz=3D65536 blocks=3D0, rtextents= =3D0 Just an aside here, performance will improve by using a bigger log and some mount options. mkfs -t xfs -f -l size=3D16000b /dev/xxx would create a 16000 x 4K block log for instance. In heavy metadata updat= e situations, a small log tends to lead to new operations getting blocked waiting for log space, log space being freed by flushing previously modified metadata. Under this load you will always be log bound, but a larger log helps some. For mount options I would recommend logbufs=3D4,logbsize=3D32768,kio logbufs is the number of internal buffers used for writing transactions into, logbsize is the size of these buffers. These two values are current= ly the maximums for Linux. kio only applies for scsi at the moment, it will reduce system overhead in getting I/O requests to the driver. Steve = > = > > The vnode crash is being worked on, all I have managed to do so > > far is make it harder to hit. It is basically top of the list at > > the moment. > = > I'll update my CVS repository soon to see the changes (I'm using > the cvs20000829 snapshot). > = > Peter > = > -- = > .+'''+. .+'''+. .+'''+. .+'''+. .+'= ' > Kelemen P=E9ter / \ / \ Peter.Kelemen@cern.c= h > .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Thu Sep 7 07:09:27 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 07:09:17 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41299 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 07:09:04 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08885 for ; Thu, 7 Sep 2000 07:15:36 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA70261 for ; Thu, 7 Sep 2000 09:07:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA56100 for ; Thu, 7 Sep 2000 09:07:47 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id JAA30212; Thu, 7 Sep 2000 09:06:38 -0500 Message-Id: <200009071406.JAA30212@jen.americas.sgi.com> Date: Thu, 7 Sep 2000 09:06:38 -0500 Subject: TAKE - fix build problem To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The last change to xfs_vfsops.c broke the build, this gets us going again. Please build the kernel when you change it! Date: Thu Sep 7 07:06:59 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73882a linux/fs/xfs/xfs_vfsops.c - 1.287 - Remove last reference to xfsd_lock missed on previous checkin. From owner-linux-xfs@oss.sgi.com Thu Sep 7 08:16:27 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 08:16:17 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:44378 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 08:15:53 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA01803; Thu, 7 Sep 2000 08:22:26 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA76572; Thu, 7 Sep 2000 08:15:50 -0700 (PDT) Date: Thu, 7 Sep 2000 08:15:50 -0700 (PDT) Message-Id: <200009071515.IAA76572@info.engr.sgi.com> X-Pv-Incident: 801095 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 801095 - xfs_repair sucks memory in phase7 To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801095 Status : open Priority : 3 Assigned Engineer : dxm Submitter : dxm *Modified User : lord *Modified User Domain : sgi.com *Description : xfs_repair -n phase7 seems to leak memory big time, chewing up over 100Mb on sagan and causing processes to get nuked. ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 07 2000 08:15:50AM ========================== Just for grins I used the glibc memory tracer on repair and yes there is lots of leakage. The majority of it seems to come from memory allocated at line 315 in libxfs/rdwr.c which is the zone_zalloc call. There are only certain zones which get called via zalloc, and based on the sizes which show up (0x4c and 0x30) I would say that the culprit structures are these (gdb) print/x sizeof(xfs_buf_log_item_t) $8 = 0x30 (gdb) print/x sizeof(xfs_inode_log_item_t) $9 = 0x4c I would ask how these items get freed in the case where a transaction is committed, but is clean. libxfs_trans_commit() will call xfs_trans_free_items for a clean transaction, and trans_commited for a dirty one. In the trans_commited case it ends up in the buf_item_done and inode_item_done functions which free the memory, in the xfs_trans_free_items case it ends up in xfs_trans_unlock_chunk which does not do any freeing of this memory. From owner-linux-xfs@oss.sgi.com Thu Sep 7 08:49:17 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 08:49:07 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10078 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 08:48:39 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03432; Thu, 7 Sep 2000 08:55:12 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA26557; Thu, 7 Sep 2000 08:48:38 -0700 (PDT) Date: Thu, 7 Sep 2000 08:48:38 -0700 (PDT) Message-Id: <200009071548.IAA26557@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Status : open Priority : 3 Assigned Engineer : nathans Submitter : lord *Modified User : lord *Modified User Domain : sgi.com *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 07 2000 08:48:37AM ========================== A couple more data points: o I was running a debug version of mkfs, it does not dump core, just exists. o running ltrace crashed the system in a copy_from_user writing to the block device. This may have more to do with the state ext2 leaves the block device than anything else. I seem to recall that they deliberately do not purge cached data on unmount (flush yes, thow away no). Not sure what this might have to do with it though. This does appear to be repeatable on my box though. From owner-linux-xfs@oss.sgi.com Thu Sep 7 11:38:08 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 11:37:59 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13426 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 11:37:34 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id LAA06116 for ; Thu, 7 Sep 2000 11:44:07 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA24719; Fri, 8 Sep 2000 05:36:15 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id FAA06292; Fri, 8 Sep 2000 05:36:13 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009080536.ZM6301@wobbly.melbourne.sgi.com> Date: Fri, 8 Sep 2000 05:36:12 -0400 In-Reply-To: Steve Lord "TAKE - fix build problem" (Sep 7, 9:06am) References: <200009071406.JAA30212@jen.americas.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: TAKE - fix build problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sep 7, 9:06am, Steve Lord wrote: > Subject: TAKE - fix build problem > The last change to xfs_vfsops.c broke the build, this gets us going > again. Please build the kernel when you change it! > eep ... thought I had, several times ... + installed it & went thru a mount, several times! I must be suffering versionitis. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Sep 7 12:17:28 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 12:17:18 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1911 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 12:16:56 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08416; Thu, 7 Sep 2000 12:23:29 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA11891; Thu, 7 Sep 2000 12:16:25 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id MAA99645; Thu, 7 Sep 2000 12:15:07 -0700 (PDT) Date: Thu, 7 Sep 2000 12:15:07 -0700 (PDT) Message-Id: <200009071915.MAA99645@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Status : open Priority : 3 Assigned Engineer : nathans Submitter : lord *Modified User : nathans *Modified User Domain : engr *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Sep 07 2000 12:15:06PM ========================== double DOH! - ioctl takes a pointer & returns errno - no strace-visible size, of course; - the libxfs Makefile forces -DNDEBUG cos of repair (in the noble tradition of libsim ;), so we don't trip the assert; but anyway... >From the strace output it does look alot like we're writing "too far" in the splat-zeroes-over-last-EFS-SB case - its very tempting to remove this write since we shouldn't expect too many EFS superblocks on all the existing Linux boxen & we don't take such measures for any of the other filesystem types... so, think I'll nuke this. I still suspect the driver ... do you know whether this is going through the generic scsi driver, or something else like md/lvm? I tried reproducing this on two local machines with vanilla scsi devices yesterday with no luck. Guess it could even be specific to a particular type of scsi drive. From owner-linux-xfs@oss.sgi.com Thu Sep 7 13:08:09 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 13:07:59 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:65403 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 13:07:40 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA09410; Thu, 7 Sep 2000 13:14:09 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA11105; Thu, 7 Sep 2000 13:07:34 -0700 (PDT) Date: Thu, 7 Sep 2000 13:07:34 -0700 (PDT) Message-Id: <200009072007.NAA11105@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Status : open Priority : 3 Assigned Engineer : nathans Submitter : lord *Modified User : lord *Modified User Domain : sgi.com *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 07 2000 01:07:34PM ========================== I have modified libsim in the past to attempt to fix this, I never got a fix I was comfortable with. Dumping out the ioctl results was an easy one though. The driver was scsi - no lvm involved, it is an adaptec controller. Since it is 100% repeatable here, I can try anything you can think of. From owner-linux-xfs@oss.sgi.com Thu Sep 7 16:45:52 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 16:45:32 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24344 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 16:45:13 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA07325 for ; Thu, 7 Sep 2000 16:51:46 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA35535 for linux-xfs@oss.sgi.com; Fri, 8 Sep 2000 10:42:39 +1100 (EST) Date: Fri, 8 Sep 2000 10:42:39 +1100 (EST) From: Daniel Moore Message-Id: <200009072342.KAA35535@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73939a Date: Thu Sep 7 16:42:29 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/013 - 1.7 cmd/xfs/stress/017 - 1.5 cmd/xfs/stress/common.dump - 1.12 - use $FSSTRESS_AVOID cmd/xfs/stress/common.rc - 1.27 - define $FSSTRESS_AVOID - options to fsstress to make it avoid operations we can't do safely right now. ie the resvsp and unresvsp operations (there's a bug open on these) From owner-linux-xfs@oss.sgi.com Thu Sep 7 17:18:42 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 17:18:32 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17434 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 17:18:17 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA07589; Thu, 7 Sep 2000 17:24:51 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA84150; Thu, 7 Sep 2000 17:17:47 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA88841; Thu, 7 Sep 2000 17:15:10 -0700 (PDT) Date: Thu, 7 Sep 2000 17:15:10 -0700 (PDT) Message-Id: <200009080015.RAA88841@feature.engr.sgi.com> X-Pv-Incident: 801063 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (nathans@engr.sgi.com) Subject: PARTIAL TAKE 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord Status : open Assigned Engineer : nathans Priority : 3 *Modified Date : 09/07/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : From: nathan scott (PARTIAL) Date: Sep 07 2000 05:15:10PM [pvnews version: 1.71] ---------------------------- Steve, Please let me know whether this fixes your write error. I've also put a mkfs binary at babylon:/tmp/mkfs.xfs - could you run this one too, then send me the output and core file which it generates. thanks. Modid: 2.4.0-test1-xfs:slinx:73917a Date: Thu Sep 7 15:57:41 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/mkfs/xfs_mkfs.c - 1.176 - remove the zero-512-bytes code to overwrite the potential last EFS superblock - unnecessary on Linux. Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 07 2000 01:07:34PM ========================== I have modified libsim in the past to attempt to fix this, I never got a fix I was comfortable with. Dumping out the ioctl results was an easy one though. The driver was scsi - no lvm involved, it is an adaptec controller. Since it is 100% repeatable here, I can try anything you can think of. From owner-linux-xfs@oss.sgi.com Thu Sep 7 17:29:53 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 17:29:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57370 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 17:29:19 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA00291 for ; Thu, 7 Sep 2000 17:35:52 -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 LAA07237 for linux-xfs@oss.sgi.com; Fri, 8 Sep 2000 11:28:01 +1100 (EST) Date: Fri, 8 Sep 2000 11:28:01 +1100 (EST) From: Nathan Scott Message-Id: <200009080028.LAA07237@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sep 7, 1:32pm, Peter.Kelemen@cern.ch wrote: > Subject: Re: xfs_repair dumps core on damaged filesystem > ... > I expected such a request and I left the filesystem intact after > the crash. The core file, xfs_repair binary, xfs_db and > xfs_repair output can all be found at: > http://home.cern.ch/fuji/xfs/nathan/ > Thanks for your efforts, Peter - made it easy to track down. This should fix it... --- 453,463 ---- * update cursor keys to reflect this block */ if (check_dups == 0) { ! bm_cursor->level[level].first_key = ! INT_GET(pkey[0].br_startoff, ARCH_CONVERT); ! i = INT_GET(block->bb_numrecs, ARCH_CONVERT) - 1; bm_cursor->level[level].last_key = ! INT_GET(pkey[i].br_startoff, ARCH_CONVERT); } return(0); Modid: 2.4.0-test1-xfs:slinx:73949a Date: Thu Sep 7 17:21:09 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/repair/scan.c - 1.44 - missed an endian conversion here. From owner-linux-xfs@oss.sgi.com Thu Sep 7 18:20:44 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 18:20:24 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33309 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 18:20:02 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA09187; Thu, 7 Sep 2000 18:26:35 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA69203; Thu, 7 Sep 2000 18:19:59 -0700 (PDT) Date: Thu, 7 Sep 2000 18:19:59 -0700 (PDT) Message-Id: <200009080119.SAA69203@info.engr.sgi.com> X-Pv-Incident: 801095 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 801095 - xfs_repair sucks memory in phase7 To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801095 Status : open Priority : 3 Assigned Engineer : dxm Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : xfs_repair -n phase7 seems to leak memory big time, chewing up over 100Mb on sagan and causing processes to get nuked. ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 07 2000 08:15:50AM ========================== ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 07 2000 06:19:59PM ========================== phase6 is pretty leaky too. Needed to free xfs_buf_log_items and xfs_inode_log_items. This TAKE plugs the big leaks. Modid: 2.4.0-test1-xfs:slinx:73955a Date: Thu Sep 7 18:14:48 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/include/libxfs.h - 1.14 - pv 801095 add allocated counter to zones cmd/xfs/libxfs/rdwr.c - 1.15 - pv 801095 free xfs_buf_log_items and xfs_inode_log_items add debugging including allocated counter for zones From owner-linux-xfs@oss.sgi.com Thu Sep 7 18:21:24 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 18:21:14 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:34077 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 18:21:01 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA02957 for ; Thu, 7 Sep 2000 18:27:34 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA03996 for linux-xfs@oss.sgi.com; Fri, 8 Sep 2000 12:19:41 +1100 (EST) Date: Fri, 8 Sep 2000 12:19:41 +1100 (EST) From: Daniel Moore Message-Id: <200009080119.MAA03996@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_repair plug some leaks Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing for pv 801095 - the really big leaks Modid: 2.4.0-test1-xfs:slinx:73955a Date: Thu Sep 7 18:14:48 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/include/libxfs.h - 1.14 - pv 801095 add allocated counter to zones cmd/xfs/libxfs/rdwr.c - 1.15 - pv 801095 free xfs_buf_log_items and xfs_inode_log_items add debugging including allocated counter for zones cmd/xfs/libxfs/trans.c - 1.2 - debug. cmd/xfs/stress/check - 1.7 - fix error case From owner-linux-xfs@oss.sgi.com Thu Sep 7 19:20:44 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 19:20:34 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32291 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 19:20:10 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA07644; Thu, 7 Sep 2000 19:26:44 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA61418; Thu, 7 Sep 2000 19:20:09 -0700 (PDT) Date: Thu, 7 Sep 2000 19:20:09 -0700 (PDT) Message-Id: <200009080220.TAA61418@info.engr.sgi.com> X-Pv-Incident: 801241 webPV: omen.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ivanr@engr.sgi.com) Subject: BUG 801241 - xfsdump can cause filesystem corruption To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801241 Submitter : ivanr Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 1 Project : xfs-linux Status : open Description : QA for xfsdump/xfsrestore revealed that it is possible for xfsdump to cause filesystem corruption. The test involves creating a filesystem, creating a whole buncha files, xfsdumping them to a file somewhere, then removing all the files. xfs_check reports lots of inodes with zero link counts, etc. It's probably due to xfsdump using bulkstat on the entire fs. The following is a script which will reliably (at least on bruce.melbourne) produce the error. Run it in cmd/xfs/stress - it needs the src/fill program, and make sure you fix the variables at the top. ======================================= #!/bin/sh #TEST_DIR=/mnt/xfs1 #TEST_DEV=/dev/sda10 TEST_DIR= TEST_DEV= tmp=/tmp/$$ dump_dir=$TEST_DIR/dump.$$ dump_file=$tmp.dumpfile here=`pwd` trap "rm -rf $tmp\*; exit" 0 1 2 3 15 _wipe_dev() { umount $1 mkfs.xfs -f $1 mount $1 } _create_dumpdir_fill() { echo "Creating directory system to dump using src/fill." # wipe test dir clean first rm -rf $TEST_DIR/* cat <$tmp.config # pathname size in bytes # small 10 big 102400 sub/small 10 sub/big 102400 # sub/a 1 sub/b 2 sub/c 4 sub/d 8 sub/e 16 sub/f 32 sub/g 64 sub/h 128 sub/i 256 sub/j 512 sub/k 1024 sub/l 2048 sub/m 4096 sub/n 8192 # sub/a00 100 sub/b00 200 sub/c00 400 sub/d00 800 sub/e00 1600 sub/f00 3200 sub/g00 6400 sub/h00 12800 sub/i00 25600 sub/j00 51200 sub/k00 102400 sub/l00 204800 sub/m00 409600 sub/n00 819200 # sub/a000 1000 sub/e000 16000 sub/h000 128000 sub/k000 1024000 End-of-File if mkdir -p $dump_dir then : else echo "Error: cannot mkdir \"$dump_dir\"" exit 1 fi cd $dump_dir sed -e '/^#/d' $tmp.config \ | while read file nbytes do dir=`dirname $file` if [ "$dir" != "." ] then if [ ! -d $dir ] then if mkdir $dir then : else echo "Error: cannot mkdir \"$dir\"" exit 1 fi fi fi rm -f $file if $here/src/fill $file $file $nbytes then : else echo "Error: cannot create \"$file\"" exit 1 fi done cd $here } _fix_malloc() { # filter out the Electric Fence notice perl -e ' undef $/; $_ = <>; s/\n Electric Fence .*\n//g; print' } NO_REMOUNT=1 _check_fs() { device=$1 xfs_check $device 2>&1 | _fix_malloc > $tmp.xfscheck if [ -s $tmp.xfscheck ] then echo "_check_fs: filesystem on $device is inconsistent (xfs_check)" rm -f $tmp.xfscheck fi if ! xfs_repair -n $device > /dev/null 2>&1 then echo "_check_fs: filesystem on $device is inconsistent (xfs_repair)" fi } _wipe_dev $TEST_DEV _create_dumpdir_fill sync sleep 15 xfsdump -f $dump_file -M med -L sess $TEST_DIR > /dev/null rm -rf $dump_dir _check_fs $TEST_DEV ======================================= From owner-linux-xfs@oss.sgi.com Thu Sep 7 20:03:36 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 20:03:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:8300 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 20:03:03 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA24048; Thu, 7 Sep 2000 19:55:22 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA28543; Thu, 7 Sep 2000 20:02:31 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA32674; Thu, 7 Sep 2000 20:01:13 -0700 (PDT) Date: Thu, 7 Sep 2000 20:01:13 -0700 (PDT) Message-Id: <200009080301.UAA32674@info.engr.sgi.com> X-Pv-Incident: 801246 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 801246 - XFS on loopback mount doesn't work To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801246 Submitter : dxm Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : Mike reminded me of this problem, so I've opened a bug. From owner-linux-xfs@oss.sgi.com Thu Sep 7 22:26:09 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 22:25:49 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:12159 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 22:25:24 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA04008; Thu, 7 Sep 2000 22:17:43 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA19079; Thu, 7 Sep 2000 22:25:20 -0700 (PDT) Date: Thu, 7 Sep 2000 22:25:20 -0700 (PDT) Message-Id: <200009080525.WAA19079@info.engr.sgi.com> X-Pv-Incident: 801241 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: UPDATE 801241 - xfsdump can cause filesystem corruption To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801241 Status : open Priority : 1 Assigned Engineer : nb Submitter : ivanr Opened Date : 09/07/00 *Modified User : dxm *Modified User Domain : engr *Description : QA for xfsdump/xfsrestore revealed that it is possible for xfsdump to cause filesystem corruption. The test involves creating a filesystem, creating a whole buncha files, xfsdumping them to a file somewhere, then removing all the files. xfs_check reports lots of inodes with zero link counts, etc. It's probably due to xfsdump using bulkstat on the entire fs. The following is a script which will reliably (at least on bruce.melbourne) produce the error. Run it in cmd/xfs/stress - it needs the src/fill program, and make sure you fix the ..... ========================== ADDITIONAL INFORMATION (UPDATE) From: dxm@engr (BugWorks) Date: Sep 07 2000 10:25:19PM ========================== _check_fs() should "umount $device" before running xfs_check or xfs_repair or else "corruption" would be expected. I've made this change here, and still see corruption after unmounting. From owner-linux-xfs@oss.sgi.com Thu Sep 7 22:52:59 2000 Received: by oss.sgi.com id ; Thu, 7 Sep 2000 22:52:49 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57642 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Sep 2000 22:52:22 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA03948; Thu, 7 Sep 2000 22:58:56 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA14588; Thu, 7 Sep 2000 22:52:21 -0700 (PDT) Date: Thu, 7 Sep 2000 22:52:21 -0700 (PDT) Message-Id: <200009080552.WAA14588@info.engr.sgi.com> X-Pv-Incident: 800752 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: CLOSE 800752 - repair core dump in scanfunc_bno To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800752 *Status : closed Priority : 2 Assigned Engineer : nathans Submitter : nathans Opened Date : 08/31/00 *Closed Date : 09/07/00 *Fixed By : nathans *Fixed By Domain : engr *Modified Date : 09/07/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: nathans@engr (BugWorks) Date: Sep 07 2000 10:52:20PM ========================== This seems to have been fixed by one of the repair/libxfs changes - previously this QA test produced a core file every time it was run, whereas it has now passed on every QA host for the last four nights in a row & I cannot reproduce it by hand either. From owner-linux-xfs@oss.sgi.com Fri Sep 8 00:57:00 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 00:56:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:64532 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 00:56:24 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA12861; Fri, 8 Sep 2000 00:48:44 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id AAA99881; Fri, 8 Sep 2000 00:55:05 -0700 (PDT) Date: Fri, 8 Sep 2000 00:55:05 -0700 (PDT) Message-Id: <200009080755.AAA99881@feature.engr.sgi.com> X-Pv-Incident: 801063 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (lord@sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord Status : open Assigned Engineer : nathans Priority : 3 *Modified Date : 09/08/00 *Modified User : lord *Modified User Domain : sgi.com *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: steve lord Date: Sep 08 2000 12:55:03AM [pvnews version: 1.71] ========================== > > Steve, > > Please let me know whether this fixes your write error. > I've also put a mkfs binary at babylon:/tmp/mkfs.xfs - > could you run this one too, then send me the output and > core file which it generates. > This fixes the error. Interestingly enough, there was just a message in linux-fsdevel about a size off by one error in the block device layer. [I have been trying to get the linear md driver to work with NTFS volumes for several months and it never worked. - I was suspecting the NTFS driver (after having fixed linear md and verified that at least that worked fine) but today I finally found why it doesn't work: There is a bug in reading/writing to block devices. - It manifests itself in the form that partitions are too small by exactly one sector! Even though a cfdisk shows that a partition has a certain number of sectors, you can never seek + read and/or write to the last sector (doing file i/o using read/write(2) [also tried fread/fwrite(3), same result]. - Last sector doesn't seem to exist. However reading the actual hd (/dev/hdb or /dev/sda, ie. affects both IDE and SCSI) instead of the partition (/dev/hdb7 or whatever) the sector does exist and contains the expected information!] Looks like it could be related. i.e. something is lying about the size. From owner-linux-xfs@oss.sgi.com Fri Sep 8 03:18:51 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 03:18:32 -0700 Received: from hermes.mixx.net ([212.84.196.2]:28431 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 8 Sep 2000 03:18:02 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id A93D1F80A for ; Fri, 8 Sep 2000 12:18:00 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id D0EBA2CA6D; Fri, 8 Sep 2000 12:17:59 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: mkfs.xfs & xfs_repair crashing? Date: 8 Sep 2000 10:17:59 GMT Organization: innominate AG, Berlin, Germany Lines: 19 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968408279 16698 10.0.0.69 (8 Sep 2000 10:17:59 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing has anybody else seen mkfs.xfs and xfS_repair crashing? i yesterday updated my home machine to the latest xfs code and tar'ed together the root dir - mkfs.xfs'ed with the new (libxfs) mkfs.xfs and it crashed (core dumped) on it - so i did it with the old (sim based) mkfs.xfs and it worked but on that fresh filesystem the new xfs_repair core-dumped ... the old xfS_repair worked ... has anybody else seen this behaviour with the latest code (it was absolutely reproducable for me)? t p.s.: p5 233, 64mb, ide, no kio-stuff -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 03:31:12 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 03:30:51 -0700 Received: from hermes.mixx.net ([212.84.196.2]:46351 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 8 Sep 2000 03:30:43 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 0F982F810 for ; Fri, 8 Sep 2000 12:30:42 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id BCE582CA6D; Fri, 8 Sep 2000 12:30:41 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: mysterious problem Date: 8 Sep 2000 10:30:41 GMT Organization: innominate AG, Berlin, Germany Lines: 32 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968409041 16698 10.0.0.69 (8 Sep 2000 10:30:41 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing and another one - i have here a machine (dual p6 333, 128m, ide) with an rootfs on ext2 and the same on xfs plus my homedir nfs mounted from a fileserver - then i run the xfs root fs and will start netscape i get a core dump with the following backtrace (gdb) bt #0 0x4024dc55 in __getdents (fd=16, buf=0x90ea030 "", nbytes=65536) at ../sysdeps/unix/sysv/linux/getdents.c:84 #1 0x4024d82c in __readdir (dirp=0x90ea000) at ../sysdeps/unix/readdir.c:57 ... if i do it with the ext2 root fs (and the _same_ kernel) it works fine ... maybe the xfs and the nfs code are walking on eachother foot anywhere here? some more side infos: nfs server is 2.2.17pre17 with dhiggens/trond patches, the ext2 system is ext2 only and the xfs one xfs only, also it is not the netscape bin - running the bin from the ext2 fs on the xfs root system crashes too, ah - and the xfs code is fresh from now but the problem is here for at least some weeks (as long as i know) and is absolutely reproducable ... any ideas? t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 04:53:41 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 04:53:21 -0700 Received: from hermes.mixx.net ([212.84.196.2]:4114 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 8 Sep 2000 04:52:55 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 83631F816 for ; Fri, 8 Sep 2000 13:52:53 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 3E4582CA6D; Fri, 8 Sep 2000 13:52:53 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs as root fs Date: 8 Sep 2000 11:52:53 GMT Organization: innominate AG, Berlin, Germany Lines: 33 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968413973 5650 10.0.0.69 (8 Sep 2000 11:52:53 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing i run several machines for testing with xfs root filesystem and it looks like something is not working properly ... all the systems are dual bootable with ext2 root from which i max xfs_check or xfs_repair the xfs root partition ... from time to time i just boot into that system (after a clean shutdown of the xfs root system) and check the xfs fs and in most cases it contains various simple problems ... anybody else seeing this too? (anybody else running with xfs as /?) also i quite often have situations where i can't boot the system with xfs root - it either dumps into kdb on mounting the fs r/w (bt shows only things like flip_close etc. - something i think russel or nathan saw too) or it can mount it but nothing useable is on it (can't find /sbin/getty etc.) ... in both cases booting into the ext2 system and letting xfs_repair fix the problems helps - after that it definitely boots fine again ... also this is quite reproducable some more side infos: p5 or dual p6 systems with 64m or 128m, ide disk, no kio-stuff, redhat 6.2 (egcs) and always updating to the latest xfs cvs tree anybody else seeing this or any ideas? t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 07:33:04 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 07:32:44 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:32586 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 07:32:24 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA10409 for ; Fri, 8 Sep 2000 07:24:44 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA55331; Fri, 8 Sep 2000 09:31:05 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA53998; Fri, 8 Sep 2000 09:31:05 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA15622; Fri, 8 Sep 2000 09:29:46 -0500 Message-Id: <200009081429.JAA15622@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs & xfs_repair crashing? In-Reply-To: Message from Thomas Graichen of "08 Sep 2000 10:17:59 GMT." Date: Fri, 08 Sep 2000 09:29:45 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > has anybody else seen mkfs.xfs and xfS_repair crashing? > > i yesterday updated my home machine to the latest xfs code and > tar'ed together the root dir - mkfs.xfs'ed with the new (libxfs) > mkfs.xfs and it crashed (core dumped) on it - so i did it with > the old (sim based) mkfs.xfs and it worked but on that fresh > filesystem the new xfs_repair core-dumped ... the old xfS_repair > worked ... has anybody else seen this behaviour with the latest > code (it was absolutely reproducable for me)? > The latest commands worked for me - I always do a make clean realclean when rebuilding commands, could you try this. Also, if the problem is still there, can you send us a backtrace from the core dump. Thanks Steve From owner-linux-xfs@oss.sgi.com Fri Sep 8 08:26:23 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 08:26:14 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:20315 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 08:25:56 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA18693 for ; Fri, 8 Sep 2000 08:18:15 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA68164; Fri, 8 Sep 2000 10:24:35 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA89422; Fri, 8 Sep 2000 10:24:35 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id KAA18635; Fri, 8 Sep 2000 10:23:16 -0500 Message-Id: <200009081523.KAA18635@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs as root fs In-Reply-To: Message from Thomas Graichen of "08 Sep 2000 11:52:53 GMT." Date: Fri, 08 Sep 2000 10:23:16 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > i run several machines for testing with xfs root filesystem and it > looks like something is not working properly ... all the systems > are dual bootable with ext2 root from which i max xfs_check or > xfs_repair the xfs root partition ... from time to time i > just boot into that system (after a clean shutdown of the > xfs root system) and check the xfs fs and in most cases > it contains various simple problems ... anybody else > seeing this too? (anybody else running with xfs as > /?) > I just tried three copies of a root filesystem into xfs using find / -mount -print | cpio -pdm /mnt/root In two out of the three cases running repair on the resulting filesystem I got a number of disconnected inodes: disconnected inode 132, moving to lost+found disconnected inode 133, moving to lost+found disconnected inode 134, moving to lost+found disconnected inode 135, moving to lost+found disconnected inode 136, moving to lost+found disconnected inode 137, moving to lost+found disconnected inode 138, moving to lost+found disconnected inode 139, moving to lost+found disconnected inode 140, moving to lost+found disconnected inode 141, moving to lost+found disconnected inode 142, moving to lost+found disconnected inode 143, moving to lost+found disconnected inode 144, moving to lost+found disconnected inode 145, moving to lost+found disconnected inode 146, moving to lost+found disconnected inode 147, moving to lost+found disconnected inode 148, moving to lost+found disconnected inode 149, moving to lost+found disconnected inode 150, moving to lost+found disconnected inode 151, moving to lost+found disconnected inode 152, moving to lost+found disconnected inode 153, moving to lost+found disconnected inode 154, moving to lost+found disconnected inode 155, moving to lost+found disconnected inode 156, moving to lost+found disconnected inode 157, moving to lost+found disconnected inode 158, moving to lost+found disconnected dir inode 524416, moving to lost+found I have not yet determined anything special about the files themselves - a couple are named pipes, the rest seem to be temporary files. This looks like something to start digging from. Steve From owner-linux-xfs@oss.sgi.com Fri Sep 8 08:31:34 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 08:31:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:41308 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 08:31:16 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA19355 for ; Fri, 8 Sep 2000 08:23:35 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA69728; Fri, 8 Sep 2000 10:29:57 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA59412; Fri, 8 Sep 2000 10:29:57 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id KAA18649; Fri, 8 Sep 2000 10:28:38 -0500 Message-Id: <200009081528.KAA18649@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: mysterious problem In-Reply-To: Message from Thomas Graichen of "08 Sep 2000 10:30:41 GMT." Date: Fri, 08 Sep 2000 10:28:38 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > and another one - i have here a machine (dual p6 333, 128m, ide) > with an rootfs on ext2 and the same on xfs plus my homedir nfs > mounted from a fileserver - then i run the xfs root fs and will > start netscape i get a core dump with the following backtrace > > (gdb) bt > #0 0x4024dc55 in __getdents (fd=16, buf=0x90ea030 "", nbytes=65536) > at ../sysdeps/unix/sysv/linux/getdents.c:84 > #1 0x4024d82c in __readdir (dirp=0x90ea000) at ../sysdeps/unix/readdir.c:5 7 > ... Rather depends on what fd 16 is in netscape at this point. It is probably a directory in xfs given the nbytes value. Is it possible to find this out, an strace output of netscape could be huge depending on how far it has got before it crashes. I suppose another way would be to start netscape in gdb, and when it crashes go look at the /proc directory for the process, doing an ls -l in the /proc/pid/fd subdirectory will give us what is at this descriptor. For example mine looks like this right now: lr-x------ 1 lord network 64 Sep 8 10:27 0 -> /dev/null l-wx------ 1 lord network 64 Sep 8 10:27 1 -> pipe:[2732573] l-wx------ 1 lord network 64 Sep 8 10:27 10 -> pipe:[2732425] lr-x------ 1 lord network 64 Sep 8 10:27 11 -> pipe:[2732460] l-wx------ 1 lord network 64 Sep 8 10:27 12 -> pipe:[2732460] lrwx------ 1 lord network 64 Sep 8 10:27 13 -> /home/tulip15/lord/.netscape/cert7.db lrwx------ 1 lord network 64 Sep 8 10:27 14 -> /home/tulip15/lord/.netscape/key3.db lrwx------ 1 lord network 64 Sep 8 10:27 15 -> /var/tmp/lord-cache/index.db lrwx------ 1 lord network 64 Sep 8 10:27 16 -> /home/tulip15/lord/.netscape/history.dat lr-x------ 1 lord network 64 Sep 8 10:27 17 -> pipe:[2732573] l-wx------ 1 lord network 64 Sep 8 10:27 18 -> pipe:[2732573] lrwx------ 1 lord network 64 Sep 8 10:27 19 -> /dev/tty1 l-wx------ 1 lord network 64 Sep 8 10:27 2 -> pipe:[2732573] lrwx------ 1 lord network 64 Sep 8 10:27 20 -> /dev/tty1 lrwx------ 1 lord network 64 Sep 8 10:27 21 -> /home/tulip15/lord/.netscape/xover-cache/host-fido.engr.sgi.com/hostinfo.dat lr-x------ 1 lord network 64 Sep 8 10:27 22 -> pipe:[2732703] lr-x------ 1 lord network 64 Sep 8 10:27 23 -> pipe:[2868891] l-wx------ 1 lord network 64 Sep 8 10:27 24 -> pipe:[2732703] lrwx------ 1 lord network 64 Sep 8 10:27 25 -> socket:[3123735] l-wx------ 1 lord network 64 Sep 8 10:27 26 -> pipe:[2868891] lrwx------ 1 lord network 64 Sep 8 10:27 27 -> socket:[3284401] lr-x------ 1 lord network 64 Sep 8 10:27 29 -> /usr/lib/netscape/java/classes/java40.jar lrwx------ 1 lord network 64 Sep 8 10:27 3 -> /dev/zero lr-x------ 1 lord network 64 Sep 8 10:27 30 -> pipe:[2864534] l-wx------ 1 lord network 64 Sep 8 10:27 31 -> pipe:[2864534] lrwx------ 1 lord network 64 Sep 8 10:27 33 -> socket:[3284399] lrwx------ 1 lord network 64 Sep 8 10:27 34 -> socket:[3284400] l-wx------ 1 lord network 64 Sep 8 10:27 4 -> pipe:[2732417] lr-x------ 1 lord network 64 Sep 8 10:27 5 -> pipe:[2732418] lr-x------ 1 lord network 64 Sep 8 10:27 6 -> pipe:[2732419] l-wx------ 1 lord network 64 Sep 8 10:27 7 -> pipe:[2732419] lrwx------ 1 lord network 64 Sep 8 10:27 8 -> socket:[2732423] lr-x------ 1 lord network 64 Sep 8 10:27 9 -> pipe:[2732425] >From your description, I do not think XFS and NFS are stepping on each other, since they are never both involved in the same filesystem. Steve > > if i do it with the ext2 root fs (and the _same_ kernel) it > works fine ... maybe the xfs and the nfs code are walking on > eachother foot anywhere here? > > some more side infos: nfs server is 2.2.17pre17 with dhiggens/trond > patches, the ext2 system is ext2 only and the xfs one xfs only, > also it is not the netscape bin - running the bin from the > ext2 fs on the xfs root system crashes too, ah - and the > xfs code is fresh from now but the problem is here for > at least some weeks (as long as i know) and is > absolutely reproducable ... > > any ideas? > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 08:41:53 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 08:41:34 -0700 Received: from hermes.mixx.net ([212.84.196.2]:59145 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 8 Sep 2000 08:41:15 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B5EF3F804 for ; Fri, 8 Sep 2000 17:41:13 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 924F92CA6D; Fri, 8 Sep 2000 17:41:13 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs as root fs Date: 8 Sep 2000 15:41:13 GMT Organization: innominate AG, Berlin, Germany Lines: 63 Distribution: local Message-ID: References: <200009081523.KAA18635@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968427673 27791 10.0.0.69 (8 Sep 2000 15:41:13 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> i run several machines for testing with xfs root filesystem and it >> looks like something is not working properly ... all the systems >> are dual bootable with ext2 root from which i max xfs_check or >> xfs_repair the xfs root partition ... from time to time i >> just boot into that system (after a clean shutdown of the >> xfs root system) and check the xfs fs and in most cases >> it contains various simple problems ... anybody else >> seeing this too? (anybody else running with xfs as >> /?) >> > I just tried three copies of a root filesystem into xfs using > find / -mount -print | cpio -pdm /mnt/root > In two out of the three cases running repair on the resulting > filesystem I got a number of disconnected inodes: > disconnected inode 132, moving to lost+found > disconnected inode 133, moving to lost+found > disconnected inode 134, moving to lost+found > disconnected inode 135, moving to lost+found > disconnected inode 136, moving to lost+found > disconnected inode 137, moving to lost+found > disconnected inode 138, moving to lost+found > disconnected inode 139, moving to lost+found > disconnected inode 140, moving to lost+found > disconnected inode 141, moving to lost+found > disconnected inode 142, moving to lost+found > disconnected inode 143, moving to lost+found > disconnected inode 144, moving to lost+found > disconnected inode 145, moving to lost+found > disconnected inode 146, moving to lost+found > disconnected inode 147, moving to lost+found > disconnected inode 148, moving to lost+found > disconnected inode 149, moving to lost+found > disconnected inode 150, moving to lost+found > disconnected inode 151, moving to lost+found > disconnected inode 152, moving to lost+found > disconnected inode 153, moving to lost+found > disconnected inode 154, moving to lost+found > disconnected inode 155, moving to lost+found > disconnected inode 156, moving to lost+found > disconnected inode 157, moving to lost+found > disconnected inode 158, moving to lost+found > disconnected dir inode 524416, moving to lost+found > I have not yet determined anything special about the files themselves - a > couple are named pipes, the rest seem to be temporary files. > This looks like something to start digging from. yes - the things i usually had were the /var/run/sybsys/* files on readhat - so stuff changed or removed in the shutdown process t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 08:43:23 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 08:43:04 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24144 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 08:43:00 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA02116 for ; Fri, 8 Sep 2000 08:49:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA75043; Fri, 8 Sep 2000 10:41:39 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA32116; Fri, 8 Sep 2000 10:41:39 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id KAA18672; Fri, 8 Sep 2000 10:40:20 -0500 Message-Id: <200009081540.KAA18672@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Steve Lord cc: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: xfs as root fs In-Reply-To: Message from Steve Lord of "Fri, 08 Sep 2000 10:23:16 CDT." <200009081523.KAA18635@jen.americas.sgi.com> Date: Fri, 08 Sep 2000 10:40:20 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > I just tried three copies of a root filesystem into xfs using > > find / -mount -print | cpio -pdm /mnt/root > > In two out of the three cases running repair on the resulting > filesystem I got a number of disconnected inodes: > > disconnected inode 132, moving to lost+found > disconnected inode 133, moving to lost+found > disconnected inode 134, moving to lost+found > disconnected inode 135, moving to lost+found .... OK, this is a red herring, these were files from the lost+found on the root filesystem, so xfs_repair removed its lost+found to start with, so it was not finding anything wrong really. This basically says that after cloning a root the lost+found directory in the xfs filesystem needs to be cleaned. Steve From owner-linux-xfs@oss.sgi.com Fri Sep 8 08:46:35 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 08:46:24 -0700 Received: from hermes.mixx.net ([212.84.196.2]:522 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 8 Sep 2000 08:46:08 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id CBE28F807 for ; Fri, 8 Sep 2000 17:46:06 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id AFAD72CA6D; Fri, 8 Sep 2000 17:46:06 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: mysterious problem Date: 8 Sep 2000 15:46:06 GMT Organization: innominate AG, Berlin, Germany Lines: 35 Distribution: local Message-ID: References: <200009081528.KAA18649@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968427966 27791 10.0.0.69 (8 Sep 2000 15:46:06 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> and another one - i have here a machine (dual p6 333, 128m, ide) >> with an rootfs on ext2 and the same on xfs plus my homedir nfs >> mounted from a fileserver - then i run the xfs root fs and will >> start netscape i get a core dump with the following backtrace >> >> (gdb) bt >> #0 0x4024dc55 in __getdents (fd=16, buf=0x90ea030 "", nbytes=65536) >> at ../sysdeps/unix/sysv/linux/getdents.c:84 >> #1 0x4024d82c in __readdir (dirp=0x90ea000) at ../sysdeps/unix/readdir.c:5 > 7 >> ... > Rather depends on what fd 16 is in netscape at this point. It is probably > a directory in xfs given the nbytes value. Is it possible to find this > out, an strace output of netscape could be huge depending on how far it > has got before it crashes. I suppose another way would be to start netscape > in gdb, and when it crashes go look at the /proc directory for the process, > doing an ls -l in the /proc/pid/fd subdirectory will give us what is at this > descriptor. an strace output is now at http://innominate.org/~graichen/projects/xfs/misc/strace.out.gz maybe you can find something in it - otherwise i may run it in the debugger ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 08:49:24 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 08:49:04 -0700 Received: from hermes.mixx.net ([212.84.196.2]:2570 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 8 Sep 2000 08:48:58 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id BF7C9F807 for ; Fri, 8 Sep 2000 17:48:56 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 829AB2CA6D; Fri, 8 Sep 2000 17:48:56 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs as root fs Date: 8 Sep 2000 15:48:56 GMT Organization: innominate AG, Berlin, Germany Lines: 43 Distribution: local Message-ID: References: <200009081540.KAA18672@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968428136 27791 10.0.0.69 (8 Sep 2000 15:48:56 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> >> I just tried three copies of a root filesystem into xfs using >> >> find / -mount -print | cpio -pdm /mnt/root >> >> In two out of the three cases running repair on the resulting >> filesystem I got a number of disconnected inodes: >> >> disconnected inode 132, moving to lost+found >> disconnected inode 133, moving to lost+found >> disconnected inode 134, moving to lost+found >> disconnected inode 135, moving to lost+found > .... > OK, this is a red herring, these were files from the lost+found on the root > filesystem, so xfs_repair removed its lost+found to start with, so it was > not finding anything wrong really. > This basically says that after cloning a root the lost+found directory in > the xfs filesystem needs to be cleaned. hmmm in my cases the files were real (just on several real machines i get it after some time of use) - i also usually do an xfs_repair mount rm -rf lost+found xfs_repair <- is fine now umount reboot so - it is not the lost+found dir in my case ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 08:52:24 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 08:52:04 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:18311 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 08:51:50 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id KAA27203; Fri, 8 Sep 2000 10:51:47 -0500 (CDT) Date: Fri, 8 Sep 2000 10:51:47 -0500 (CDT) Message-Id: <200009081551.KAA27203@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: Small patch to open_by_handle function in fs/xfs/linux/xfs_ioctl.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing By default linux does not free dcache entries. They may be needed later. It stick them on an unused queue list and will delete them if memory is needed or reuse them. The dentry craeted in open_by_handle is a discounted, anonymous, dcache enties and will not be reused. They will hang around until the memory is needed or an umount is is done casuing an unnecessary waist of memory. The following patch forces dentry created by open_by_handle to be deleted when they are no longer neeed instead of being put on the unsed list. This does not fix a bug but it does keep things nice and tidy. Bill Jones -------------------------------- xfs_ioctl.c.patch *** xfs_ioctl.c.orig Fri Sep 8 10:29:47 2000 --- xfs_ioctl.c Fri Sep 8 10:30:32 2000 *************** *** 286,291 **** --- 286,303 ---- } + /* + * We don't want to cluter up the dcache with non namei dentries. + */ + static int open_by_inode_delete_dentry(struct dentry *dentry) + { + return 1; + } + + static struct dentry_operations open_by_inode_dentry_operations = { + d_delete: open_by_inode_delete_dentry, + }; + int xfs_open_by_handle( unsigned int cmd, *************** *** 453,458 **** --- 465,475 ---- * Keep nfsd happy. */ dentry->d_flags |= DCACHE_NFSD_DISCONNECTED; + + /* + * Don't fill dcache with useless entries. + */ + dentry->d_op = &open_by_inode_dentry_operations; /* * Make sure dput can find this dcache entry. From owner-linux-xfs@oss.sgi.com Fri Sep 8 11:12:03 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 11:11:53 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22040 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 11:11:31 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA17146 for ; Fri, 8 Sep 2000 11:03:50 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA09231; Fri, 8 Sep 2000 13:08:55 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id NAA23696; Fri, 8 Sep 2000 13:08:54 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e88I8qe07634; Fri, 8 Sep 2000 13:08:53 -0500 Message-ID: <39B92B33.7ACC80D2@thebarn.com> Date: Fri, 08 Sep 2000 13:08:51 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: xfs as root fs References: <200009081540.KAA18672@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > Steve Lord wrote: > > >> > >> I just tried three copies of a root filesystem into xfs using > >> > >> find / -mount -print | cpio -pdm /mnt/root > >> > >> In two out of the three cases running repair on the resulting > >> filesystem I got a number of disconnected inodes: > >> > >> disconnected inode 132, moving to lost+found > >> disconnected inode 133, moving to lost+found > >> disconnected inode 134, moving to lost+found > >> disconnected inode 135, moving to lost+found > > > .... > > > OK, this is a red herring, these were files from the lost+found on the root > > filesystem, so xfs_repair removed its lost+found to start with, so it was > > not finding anything wrong really. > > > This basically says that after cloning a root the lost+found directory in > > the xfs filesystem needs to be cleaned. > > hmmm in my cases the files were real (just on several real machines > i get it after some time of use) - i also usually do an > > xfs_repair > mount > rm -rf lost+found > xfs_repair <- is fine now > umount > reboot > > so - it is not the lost+found dir in my case ... > Drat, I thought had cleaned this up. This seems to happen when the last call to sync doesn't fully complete, or more file system activity comes in after the call to sync. This gets back to the problem of there not really being a way to check for activity in the file systen. Do you have a specific circumstance that causes the failure or is it rather random? From owner-linux-xfs@oss.sgi.com Fri Sep 8 11:18:43 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 11:18:33 -0700 Received: from hermes.mixx.net ([212.84.196.2]:16654 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 8 Sep 2000 11:18:22 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 14DBAF809 for ; Fri, 8 Sep 2000 20:18:21 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id C7F492CA6D; Fri, 8 Sep 2000 20:18:20 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs as root fs Date: 8 Sep 2000 18:18:20 GMT Organization: innominate AG, Berlin, Germany Lines: 43 Distribution: local Message-ID: References: <200009081540.KAA18672@jen.americas.sgi.com> <39B92B33.7ACC80D2@thebarn.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968437100 25988 10.0.0.69 (8 Sep 2000 18:18:20 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: >> > OK, this is a red herring, these were files from the lost+found on the root >> > filesystem, so xfs_repair removed its lost+found to start with, so it was >> > not finding anything wrong really. >> >> > This basically says that after cloning a root the lost+found directory in >> > the xfs filesystem needs to be cleaned. >> >> hmmm in my cases the files were real (just on several real machines >> i get it after some time of use) - i also usually do an >> >> xfs_repair >> mount >> rm -rf lost+found >> xfs_repair <- is fine now >> umount >> reboot >> >> so - it is not the lost+found dir in my case ... >> > Drat, I thought had cleaned this up. > This seems to happen when the last call to sync doesn't fully complete, > or more file system activity comes in after the call to sync. > This gets back to the problem of there not really being a way to check for > activity in the file systen. > Do you have a specific circumstance that causes the failure or is it > rather random? due to my experience i had it nearly everytime when i checked ... i may reboot and check this machine in a few minutes and see and maybe send you the xfs_repair output ... so a few minutes from now ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 11:19:03 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 11:18:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54625 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 11:18:26 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA06339; Fri, 8 Sep 2000 11:25:00 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA83457; Fri, 8 Sep 2000 11:17:54 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA79515; Fri, 8 Sep 2000 11:16:37 -0700 (PDT) Date: Fri, 8 Sep 2000 11:16:37 -0700 (PDT) Message-Id: <200009081816.LAA79515@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: ADD 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: tduffy@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 Assigned Engineer : lord Submitter : ananth *Modified User : ananth *Modified User Domain : engr *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: ananth@engr (BugWorks) Date: Sep 08 2000 11:16:37AM ========================== The system, "waco.engr", has got into the wierd state, where one rm is hung on XXX_grant_log_space(). Console on telnet b30-3c-linux-annex 5002. Couple of "vi" processes are also hung trying to access files on /build1, the only xfs file system on the machine ... Waco is running the alpha bits built as of last saturday (09/02/00) ... ananth. From owner-linux-xfs@oss.sgi.com Fri Sep 8 11:30:34 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 11:30:14 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:26654 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 11:29:49 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA20605; Fri, 8 Sep 2000 11:22:08 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA55979; Fri, 8 Sep 2000 11:29:47 -0700 (PDT) Date: Fri, 8 Sep 2000 11:29:47 -0700 (PDT) Message-Id: <200009081829.LAA55979@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: tduffy@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 Assigned Engineer : lord Submitter : ananth *Modified User : lord *Modified User Domain : sgi.com *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 08 2000 11:29:46AM ========================== OK, I did grab some info before I managed some pilot error which crashed the debugger - damn! [0]kdb> btp 30128 EBP EIP Function(args) 0xc81d1e00 0xc0119bdd schedule+0x415 (0xf4b67e10) kernel .text 0xc0100000 0xc01197c8 0xc011a1b0 0xc81d1e3c 0xf8883bf5 [xfs]_sv_wait+0xcd (0xf4b67e10, 0xf7cee114, 0x282, 0x0, 0x0) xfs .text 0xf8830060 0xf8883b28 0xf8883c10 0xc81d1e68 0xf8867fa5 [xfs]xlog_grant_log_space+0x139 (0xf7cee080, 0xf4b67e10, 0xf72d7c00, 0x58b70, 0xf7cee080) xfs .text 0xf8830060 0xf8867e6c 0xf88680d0 0xc81d1ea0 0xf8866587 [xfs]xfs_log_reserve+0x7b (0xf72d7c00, 0x2abb8, 0x2, 0xef1b0bf4, 0x69) xfs .text 0xf8830060 0xf886650c 0xf8866594 0xc81d1ecc 0xf887391a [xfs]xfs_trans_reserve+0x76 (0xef1b0bc0, 0x0, 0x2abb8, 0x0, 0x4) xfs .text 0xf8830060 0xf88738a4 0xf88739c4 0xc81d1f24 0xf887a0b6 [xfs]xfs_inactive+0x1ca (0xedaf6324, 0x0) xfs .text 0xf8830060 0xf8879eec 0xf887a2fc 0xc81d1f3c 0xf888906f [xfs]vn_put+0x47 (0xc88305a0) xfs .text 0xf8830060 0xf8889028 0xf88890a8 0xc81d1f4c 0xf8883622 [xfs]linvfs_d_iput+0x1a (0xe8e64be0, 0xc88304c0) xfs .text 0xf8830060 0xf8883608 0xf8883640 0xc81d1f64 0xc01477eb d_delete+0x57 (0xe8e64be0) kernel .text 0xc0100000 0xc0147794 0xc0147830 0xc81d1f80 0xc0141c07 vfs_unlink+0x18b (0xc8830640, 0xe8e64be0) kernel .text 0xc0100000 0xc0141a7c 0xc0141c20 0xc81d1fbc 0xc0141cbb sys_unlink+0x9b (0x805115b, 0xbffff240, 0xbffff02c, 0x0, 0x805115b) kernel .text 0xc0100000 0xc0141c20 0xc0141d34 [0]more> 0xc010a860 system_call+0x34 kernel .text 0xc0100000 0xc010a82c 0xc010a864 [0]kdb> [0]kdb> xlog 0xf7cee080 xlog at 0xf7cee080 &flushsm: 0xf7cee080 tic_cnt: 99 tic_tcnt: 102 freelist: 0xf4b67c30 tail: 0xf4b67af0 ICLOG: 0xf4b70000 &icloglock: 0xf7cee0b4 tail_lsn: 0x5b300001e90 last_sync_lsn: 0x5b400001bc5 mp: 0xf72d7c00 xbuf: 0xf732be40 roundoff: 3292 l_covered_state: need flags: log 0x0 <> dev: 0x811 logBBstart: 7962656 logsize: 4915200 logBBsize: 9600 curr_cycle: 1460 prev_cycle: 1460 curr_block: 7119 prev_block: 7109 iclog_bak: 0xf7cee104 iclog_size: 0x8000 (32768) num iclogs: 2 &grant_lock: 0xf7cee114 resHeadQ: 0xf4b67e10 wrHeadQ: 0x00000000 GResCycle: 1460 GResBytes: 3644348 GWrCycle: 1460 GWrBytes: 3644348 GResBlocks: 7124 GResRemain: 152 GWrBlocks: 7124 GWrRemain: 152 [0]kdb> xmount 0xf72d7c00 xfs_mount at 0xf72d7c00 vfsp 0xf7621920 tid 0x0 ail_lock 0xf72d7c14 &ail 0xf72d7c18 ail_gen 0x14f86a &sb 0xf72d7c24 sb_lock 0xf72d7cec sb_bp 0xf732bee0 dev 0x811 logdev 0x811 rtdev 0x0 bsize 8 agfrotor 2 agirotor 4 ihash 0xf5b78000 ihsize 332 inodes 0xe86dd930 ilock 0xf72d7d14 ireclaims 0x10431 readio_log 0x10 readio_blocks 0x10 writeio_log 0x10 writeio_blocks 0x10 logbufs -1 logbsize -1 LOG 0xf7cee080 rsumlevels 0x0 rsumsize 0x0 rbmip 0x00000000 rsumip 0x00000000 rootip 0xf5a10c88 dircook_elog 0 blkbit_log 15 blkbb_log 3 agno_log 4 agino_log 22 nreadaheads 4 inode cluster size 8192 blockmask 0xfff blockwsize 0x400 blockwmask 0x3ff alloc_mxr[lf,nd] 510 340 alloc_mnr[lf,nd] 255 170 bmap_dmxr[lfnr,ndnr] 254 254 bmap_dmnr[lfnr,ndnr] 127 127 inobt_mxr[lf,nd] 255 510 inobt_mnr[lf,nd] 127 255 ag_maxlevels 3 bm_maxlevels[d,a] 5 3 in_maxlevels 3 perag 0xf7cee180 &peraglock 0xf72d7dd8 &growlock 0xf72d7e00 flags 0x0 <> ialloc_inos 64 ialloc_blks 4 litino 156 attroffset 120 da_node_ents 510 maxicount 8957888 inoalign_mask 1 resblks 0 resblks_avail 0 inoadd 0quotaflags 0x0 <> dalign 0 swidth 0 sinoalign 0 attr_magicpct 1515 dir_magicpct 1515 mk_sharedro 0 dirversion 2 dirblkfsbs 1 &dirops 0xf72d7ecc dirblksize 4096 dirdatablk 0x0 dirleafblk 0x800000 dirfreeblk 0x1000000 chsize 37 chash 0xf72dca00 mountpoint "sd(8,17)" Unfortunately the command I really wanted to see the output of I gave the wrong address to and it died on me - the machine will need a reset and I will need another occurrence, sorry about that. From owner-linux-xfs@oss.sgi.com Fri Sep 8 11:30:34 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 11:30:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:33310 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 11:30:03 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA20657 for ; Fri, 8 Sep 2000 11:22:23 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA25308; Fri, 8 Sep 2000 13:27:29 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id NAA25263; Fri, 8 Sep 2000 13:27:28 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e88IRQe10251; Fri, 8 Sep 2000 13:27:27 -0500 Message-ID: <39B92F8D.1E732EAE@thebarn.com> Date: Fri, 08 Sep 2000 13:27:25 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: xfs as root fs References: <200009081540.KAA18672@jen.americas.sgi.com> <39B92B33.7ACC80D2@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > Russell Cattelan wrote: > >> > OK, this is a red herring, these were files from the lost+found on the root > >> > filesystem, so xfs_repair removed its lost+found to start with, so it was > >> > not finding anything wrong really. > >> > >> > This basically says that after cloning a root the lost+found directory in > >> > the xfs filesystem needs to be cleaned. > >> > >> hmmm in my cases the files were real (just on several real machines > >> i get it after some time of use) - i also usually do an > >> > >> xfs_repair > >> mount > >> rm -rf lost+found > >> xfs_repair <- is fine now > >> umount > >> reboot > >> > >> so - it is not the lost+found dir in my case ... > >> > > > Drat, I thought had cleaned this up. > > > This seems to happen when the last call to sync doesn't fully complete, > > or more file system activity comes in after the call to sync. > > This gets back to the problem of there not really being a way to check for > > activity in the file systen. > > > Do you have a specific circumstance that causes the failure or is it > > rather random? > > due to my experience i had it nearly everytime when i checked ... > i may reboot and check this machine in a few minutes and see and > maybe send you the xfs_repair output ... so a few minutes from > now ... > I'll restart my xfs root fs machine with the latest build... see what happens. Maybe it's a recent change. From owner-linux-xfs@oss.sgi.com Fri Sep 8 11:41:35 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 11:41:16 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49764 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 11:40:42 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA06445; Fri, 8 Sep 2000 11:47:16 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA02306; Fri, 8 Sep 2000 11:40:40 -0700 (PDT) Date: Fri, 8 Sep 2000 11:40:40 -0700 (PDT) Message-Id: <200009081840.LAA02306@info.engr.sgi.com> X-Pv-Incident: 768238 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: ADD 768238 - Volume Manager work for XFS on Linux To: n8992@sgi.com Cc: slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=768238 Status : open Priority : 1 Assigned Engineer : n8992 Submitter : mostek *Modified User : cattelan *Modified User Domain : engr *Description : The interactions between XFS and volume managers on Linux need to be investigated, designed, and implemented. This includes enhancing slinx-xfs/cmd/xfs/sim/src/libdisk.c to also deal with volume managers. i. Install LVM on a machine and integrate with XFS. ii. Install/configure md on a machine and integrate with XFS. iii. port xlv_get_subvolumes() to a more generic routine and implement to handle multiple Linux volume managers. iv. libdisk needs to: ..... ========================== ADDITIONAL INFORMATION (ADD) From: cattelan@engr (BugWorks) Date: Sep 08 2000 11:40:40AM ========================== Latest LVM related error. occured during the untar phase of rpm -bc glibc I/O Error Detected. Shutting down filesystem: lvm(58,0) Please umount the filesystem, and rectify the problem(s) PCD: pagebuf_bmap error -5 pb_flags 0x10010002 PCD: pagebuf_bmap error -5 pb_flags 0x10010002 PCD: pagebuf_bmap error -5 pb_flags 0x10010002 PCD: pagebuf_bmap error -5 pb_flags 0x10010002 PCD: pagebuf_bmap error -5 pb_flags 0x10010002 PCD: pagebuf_bmap error -5 pb_flags 0x10010002 PCD: pagebuf_bmap error -5 pb_flags 0x10010002 PCD: pagebuf_bmap error -5 pb_flags 0x10010002 PCD: pagebuf_bmap error -5 pb_flags 0x10010002 From owner-linux-xfs@oss.sgi.com Fri Sep 8 11:49:06 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 11:48:46 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:20005 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 11:48:30 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA24236 for ; Fri, 8 Sep 2000 11:40:27 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA26324 for ; Fri, 8 Sep 2000 13:45:35 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA82845 for ; Fri, 8 Sep 2000 13:45:34 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA22873; Fri, 8 Sep 2000 13:44:14 -0500 Message-Id: <200009081844.NAA22873@jen.americas.sgi.com> Date: Fri, 8 Sep 2000 13:44:14 -0500 Subject: TAKE - fix log zeroing off by one error in repair To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The blocks zeroed by xfs_repair were offset by 1 in the internal log case, this would cause problems if a filesystem was repaired, then mounted, then mounted again after some activity. The second mount would fail panicing the system, provided the log had not been completely written over during the first mount. Date: Fri Sep 8 11:42:11 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74012a cmd/xfs/repair/phase2.c - 1.30 - Fix log zeroing in repair - it was starting out one block too early for an internal log. This could do two things, zero out part of a valid filesystem block, and make recovery fail on the second mount after repair was run in some cases. From owner-linux-xfs@oss.sgi.com Fri Sep 8 12:25:35 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 12:25:25 -0700 Received: from hermes.mixx.net ([212.84.196.2]:52239 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 8 Sep 2000 12:25:03 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 74588F80D for ; Fri, 8 Sep 2000 21:25:01 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 35B862CA6D; Fri, 8 Sep 2000 21:25:01 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: mkfs.xfs & xfs_repair crashing? Date: 8 Sep 2000 19:25:01 GMT Organization: innominate AG, Berlin, Germany Lines: 28 Distribution: local Message-ID: References: <200009081429.JAA15622@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968441101 27875 10.0.0.69 (8 Sep 2000 19:25:01 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> has anybody else seen mkfs.xfs and xfS_repair crashing? >> >> i yesterday updated my home machine to the latest xfs code and >> tar'ed together the root dir - mkfs.xfs'ed with the new (libxfs) >> mkfs.xfs and it crashed (core dumped) on it - so i did it with >> the old (sim based) mkfs.xfs and it worked but on that fresh >> filesystem the new xfs_repair core-dumped ... the old xfS_repair >> worked ... has anybody else seen this behaviour with the latest >> code (it was absolutely reproducable for me)? > The latest commands worked for me - I always do a make clean realclean > when rebuilding commands, could you try this. Also, if the problem is > still there, can you send us a backtrace from the core dump. ok - did a realclean and rebuilt all and now it works - so maybe the makefiles do not pick up all the dependencies correctly? at least this problem seems to be solved - will check the mkfs.xfs later too - but i'm quite positive that this works now too t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 12:31:15 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 12:31:06 -0700 Received: from hermes.mixx.net ([212.84.196.2]:62735 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 8 Sep 2000 12:30:46 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 4B9DCF810 for ; Fri, 8 Sep 2000 21:30:44 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id E229F2CA6D; Fri, 8 Sep 2000 21:30:43 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs as root fs Date: 8 Sep 2000 19:30:43 GMT Organization: innominate AG, Berlin, Germany Lines: 21 Distribution: local Message-ID: References: <200009081540.KAA18672@jen.americas.sgi.com> <39B92B33.7ACC80D2@thebarn.com> <39B92F8D.1E732EAE@thebarn.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968441443 27875 10.0.0.69 (8 Sep 2000 19:30:43 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: >> due to my experience i had it nearly everytime when i checked ... >> i may reboot and check this machine in a few minutes and see and >> maybe send you the xfs_repair output ... so a few minutes from >> now ... > I'll restart my xfs root fs machine with the latest build... see what happens. > Maybe it's a recent change. hmmm - schroedingers cat - i just tried to reproduce it and now it works all time ... so if you have other things to work on just ignore this one until i have reproduced it better and can give you some more details about it t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Sep 8 12:34:46 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 12:34:37 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5684 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 12:34:22 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA02458 for ; Fri, 8 Sep 2000 12:26:42 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA37219; Fri, 8 Sep 2000 14:33:04 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA01163; Fri, 8 Sep 2000 14:33:03 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id OAA25676; Fri, 8 Sep 2000 14:31:43 -0500 Message-Id: <200009081931.OAA25676@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs & xfs_repair crashing? In-Reply-To: Message from Thomas Graichen of "08 Sep 2000 19:25:01 GMT." Date: Fri, 08 Sep 2000 14:31:43 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > >> has anybody else seen mkfs.xfs and xfS_repair crashing? > >> > >> i yesterday updated my home machine to the latest xfs code and > >> tar'ed together the root dir - mkfs.xfs'ed with the new (libxfs) > >> mkfs.xfs and it crashed (core dumped) on it - so i did it with > >> the old (sim based) mkfs.xfs and it worked but on that fresh > >> filesystem the new xfs_repair core-dumped ... the old xfS_repair > >> worked ... has anybody else seen this behaviour with the latest > >> code (it was absolutely reproducable for me)? > > > The latest commands worked for me - I always do a make clean realclean > > when rebuilding commands, could you try this. Also, if the problem is > > still there, can you send us a backtrace from the core dump. > > ok - did a realclean and rebuilt all and now it works - so maybe > the makefiles do not pick up all the dependencies correctly? > > at least this problem seems to be solved - will check the mkfs.xfs > later too - but i'm quite positive that this works now too To be honest, I do not believe there is a dependency check in the command make files. Steve p.s. I am now running netscape on a machine with / and /usr both in XFS and my home directory nfs cross mounted. The cross mounting is from Irix though. netscape appears to be functioning just fine. From owner-linux-xfs@oss.sgi.com Fri Sep 8 13:38:56 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 13:38:36 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:34884 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 13:38:03 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA10747 for ; Fri, 8 Sep 2000 13:30:22 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id PAA49733; Fri, 8 Sep 2000 15:36:43 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id PAA04540; Fri, 8 Sep 2000 15:36:42 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e88Kage15232; Fri, 8 Sep 2000 15:36:42 -0500 Message-ID: <39B94DD8.4D248B2B@thebarn.com> Date: Fri, 08 Sep 2000 15:36:40 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: xfs as root fs References: <200009081540.KAA18672@jen.americas.sgi.com> <39B92B33.7ACC80D2@thebarn.com> <39B92F8D.1E732EAE@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > Russell Cattelan wrote: > >> due to my experience i had it nearly everytime when i checked ... > >> i may reboot and check this machine in a few minutes and see and > >> maybe send you the xfs_repair output ... so a few minutes from > >> now ... > > > I'll restart my xfs root fs machine with the latest build... see what happens. > > Maybe it's a recent change. > > hmmm - schroedingers cat - i just tried to reproduce it and now it > works all time ... so if you have other things to work on just > ignore this one until i have reproduced it better and can > give you some more details about it Try this patch... it may help. This will issue another round of trying to sync the fs to a clean state. In talking with Steve about this, it may be possible for xfs inodes to not completely be flushed out after the first sync, hopefully the second one will catch the rest of the clean up necessary. *** /usr/tmp/TmpDir.15204-0/linux/fs/xfs/linux/xfs_super.c_1.86 Fri Sep 8 15:31:09 2000 --- linux/fs/xfs/linux/xfs_super.c Fri Sep 8 14:44:54 2000 *************** *** 565,570 **** --- 565,573 ---- PVFS_SYNC(vfsp->vfs_fbhv, SYNC_ATTR|SYNC_WAIT|SYNC_CLOSE, sys_cred, error); + PVFS_SYNC(vfsp->vfs_fbhv, + SYNC_ATTR|SYNC_WAIT|SYNC_CLOSE, + sys_cred, error); if (error) { sb->s_flags=save; printk("XFS: Failed to sync for read-only remount\n"); From owner-linux-xfs@oss.sgi.com Fri Sep 8 13:47:55 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 13:47:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:62790 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 13:47:31 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA11979; Fri, 8 Sep 2000 13:39:50 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA71340; Fri, 8 Sep 2000 13:47:27 -0700 (PDT) Date: Fri, 8 Sep 2000 13:47:27 -0700 (PDT) Message-Id: <200009082047.NAA71340@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: getafix.engr.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (chait@engr.sgi.com) Subject: ADD 800850 - XFS + CONFIG_HIGHMEM4GB bug To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 Status : open Priority : 2 Assigned Engineer : lord Submitter : dxm *Modified User : chait *Modified User Domain : engr *Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (ADD) From: chait@engr (BugWorks) Date: Sep 08 2000 01:47:26PM ========================== I've been able to reliably reproduce Daniel's oops with highmem at xfs_itobp() on "sierra" running stress test 013. I've tried Steve's suggested check for trapping unmapped metadata pages in page_buf.c and his check doesn't fire. Any other ideas? Thanks, -Chait. From owner-linux-xfs@oss.sgi.com Fri Sep 8 13:47:55 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 13:47:35 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62578 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 13:47:30 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA07678; Fri, 8 Sep 2000 13:54:04 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA40435; Fri, 8 Sep 2000 13:47:27 -0700 (PDT) Date: Fri, 8 Sep 2000 13:47:27 -0700 (PDT) Message-Id: <200009082047.NAA40435@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: getafix.engr.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (chait@engr.sgi.com) Subject: ADD 800850 - XFS + CONFIG_HIGHMEM4GB bug To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 Status : open Priority : 2 Assigned Engineer : lord Submitter : dxm *Modified User : chait *Modified User Domain : engr *Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (ADD) From: chait@engr (BugWorks) Date: Sep 08 2000 01:47:26PM ========================== I've been able to reliably reproduce Daniel's oops with highmem at xfs_itobp() on "sierra" running stress test 013. I've tried Steve's suggested check for trapping unmapped metadata pages in page_buf.c and his check doesn't fire. Any other ideas? Thanks, -Chait. From owner-linux-xfs@oss.sgi.com Fri Sep 8 13:52:35 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 13:52:25 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24435 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 13:52:17 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA03952; Fri, 8 Sep 2000 13:58:51 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA85152; Fri, 8 Sep 2000 13:52:15 -0700 (PDT) Date: Fri, 8 Sep 2000 13:52:15 -0700 (PDT) Message-Id: <200009082052.NAA85152@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800850 - XFS + CONFIG_HIGHMEM4GB bug To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 Status : open Priority : 2 Assigned Engineer : lord Submitter : dxm *Modified User : lord *Modified User Domain : sgi.com *Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 08 2000 01:52:14PM ========================== > I've been able to reliably reproduce Daniel's oops with highmem > at xfs_itobp() on "sierra" running stress test 013. I've tried > Steve's suggested check for trapping unmapped metadata pages > in page_buf.c and his check doesn't fire. > > Any other ideas? Wait for me to get around to this bug would be one ..... Another would be to change xfs_itobp a little so that it prints out the pagebuf pointer in this case - i.e. if page_buf_offset returns zero then print the pagebuf pointer before continuing and dying. Make sure you have the page_buf kdbm module loaded and then dump the pagebuf and kiobuf contents into the PV. From owner-linux-xfs@oss.sgi.com Fri Sep 8 14:09:25 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 14:09:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:65357 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 14:09:02 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA15342; Fri, 8 Sep 2000 14:01:22 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA38455; Fri, 8 Sep 2000 14:09:00 -0700 (PDT) Date: Fri, 8 Sep 2000 14:09:00 -0700 (PDT) Message-Id: <200009082109.OAA38455@info.engr.sgi.com> X-Pv-Incident: 795642 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: REASSIGN 795642 - remount -o remount,ro doesn't leave FS consistent To: cattelan@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=795642 Status : open Priority : 3 *Assigned Engineer : cattelan *Assigned Domain : engr Submitter : dxm Project : xfs-linux *Assigned Group : xfs-linux Opened Date : 07/06/00 *Modified User : cattelan *Modified User Domain : engr *Description : Remounting an XFS filesystem R/O can leave the FS in an inconsistent state. (Playing with this for long enough can hang mount up...) Reproduce with QA 013 or: #!/bin/sh DEV=/dev/hda6 MNT=/mnt/arch0 ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: cattelan@engr (BugWorks) Date: Sep 08 2000 02:08:59PM ========================== From owner-linux-xfs@oss.sgi.com Fri Sep 8 15:36:56 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 15:36:46 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:8035 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 15:36:32 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA25761; Fri, 8 Sep 2000 15:28:51 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA87915; Fri, 8 Sep 2000 15:36:30 -0700 (PDT) Date: Fri, 8 Sep 2000 15:36:30 -0700 (PDT) Message-Id: <200009082236.PAA87915@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Status : open Priority : 3 Assigned Engineer : nathans Submitter : lord *Modified User : lord *Modified User Domain : sgi.com *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 08 2000 03:36:29PM ========================== Here is what is happening here. There are some tables in the kernel which record the size of devices in sectors and the block size used by a filesystem. The block character device uses these to device if an I/O is in or out of range on the device. So it takes the device size in raw 512 byte sectors and converts it to bytes. It then shifts it down to be in terms of the filesystem blocksize. When ext2 is mounted on a device it changes the block size to be whatever its mkfs block size was. 4K in my case. The end result is that internally the end of the device gets rounded down to a 4 K boundary. All checks in the code are based on a block address version of the offset specified by the file pointer - so again rounded down to a 4 K boundary. There is then a check for this block being >= the size of the device. An error is returned if this happens. See block_write in fs/block_dev.c for details. There are a few ways to fudge this: 1. repeat the same calculation in libxfs to reduce the size of the partition we tell mkfs about - problem is there is no call to get this block size value out of the kernel. 2. reset the block size to the hardware sector size - the only way I can see to do this is to use the raw device interface. 3. mask off some bits in the size to round it down. By masking off 3 bits I can make this work. 2 would be best if we could figure out how to do it. We can skip doing the write of the zeros over the last block, but we want to write to the end of an external log - this could hit the same issue. From owner-linux-xfs@oss.sgi.com Fri Sep 8 15:51:45 2000 Received: by oss.sgi.com id ; Fri, 8 Sep 2000 15:51:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:16998 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 8 Sep 2000 15:51:03 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA27295; Fri, 8 Sep 2000 15:43:23 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA68700; Fri, 8 Sep 2000 15:51:01 -0700 (PDT) Date: Fri, 8 Sep 2000 15:51:01 -0700 (PDT) Message-Id: <200009082251.PAA68700@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: getafix.engr.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (chait@engr.sgi.com) Subject: ADD 800850 - XFS + CONFIG_HIGHMEM4GB bug To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 Status : open Priority : 2 Assigned Engineer : lord Submitter : dxm *Modified User : chait *Modified User Domain : engr *Description : Enabling CONFIG_HIGHMEM4GB on bruce (a 1400), then running QA trips the following BUG() in QA 001: kernel BUG at highmem.c:231! Entering kdb (0xf6eec000) on processor 0 Panic: invalid operand due to panic @ 0xc013077b eax = 0x0000001d ebx = 0xfe268000 ecx = 0xc02b406c edx = 0x00000028 esi = 0x00000000 edi = 0xc2055790 esp = 0xf6eedda0 eip = 0xc013077b ebp = 0xf6eeddb4 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ..... ========================== ADDITIONAL INFORMATION (ADD) From: chait@engr (BugWorks) Date: Sep 08 2000 03:51:00PM ========================== Interesting....I'm seeing the highmem oops occur also via xfs_bulkstat() invoking xfs_itobp(). The trace below is via a call to xfs_itobp() from xfs_sync() as in Daniel's trace. I've included info. about the offending pagebuf/kiobuf/pages. Lemme know if you need more information. -Chait. pagebuf_offset(): Highmem page at 0xc2029984 xfs_itobp(): pagebuf_offset() shoulda found highmem page! pagebuf ptr = 0xe9c80400 Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c01a7785 *pde = 00000000 Entering kdb (current=0xe9bba000, pid 1228) on processor 0 Panic: Oops due to panic @ 0xc01a7785 eax = 0x00000019 ebx = 0xea100000 ecx = 0xc038820c edx = 0x00000000 esi = 0x00000000 edi = 0x00000000 esp = 0xe9bbbe88 eip = 0xc01a7785 ebp = 0xe9bbbebc ss = 0x00000018 cs = 0x00000010 eflags = 0x00010296 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xe9bbbe54 [0]kdb> bt EBP EIP Function(args) 0xe9bbbebc 0xc01a7785 xfs_itobp+0x175 (0xea100000, 0x0, 0xe9bfd100, 0xe9bbbf38, 0xe9bbbf3c) kernel .text 0xc0100000 0xc01a7610 0xc01a780c 0xe9bbbf54 0xc01beddb xfs_syncsub+0x4e3 (0xea100000, 0x31, 0x0, 0x0) kernel .text 0xc0100000 0xc01be8f8 0xc01bf3f0 0xe9bbbf6c 0xc01be8f2 xfs_sync+0x16 (0xea100000, 0x31, 0xc0407480) kernel .text 0xc0100000 0xc01be8dc 0xc01be8f8 0xe9bbbf84 0xc01cef0e linvfs_write_super+0x2a (0xf7bfe400) kernel .text 0xc0100000 0xc01ceee4 0xc01cef1c 0xe9bbbf98 0xc0135b08 sync_supers+0x6c (0x0) kernel .text 0xc0100000 0xc0135a9c 0xc0135b30 0xe9bbbfb0 0xc0131a53 fsync_dev+0x3f (0x0) kernel .text 0xc0100000 0xc0131a14 0xc0131aa8 0xe9bbbfbc 0xc0131ab2 sys_sync+0xa (0x804ec08, 0x7213b053, 0x7213b053, 0x4000ae60, 0xbffffa14) kernel .text 0xc0100000 0xc0131aa8 0xc0131ab8 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [0]kdb> pb 0xe9c80400 page_buf_t at 0xe9c80400 pb_flags ASYNC DELWRI LONG_TERM LOCK LOCKABLE ALL_PAGES_MAPPED MEM_ALLOCATED pb_target 0xe9bfe1e0 pb_hold 2 pb_next 0xe9cd9660 pb_prev 0xe9cd93e0 pb_file_offset 0x44228000 pb_buffer_length 0x2000 pb_addr 0x00000000 pb_bn 0x221140 pb_count_desired 0x2000 pb_io_remaining 0 pb_error 0 pba_kiovec[0] 0xe9cd8a80 pba_kiocnt 1 pb_iodonesema (0,0) pb_sema (0,0) pincount (0) last holder 0xe9bba000 pb_fspriv 0xe9ca1f18 pb_fspriv2 0x00000000 [0]kdb> kiobuf 0xe9cd8a80 kiobuf at 0xe9cd8a80 nr_pages 2 array_len 17 offset 0x0 length 0x2000 errno 0 pb 0x00000000 page_struct page_addr cnt flags 0xc2029984 0x0 2 0x100c 0xc2029940 0x0 2 0x100c [0]kdb> page 0xc2029984 struct page at 0xc2029984 next 0xc20299c8 prev 0xc2029940 addr space 0xe9bfe27c index 279080 (offset 0x44228000) count 2 flags PG_referenced PG_uptodate PG_highmem virtual 0x0 buffers 0x00000000 block_map 11111111000000000000000000000000 [0]kdb> page 0xc2029940 struct page at 0xc2029940 next 0xc2029984 prev 0xc1b03260 addr space 0xe9bfe27c index 279081 (offset 0x44229000) count 2 flags PG_referenced PG_uptodate PG_highmem virtual 0x0 buffers 0x00000000 block_map 11111111000000000000000000000000 [0]kdb> From owner-linux-xfs@oss.sgi.com Sat Sep 9 11:04:09 2000 Received: by oss.sgi.com id ; Sat, 9 Sep 2000 11:03:59 -0700 Received: from smtp1.cern.ch ([137.138.128.38]:23312 "EHLO smtp1.cern.ch") by oss.sgi.com with ESMTP id ; Sat, 9 Sep 2000 11:03:31 -0700 Received: from pcrd10.cern.ch (pcrd10.cern.ch [137.138.29.237]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id UAA27537; Sat, 9 Sep 2000 20:03:26 +0200 (MET DST) Received: (from fuji@localhost) by pcrd10.cern.ch (8.9.3/8.9.3) id UAA31143; Sat, 9 Sep 2000 20:02:56 +0200 Date: Sat, 9 Sep 2000 20:02:56 +0200 From: Peter.Kelemen@cern.ch To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: XFS assertion failed: vp->v_bh.bh_first != NULL Message-ID: <20000909200256.B30987@pcrd10.cern.ch> Reply-To: Peter.Kelemen@cern.ch References: <20000903211728.C3797@pcrd10.cern.ch> <17574.968018229@ocs3.ocs-net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i X-Beat: @793 In-Reply-To: <17574.968018229@ocs3.ocs-net>; from kaos@melbourne.sgi.com on Mon, Sep 04, 2000 at 08:57:09AM +1100 Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, 2000-09-04 08:57:09 +1100, Keith Owens wrote: > klogd has got in first and stamped on the trace, got it wrong > and left no useful trace data for ksymoops. Can you change > klogd to run as "klogd -x" and reproduce the problem? -x stops > klogd attempting to translate the oops log, I change it in > /etc/rc.d/init.d/syslog then /etc/rc.d/init.d/syslog restart. All right, while hunting another oops[1], I reproduced the vnode-crash situation. Attached is the oops (copied by hand) processed by ksymoops. Keith, your tip with "klogd -x" didn't help---it simply dies in case of an oops and nothing gets logged. Can anyone enlighten me please, what's this f000000 in the call trace? Peter [1] "XFS assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: xfs_vnodeops.c, line: 5415" Unfortunately the oops text is lost (the kernel did not lock up completely, but there was no response to keyboard/mouse events, and the blanker kicked in---it's handy to have setterm -blank 0 when you're copying an oops by hand...) -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="oops.vnode.ksym" ksymoops 0.7c on i686 2.4.0-test5-jumbofs. Options used -v /w/fuji/build/cvs/linux-2.4-xfs/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test5-jumbofs/ (default) -m /boot/System.map-2.4.0-test5-jumbofs (specified) No modules in ksyms, skipping objects CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 0000001e ebx: cb9264a0 ecx: c030720c edx: 00000000 esi: cb9264a0 edi: cb9264a0 ebp: cfd3f9d0 esp: cfd3f9c4 ds: 0018 es: 0018 ss: 0018 Process dbench (pid: 602, stackpage=cfd3f000) Stack: c02d045a c02d044e 00000032 cfd3fa60 c01eb3e8 c02d39a0 c02d3759 000001e8 00000009 cb9264a0 cb9264a0 14003fff cfd3fae4 bd1d6000 00000282 cb9264a0 cb9264a0 cb9264a0 cfd3fa5c c01eb86b c5bd75a4 00000002 c02c69b1 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 89 ec 5d c3 90 55 89 e5 81 ec 00 01 00 00 56 53 8b 45 >>EIP; c01e10d9 <===== Trace; c02d045a Trace; c02d044e Trace; c01eb3e8 Trace; c02d39a0 Trace; c02d3759 Trace; c01eb86b Trace; c02c69b1 Trace; c01b1a9a Trace; c01b1440 Trace; c01b1a10 Trace; c01b1a9a Trace; c01eaf69 Trace; c01e9e2c Trace; c0146965 Trace; c0146bf5 Trace; c01eb14c Trace; c01b13ba Trace; f0000000 Trace; c01b1a61 Trace; c01d1fc8 Trace; c01b4203 Trace; c01d8d7f Trace; c01d3304 Trace; c01d8ec9 Trace; c01b8d3c Trace; c01bb747 Trace; c01eb80b Trace; c02ce936 Trace; c01d61a3 Trace; c01cff0f Trace; c01e3314 Trace; c01eb80b Trace; c01e3404 Trace; c013ed20 Trace; c013eeba Trace; c0132076 Trace; c01323b2 Trace; c010a73c Code; c01e10d9 00000000 <_EIP>: Code; c01e10d9 <===== 0: 0f 0b ud2a <===== Code; c01e10db 2: 89 ec movl %ebp,%esp Code; c01e10dd 4: 5d popl %ebp Code; c01e10de 5: c3 ret Code; c01e10df 6: 90 nop Code; c01e10e0 7: 55 pushl %ebp Code; c01e10e1 8: 89 e5 movl %esp,%ebp Code; c01e10e3 a: 81 ec 00 01 00 00 subl $0x100,%esp Code; c01e10e9 10: 56 pushl %esi Code; c01e10ea 11: 53 pushl %ebx Code; c01e10eb 12: 8b 45 00 movl 0x0(%ebp),%eax --+QahgC5+KEYLbs62-- From owner-linux-xfs@oss.sgi.com Sat Sep 9 12:03:10 2000 Received: by oss.sgi.com id ; Sat, 9 Sep 2000 12:03:00 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:4370 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Sat, 9 Sep 2000 12:02:46 -0700 Received: (qmail 7965 invoked from network); 9 Sep 2000 19:02:40 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 9 Sep 2000 19:02:40 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Peter.Kelemen@cern.ch cc: linux-xfs@oss.sgi.com Subject: Re: XFS assertion failed: vp->v_bh.bh_first != NULL In-reply-to: Your message of "Sat, 09 Sep 2000 20:02:56 +0200." <20000909200256.B30987@pcrd10.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Sep 2000 06:02:39 +1100 Message-ID: <15897.968526159@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sat, 9 Sep 2000 20:02:56 +0200, Peter.Kelemen@cern.ch wrote: >All right, while hunting another oops[1], I reproduced the >vnode-crash situation. Attached is the oops (copied by hand) >processed by ksymoops. Keith, your tip with "klogd -x" didn't >help---it simply dies in case of an oops and nothing gets logged. I sent a patch to the sysklogd maintainer over a year ago, they said they would include it in the next release, no next release yet. ftp://ftp.ocs.com.au/pub/ksymoops/v2.3/patch-sysklogd-1-3-31-ksymoops-1.gz might help. >Can anyone enlighten me please, what's this f000000 in the call >trace? The kernel code that prints the i386 call trace is really simple minded. Scan up the stack, any word on the stack that looks remotely like a kernel address is printed. This is anything in the kernel text area or in the "vmalloc" area, defined on i386 as ending around 0xffffe000. This results in false positives, entries on the "call trace" that have nothing to do with the call. ksymoops just converts every address it is given. This simple minded method of printing the call trace is forced on us by the lack of a decent stack frame system on i386. If you really want to shudder, see the kdb code which does the reverse, it has a full unwind scheme for i386, full of special cases. In particular arch/i386/kdb/kdbasupport.c, kdba_find_return and kdba_prologue arch/i386/kdb/kdba_bt.c, kdba_bt_stack From owner-linux-xfs@oss.sgi.com Sun Sep 10 18:48:32 2000 Received: by oss.sgi.com id ; Sun, 10 Sep 2000 18:48:22 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12124 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 10 Sep 2000 18:48:09 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA04494; Sun, 10 Sep 2000 18:54:46 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA86977; Sun, 10 Sep 2000 18:48:06 -0700 (PDT) Date: Sun, 10 Sep 2000 18:48:06 -0700 (PDT) Message-Id: <200009110148.SAA86977@info.engr.sgi.com> X-Pv-Incident: 801246 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: REASSIGN 801246 - XFS on loopback mount doesn't work To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801246 Status : open Priority : 3 *Assigned Engineer : nb *Assigned Domain : sgi.com Submitter : dxm Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/07/00 *Modified User : dxm *Modified User Domain : engr *Description : Mike reminded me of this problem, so I've opened a bug. ========================== ADDITIONAL INFORMATION (REASSIGN) From: dxm@engr (BugWorks) Date: Sep 10 2000 06:48:06PM ========================== As far as I know, no one is working on this one. So since initially unassigned bugs end up with Neil, I'm reassigning it to him. From owner-linux-xfs@oss.sgi.com Sun Sep 10 19:08:02 2000 Received: by oss.sgi.com id ; Sun, 10 Sep 2000 19:07:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36700 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 10 Sep 2000 19:07:28 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA04259; Sun, 10 Sep 2000 19:14:05 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA85680; Sun, 10 Sep 2000 19:07:25 -0700 (PDT) Date: Sun, 10 Sep 2000 19:07:25 -0700 (PDT) Message-Id: <200009110207.TAA85680@info.engr.sgi.com> X-Pv-Incident: 801241 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 801241 - xfsdump can cause filesystem corruption To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801241 Status : open Priority : 1 Assigned Engineer : nb Submitter : ivanr *Modified User : dxm *Modified User Domain : engr *Description : QA for xfsdump/xfsrestore revealed that it is possible for xfsdump to cause filesystem corruption. The test involves creating a filesystem, creating a whole buncha files, xfsdumping them to a file somewhere, then removing all the files. xfs_check reports lots of inodes with zero link counts, etc. It's probably due to xfsdump using bulkstat on the entire fs. The following is a script which will reliably (at least on bruce.melbourne) produce the error. Run it in cmd/xfs/stress - it needs the src/fill program, and make sure you fix the ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 10 2000 07:07:25PM ========================== Note that the dump/restore tests that require a tape drive to run will just fake their output, so without an actual tape drive, QA 026, 027 and 028 are the way to go. 026 reliably causes corruption for me: *** xfs_check output *** agi unlinked bucket 3 is 131 in ag 0 agi unlinked bucket 4 is 132 in ag 0 agi unlinked bucket 5 is 133 in ag 0 agi unlinked bucket 0 is 128 in ag 1 agi unlinked bucket 1 is 129 in ag 1 agi unlinked bucket 2 is 130 in ag 1 agi unlinked bucket 3 is 131 in ag 1 agi unlinked bucket 4 is 132 in ag 1 agi unlinked bucket 5 is 133 in ag 1 agi unlinked bucket 6 is 134 in ag 1 agi unlinked bucket 7 is 135 in ag 1 agi unlinked bucket 8 is 136 in ag 1 agi unlinked bucket 9 is 137 in ag 1 agi unlinked bucket 10 is 138 in ag 1 agi unlinked bucket 11 is 139 in ag 1 agi unlinked bucket 12 is 140 in ag 1 agi unlinked bucket 13 is 141 in ag 1 agi unlinked bucket 14 is 142 in ag 1 agi unlinked bucket 15 is 143 in ag 1 agi unlinked bucket 16 is 144 in ag 1 agi unlinked bucket 17 is 145 in ag 1 agi unlinked bucket 18 is 146 in ag 1 agi unlinked bucket 19 is 147 in ag 1 agi unlinked bucket 20 is 148 in ag 1 agi unlinked bucket 21 is 149 in ag 1 agi unlinked bucket 22 is 150 in ag 1 agi unlinked bucket 23 is 151 in ag 1 agi unlinked bucket 24 is 152 in ag 1 agi unlinked bucket 25 is 153 in ag 1 agi unlinked bucket 26 is 154 in ag 1 agi unlinked bucket 27 is 155 in ag 1 agi unlinked bucket 28 is 156 in ag 1 agi unlinked bucket 29 is 157 in ag 1 agi unlinked bucket 30 is 158 in ag 1 agi unlinked bucket 31 is 159 in ag 1 agi unlinked bucket 32 is 160 in ag 1 agi unlinked bucket 33 is 161 in ag 1 agi unlinked bucket 34 is 162 in ag 1 link count mismatch for inode 128 (name ?), nlink 2, counted 3 link count mismatch for inode 131 (name ?), nlink 0, counted 2 allocated inode 132 has 0 link count allocated inode 133 has 0 link count link count mismatch for inode 131200 (name ?), nlink 0, counted 1 allocated inode 131201 has 0 link count allocated inode 131202 has 0 link count allocated inode 131203 has 0 link count allocated inode 131204 has 0 link count allocated inode 131205 has 0 link count allocated inode 131206 has 0 link count allocated inode 131207 has 0 link count :q! dxm@snort ~/isms/irix6.5m/eoe/cmd/xfs/stress> cat ~/after_026.full _check_fs: filesystem on /dev/hda6 is inconsistent *** xfs_check output *** agi unlinked bucket 3 is 131 in ag 0 agi unlinked bucket 4 is 132 in ag 0 agi unlinked bucket 5 is 133 in ag 0 agi unlinked bucket 0 is 128 in ag 1 agi unlinked bucket 1 is 129 in ag 1 agi unlinked bucket 2 is 130 in ag 1 agi unlinked bucket 3 is 131 in ag 1 agi unlinked bucket 4 is 132 in ag 1 agi unlinked bucket 5 is 133 in ag 1 agi unlinked bucket 6 is 134 in ag 1 agi unlinked bucket 7 is 135 in ag 1 agi unlinked bucket 8 is 136 in ag 1 agi unlinked bucket 9 is 137 in ag 1 agi unlinked bucket 10 is 138 in ag 1 agi unlinked bucket 11 is 139 in ag 1 agi unlinked bucket 12 is 140 in ag 1 agi unlinked bucket 13 is 141 in ag 1 agi unlinked bucket 14 is 142 in ag 1 agi unlinked bucket 15 is 143 in ag 1 agi unlinked bucket 16 is 144 in ag 1 agi unlinked bucket 17 is 145 in ag 1 agi unlinked bucket 18 is 146 in ag 1 agi unlinked bucket 19 is 147 in ag 1 agi unlinked bucket 20 is 148 in ag 1 agi unlinked bucket 21 is 149 in ag 1 agi unlinked bucket 22 is 150 in ag 1 agi unlinked bucket 23 is 151 in ag 1 agi unlinked bucket 24 is 152 in ag 1 agi unlinked bucket 25 is 153 in ag 1 agi unlinked bucket 26 is 154 in ag 1 agi unlinked bucket 27 is 155 in ag 1 agi unlinked bucket 28 is 156 in ag 1 agi unlinked bucket 29 is 157 in ag 1 agi unlinked bucket 30 is 158 in ag 1 agi unlinked bucket 31 is 159 in ag 1 agi unlinked bucket 32 is 160 in ag 1 agi unlinked bucket 33 is 161 in ag 1 agi unlinked bucket 34 is 162 in ag 1 link count mismatch for inode 128 (name ?), nlink 2, counted 3 link count mismatch for inode 131 (name ?), nlink 0, counted 2 allocated inode 132 has 0 link count allocated inode 133 has 0 link count link count mismatch for inode 131200 (name ?), nlink 0, counted 1 allocated inode 131201 has 0 link count allocated inode 131202 has 0 link count allocated inode 131203 has 0 link count allocated inode 131204 has 0 link count allocated inode 131205 has 0 link count allocated inode 131206 has 0 link count allocated inode 131207 has 0 link count allocated inode 131208 has 0 link count allocated inode 131209 has 0 link count allocated inode 131210 has 0 link count allocated inode 131211 has 0 link count allocated inode 131212 has 0 link count allocated inode 131213 has 0 link count allocated inode 131214 has 0 link count allocated inode 131215 has 0 link count allocated inode 131216 has 0 link count allocated inode 131217 has 0 link count allocated inode 131218 has 0 link count allocated inode 131219 has 0 link count allocated inode 131220 has 0 link count allocated inode 131221 has 0 link count allocated inode 131222 has 0 link count allocated inode 131223 has 0 link count allocated inode 131224 has 0 link count allocated inode 131225 has 0 link count allocated inode 131226 has 0 link count allocated inode 131227 has 0 link count allocated inode 131228 has 0 link count allocated inode 131229 has 0 link count allocated inode 131230 has 0 link count allocated inode 131231 has 0 link count allocated inode 131232 has 0 link count allocated inode 131233 has 0 link count allocated inode 131234 has 0 link count *** _check_fs: filesystem on /dev/hda6 is inconsistent *** xfs_repair -n output *** Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... error following ag 0 unlinked list error following ag 1 unlinked list - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 131, would move to lost+found disconnected inode 132, would move to lost+found disconnected inode 133, would move to lost+found disconnected dir inode 131200, would move to lost+found disconnected inode 131201, would move to lost+found disconnected inode 131202, would move to lost+found disconnected inode 131203, would move to lost+found disconnected inode 131204, would move to lost+found disconnected inode 131205, would move to lost+found disconnected inode 131206, would move to lost+found disconnected inode 131207, would move to lost+found disconnected inode 131208, would move to lost+found disconnected inode 131209, would move to lost+found disconnected inode 131210, would move to lost+found disconnected inode 131211, would move to lost+found disconnected inode 131212, would move to lost+found disconnected inode 131213, would move to lost+found disconnected inode 131214, would move to lost+found disconnected inode 131215, would move to lost+found disconnected inode 131216, would move to lost+found disconnected inode 131217, would move to lost+found disconnected inode 131218, would move to lost+found disconnected inode 131219, would move to lost+found disconnected inode 131220, would move to lost+found disconnected inode 131221, would move to lost+found disconnected inode 131222, would move to lost+found disconnected inode 131223, would move to lost+found disconnected inode 131224, would move to lost+found disconnected inode 131225, would move to lost+found disconnected inode 131226, would move to lost+found disconnected inode 131227, would move to lost+found disconnected inode 131228, would move to lost+found disconnected inode 131229, would move to lost+found disconnected inode 131230, would move to lost+found disconnected inode 131231, would move to lost+found disconnected inode 131232, would move to lost+found disconnected inode 131233, would move to lost+found disconnected inode 131234, would move to lost+found Phase 7 - verify link counts... would have reset inode 131 nlinks from 0 to 2 would have reset inode 132 nlinks from 0 to 1 would have reset inode 133 nlinks from 0 to 1 would have reset inode 131200 nlinks from 0 to 2 would have reset inode 131201 nlinks from 0 to 1 would have reset inode 131202 nlinks from 0 to 1 would have reset inode 131203 nlinks from 0 to 1 would have reset inode 131204 nlinks from 0 to 1 would have reset inode 131205 nlinks from 0 to 1 would have reset inode 131206 nlinks from 0 to 1 would have reset inode 131207 nlinks from 0 to 1 would have reset inode 131208 nlinks from 0 to 1 would have reset inode 131209 nlinks from 0 to 1 would have reset inode 131210 nlinks from 0 to 1 would have reset inode 131211 nlinks from 0 to 1 would have reset inode 131212 nlinks from 0 to 1 would have reset inode 131213 nlinks from 0 to 1 would have reset inode 131214 nlinks from 0 to 1 would have reset inode 131215 nlinks from 0 to 1 would have reset inode 131216 nlinks from 0 to 1 would have reset inode 131217 nlinks from 0 to 1 would have reset inode 131218 nlinks from 0 to 1 would have reset inode 131219 nlinks from 0 to 1 would have reset inode 131220 nlinks from 0 to 1 would have reset inode 131221 nlinks from 0 to 1 would have reset inode 131222 nlinks from 0 to 1 would have reset inode 131223 nlinks from 0 to 1 would have reset inode 131224 nlinks from 0 to 1 would have reset inode 131225 nlinks from 0 to 1 would have reset inode 131226 nlinks from 0 to 1 would have reset inode 131227 nlinks from 0 to 1 would have reset inode 131228 nlinks from 0 to 1 would have reset inode 131229 nlinks from 0 to 1 would have reset inode 131230 nlinks from 0 to 1 would have reset inode 131231 nlinks from 0 to 1 would have reset inode 131232 nlinks from 0 to 1 would have reset inode 131233 nlinks from 0 to 1 would have reset inode 131234 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. *** *** mount output *** /initrd/dev/hda1 on / type ext2 (ro) /initrd/dev/ram0 on /initrd type unknown (rw) none on /initrd/dev/pts type devpts (rw,gid=5,mode=620) none on /initrd/var/shm type shm (rw) snort:/build1 on /mnt/snort/build1 type nfs (rw,addr=134.14.55.149,addr=134.14.55.149) none on /proc type proc (rw) /initrd/dev/hda6 on /mnt/arch0 type xfs (rw) From owner-linux-xfs@oss.sgi.com Sun Sep 10 19:19:02 2000 Received: by oss.sgi.com id ; Sun, 10 Sep 2000 19:18:53 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:55132 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 10 Sep 2000 19:18:41 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA05441 for ; Sun, 10 Sep 2000 19:25:17 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA65658 for linux-xfs@oss.sgi.com; Mon, 11 Sep 2000 13:16:07 +1100 (EST) Date: Mon, 11 Sep 2000 13:16:07 +1100 (EST) From: Daniel Moore Message-Id: <200009110216.NAA65658@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_check Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing print inode number for unlinked bucket warning Modid: 2.4.0-test1-xfs:slinx:74114a Date: Sun Sep 10 19:15:51 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/check.c - 1.58 - print inode number for unlinked bucket warning From owner-linux-xfs@oss.sgi.com Sun Sep 10 19:23:23 2000 Received: by oss.sgi.com id ; Sun, 10 Sep 2000 19:23:13 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:12822 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 10 Sep 2000 19:23:00 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA12380; Sun, 10 Sep 2000 19:15:20 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA08854; Sun, 10 Sep 2000 19:22:57 -0700 (PDT) Date: Sun, 10 Sep 2000 19:22:57 -0700 (PDT) Message-Id: <200009110222.TAA08854@info.engr.sgi.com> X-Pv-Incident: 801241 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: REASSIGN 801241 - xfsdump can cause filesystem corruption To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801241 Status : open Priority : 1 *Assigned Engineer : dxm *Assigned Domain : engr Submitter : ivanr Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/07/00 *Modified User : dxm *Modified User Domain : engr *Description : QA for xfsdump/xfsrestore revealed that it is possible for xfsdump to cause filesystem corruption. The test involves creating a filesystem, creating a whole buncha files, xfsdumping them to a file somewhere, then removing all the files. xfs_check reports lots of inodes with zero link counts, etc. It's probably due to xfsdump using bulkstat on the entire fs. The following is a script which will reliably (at least on bruce.melbourne) produce the error. Run it in cmd/xfs/stress - it needs the src/fill program, and make sure you fix the ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: dxm@engr (BugWorks) Date: Sep 10 2000 07:22:56PM ========================== From owner-linux-xfs@oss.sgi.com Sun Sep 10 22:17:54 2000 Received: by oss.sgi.com id ; Sun, 10 Sep 2000 22:17:44 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:24196 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sun, 10 Sep 2000 22:17:25 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id AAA29435; Mon, 11 Sep 2000 00:10:43 -0500 (CDT) Date: Mon, 11 Sep 2000 00:10:43 -0500 (CDT) Message-Id: <200009110510.AAA29435@spica.cc.utexas.edu> From: William L Jones To: pv@relay.sgi.com (dxm@engr.sgi.com) cc: dxm@engr.sgi.com, linux-xfs@oss.sgi.com Subject: Re: REASSIGN 801241 - xfsdump can cause filesystem corruption Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing One small observation. If I create a xfs file system and then untar a set of files to it and then run xfs_check I get errors. They look like the same error that I get if run xfsdump and then remove the files before running xfs_check. If I umount the file system and run xfs_repair I don't find any errors. Bill Jones From owner-linux-xfs@oss.sgi.com Sun Sep 10 22:39:44 2000 Received: by oss.sgi.com id ; Sun, 10 Sep 2000 22:39:34 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:51043 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 10 Sep 2000 22:39:17 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA04366; Sun, 10 Sep 2000 22:45:55 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA87342; Sun, 10 Sep 2000 22:39:16 -0700 (PDT) Date: Sun, 10 Sep 2000 22:39:16 -0700 (PDT) Message-Id: <200009110539.WAA87342@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Status : open Priority : 3 Assigned Engineer : nathans Submitter : lord *Modified User : nathans *Modified User Domain : engr *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Sep 10 2000 10:39:15PM ========================== > of the filesystem blocksize. When ext2 is mounted on a device > it changes the block size to be whatever its mkfs block size > was. 4K in my case. Ah - this is why I couldn't reproduce it before - I was using the default ext2 block size of 1K. I can now also reproduce it every time too using 4K - this is how to do it: mkfs.ext2 -b 4096 /dev/hda10 mount /dev/hda10 /mnt/tmp umount /mnt/tmp mkfs.xfs /dev/hda10 With the old mkfs.xfs, ie. with the EFS SB write, this always fails. And if I remove the "-b 4096" from the ext2 mkfs line, it always passes. It seems to be that the ext2 mount calls set_blocksize(), and its never reset (even on umount). So when we come along and do a 512 byte write, 1K back from the end of the device (where the end of the device is the value we get back from BLKGETSIZE, minus one, we end up issuing a 4K IO to the device driver which goes beyond the end of the device. Is that how you understand things, Steve? Going back and redoing the calculations for your sda4, Steve, and my hda10, neither of these devices have sizes which are 4K aligned, which is consistent with this theory. Unfortunately, as you say in your solution #1, there seems to be no way to get the current blocksize for a block device, and if thats true, then its difficult to guard against this in mkfs.xfs (could be bigger than 4K too, right?). And we ideally want to use as much of the device as possible - the amount of the device mkfs can access shouldn't depend on the state that a previous occupant has left the device in. I think what we're really after is a way to call set_blocksize from userspace, so that we can call that before any mkfs writes and know where we stand for an arbitrary device (from a look through the kernel most filesystems don't reset the device blocksize on unmount). Is this possible? dunno - I can't see any ioctl doing this. > > 1. repeat the same calculation in libxfs to reduce the size of > the partition we tell mkfs about - problem is there is no call > to get this block size value out of the kernel. > > 2. reset the block size to the hardware sector size - the only way > I can see to do this is to use the raw device interface. > ... > 2 would be best if we could figure out how to do it. Yup, I agree. I noticed xfs seems to set the device blocksize to 512 explicitly (in linvfs_readsuper) ... that seems odd to me - why aren't we driving this either from the superblock blocksize value or to the value from get_hardblocksize()? - does that code look right to you? The xfs put_super code also looks like it should be calling get_hardblocksize() rather than accessing hardsect_size[] directly, perhaps? Having spent all of 10 minutes looking at this code, I could well be way off on these above two statements though ;-) OK, so given we have removed the last-potential-efs-sb overwrite in mkfs.xfs, the remaining question is whether writing the external log device (i.e. zeroing & footering it) is affected as well. This experiment seems to suggest that we are not affected here either... (hda10 and hda11 both have sizes which are _not_ multiples of 4K): [nathans@troppo mkfs]# mkfs -t ext2 -b 4096 -q /dev/hda11 mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [nathans@troppo mkfs]# mkfs -t ext2 -b 4096 -q /dev/hda10 mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [nathans@troppo mkfs]# mount /dev/hda11 /mnt/tmp [nathans@troppo mkfs]# umount /mnt/tmp [nathans@troppo mkfs]# mount /dev/hda10 /mnt/tmp [nathans@troppo mkfs]# umount /mnt/tmp ...ext2 has now called set_blocksize(4096) on both devices. [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda10 mkfs.xfs: write failed: No space left on device [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda11 mkfs.xfs: write failed: No space left on device ...as expected, these both fail with the old mkfs binary. [nathans@troppo mkfs]# mkfs -t ext2 -b 1024 -q /dev/hda10 mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [nathans@troppo mkfs]# mkfs -t ext2 -b 4096 -q /dev/hda11 mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [nathans@troppo mkfs]# mount /dev/hda11 /mnt/tmp [nathans@troppo mkfs]# umount /mnt/tmp [nathans@troppo mkfs]# mount /dev/hda10 /mnt/tmp [nathans@troppo mkfs]# umount /mnt/tmp we can now expect to succeed on hda10, but not hda11... [nathans@troppo mkfs]# ./mkfs.xfs -f -q -l logdev=/dev/hda11 /dev/hda10 [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda11 mkfs.xfs: write failed: No space left on device [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda10 [nathans@troppo mkfs]# ... eureka - no error for the external log case! For bonus points, someone gets to explain why this is... cos I thought it would fail. Anyway, my head hurts ;) - I'll have to figure this one out tomorrow. Maximum blocksize which can be set in the kernel is PAGE_SIZE, so there may be issues at 8192 too, for some architectures ... mkfs.ext2 wont take us there though (disallows 8192 as a block size). cheers. From owner-linux-xfs@oss.sgi.com Sun Sep 10 23:16:14 2000 Received: by oss.sgi.com id ; Sun, 10 Sep 2000 23:16:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:54319 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 10 Sep 2000 23:15:47 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA26641; Sun, 10 Sep 2000 23:08:06 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA03915; Sun, 10 Sep 2000 23:15:43 -0700 (PDT) Date: Sun, 10 Sep 2000 23:15:43 -0700 (PDT) Message-Id: <200009110615.XAA03915@info.engr.sgi.com> X-Pv-Incident: 801241 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 801241 - xfsdump can cause filesystem corruption To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801241 Status : open Priority : 1 Assigned Engineer : dxm Submitter : ivanr *Modified User : dxm *Modified User Domain : engr *Description : QA for xfsdump/xfsrestore revealed that it is possible for xfsdump to cause filesystem corruption. The test involves creating a filesystem, creating a whole buncha files, xfsdumping them to a file somewhere, then removing all the files. xfs_check reports lots of inodes with zero link counts, etc. It's probably due to xfsdump using bulkstat on the entire fs. The following is a script which will reliably (at least on bruce.melbourne) produce the error. Run it in cmd/xfs/stress - it needs the src/fill program, and make sure you fix the ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 10 2000 11:15:42PM ========================== xfs_open_by_handle is causing some kind of reference leak which means deleted files stay in the agi_unlinked list when the FS is unmounted instead of being passed to xfs_iunlink_remove when their count hits zero (ie before unmount). I've added qa 034 which isolates this bug... From owner-linux-xfs@oss.sgi.com Sun Sep 10 23:18:34 2000 Received: by oss.sgi.com id ; Sun, 10 Sep 2000 23:18:24 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14693 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 10 Sep 2000 23:18:11 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA02189 for ; Sun, 10 Sep 2000 23:24:47 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA64377 for linux-xfs@oss.sgi.com; Mon, 11 Sep 2000 17:15:36 +1100 (EST) Date: Mon, 11 Sep 2000 17:15:36 +1100 (EST) From: Daniel Moore Message-Id: <200009110615.RAA64377@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs qa 034 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:74117a Date: Sun Sep 10 23:15:23 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/017 - 1.6 cmd/xfs/stress/group - 1.35 - add 034 cmd/xfs/stress/src/ioctl.c - 1.3 - tidy cmd/xfs/stress/034 - 1.1 - isolate pv 801241 cmd/xfs/stress/034.out - 1.1 - output for 034 From owner-linux-xfs@oss.sgi.com Mon Sep 11 00:13:04 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 00:12:44 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:42037 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 00:12:15 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA29777 for ; Mon, 11 Sep 2000 00:04:33 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA96647 for linux-xfs@oss.sgi.com; Mon, 11 Sep 2000 18:10:55 +1100 (EST) Date: Mon, 11 Sep 2000 18:10:55 +1100 (EST) From: Nathan Scott Message-Id: <200009110710.SAA96647@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This should help with random core dumps for no reason. I also find "make depend" useful (might look at running it by default one day) for the commands. cheers. Modid: 2.4.0-test1-xfs:slinx:74119a Date: Mon Sep 11 00:06:31 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/Makefile - 1.52 cmd/xfs/dump/dump/Makefile - 1.16 cmd/xfs/dump/restore/Makefile - 1.7 cmd/xfs/fsr/Makefile - 1.6 cmd/xfs/growfs/Makefile - 1.4 - add missing dependencies. cmd/xfs/include/builddefs.in - 1.12 - tidy up. cmd/xfs/include/buildrules - 1.2 cmd/xfs/logprint/Makefile - 1.39 cmd/xfs/mkfs/Makefile - 1.48 cmd/xfs/repair/Makefile - 1.44 - add missing dependencies. From owner-linux-xfs@oss.sgi.com Mon Sep 11 01:03:34 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 01:03:24 -0700 Received: from hermes.mixx.net ([212.84.196.2]:22797 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 11 Sep 2000 01:03:13 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 3930FF831 for ; Mon, 11 Sep 2000 10:03:11 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id B902C2CA6D; Mon, 11 Sep 2000 10:03:10 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs as root fs Date: 11 Sep 2000 08:03:10 GMT Organization: innominate AG, Berlin, Germany Lines: 74 Distribution: local Message-ID: References: <200009081540.KAA18672@jen.americas.sgi.com> <39B92B33.7ACC80D2@thebarn.com> <39B92F8D.1E732EAE@thebarn.com> <39B94DD8.4D248B2B@thebarn.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968659390 25566 10.0.0.69 (11 Sep 2000 08:03:10 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > Thomas Graichen wrote: >> Russell Cattelan wrote: >> >> due to my experience i had it nearly everytime when i checked ... >> >> i may reboot and check this machine in a few minutes and see and >> >> maybe send you the xfs_repair output ... so a few minutes from >> >> now ... >> >> > I'll restart my xfs root fs machine with the latest build... see what happens. >> > Maybe it's a recent change. >> >> hmmm - schroedingers cat - i just tried to reproduce it and now it >> works all time ... so if you have other things to work on just >> ignore this one until i have reproduced it better and can >> give you some more details about it > Try this patch... it may help. > This will issue another round of trying to sync the fs to a clean state. > In talking with Steve about this, it may be possible for xfs inodes to not > completely > be flushed out after the first sync, hopefully the second one will catch the rest > of > the clean up necessary. > *** /usr/tmp/TmpDir.15204-0/linux/fs/xfs/linux/xfs_super.c_1.86 Fri Sep 8 15:31:09 > 2000 > --- linux/fs/xfs/linux/xfs_super.c Fri Sep 8 14:44:54 2000 > *************** > *** 565,570 **** > --- 565,573 ---- > PVFS_SYNC(vfsp->vfs_fbhv, > SYNC_ATTR|SYNC_WAIT|SYNC_CLOSE, > sys_cred, error); > + PVFS_SYNC(vfsp->vfs_fbhv, > + SYNC_ATTR|SYNC_WAIT|SYNC_CLOSE, > + sys_cred, error); > if (error) { > sb->s_flags=save; > printk("XFS: Failed to sync for read-only remount\n"); but why this should help - i never got the "XFS: Failed to sync .." line ... ok but maybe PVFS_SYNC does not do it's job completely all the time - is that the idea? btw. i redid all on my machine at home: rebuild the tools after a make realclean, built a fresh kernel (sources from friday 8.9.) and re-mkfs.xfs'ed the filesystems - so far i was not able to reproduce the problem again - but i will keep an eye on it and try this patch then ... will do the same procedure as above now for the two testmachines here at work too but what i discovered was something i remembered having read about being fixed a few days ago (but could not find it in the mails): after running xfs_repair on an (unmounted) xfs fs - mounting it directly after that - unmounting it again ... now a new mount try fails with log problems - running xfs_repair (which does not find any errors) fixes the problem so the fs is mountable after that ... it also works in normal use (without the mount short after the xfs_repair) ... but i'll look at it closer and give more details (btw. all the stuff was from fri 8.9. so _after_ i read about the fix) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Mon Sep 11 07:40:09 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 07:40:00 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23044 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 07:39:35 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA00308 for ; Mon, 11 Sep 2000 07:46:12 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA45501; Mon, 11 Sep 2000 09:38:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA24253; Mon, 11 Sep 2000 09:38:17 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA13527; Mon, 11 Sep 2000 09:36:29 -0500 Message-Id: <200009111436.JAA13527@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: nathans@engr.sgi.com, linux-xfs@oss.sgi.com Subject: Re: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail In-Reply-To: Message from pv@odin.corp.sgi.com (nathans@engr.sgi.com) of "Sun, 10 Sep 2000 22:39:16 PDT." <200009110539.WAA87342@info.engr.sgi.com> Date: Mon, 11 Sep 2000 09:36:29 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Not sending this to the bug system..... > > > I noticed xfs seems to set the device blocksize to 512 explicitly > (in linvfs_readsuper) ... that seems odd to me - why aren't we > driving this either from the superblock blocksize value or to > the value from get_hardblocksize()? - does that code look right > to you? XFS needs 512 byte access for things like the super block, agi/agf header structures. We are forced into using the lowest common denominator block size because of this - the fact that the log may require us to pin one in memory whilst forcing the other out means we cannot just do a larger I/O. > > The xfs put_super code also looks like it should be calling > get_hardblocksize() rather than accessing hardsect_size[] directly, > perhaps? This is probably true, get_hardblocksize probably showed up after the initial code was written, or I just didn't notice it being there. > > Having spent all of 10 minutes looking at this code, I could well > be way off on these above two statements though ;-) > > > > OK, so given we have removed the last-potential-efs-sb overwrite in > mkfs.xfs, the remaining question is whether writing the external log > device (i.e. zeroing & footering it) is affected as well. > > This experiment seems to suggest that we are not affected here > either... (hda10 and hda11 both have sizes which are _not_ multiples > of 4K): > > [nathans@troppo mkfs]# mkfs -t ext2 -b 4096 -q /dev/hda11 > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 > [nathans@troppo mkfs]# mkfs -t ext2 -b 4096 -q /dev/hda10 > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 > [nathans@troppo mkfs]# mount /dev/hda11 /mnt/tmp > [nathans@troppo mkfs]# umount /mnt/tmp > [nathans@troppo mkfs]# mount /dev/hda10 /mnt/tmp > [nathans@troppo mkfs]# umount /mnt/tmp > > ...ext2 has now called set_blocksize(4096) on both devices. > > [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda10 > mkfs.xfs: write failed: No space left on device > [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda11 > mkfs.xfs: write failed: No space left on device > > ...as expected, these both fail with the old mkfs binary. > > [nathans@troppo mkfs]# mkfs -t ext2 -b 1024 -q /dev/hda10 > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 > [nathans@troppo mkfs]# mkfs -t ext2 -b 4096 -q /dev/hda11 > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 > [nathans@troppo mkfs]# mount /dev/hda11 /mnt/tmp > [nathans@troppo mkfs]# umount /mnt/tmp > [nathans@troppo mkfs]# mount /dev/hda10 /mnt/tmp > [nathans@troppo mkfs]# umount /mnt/tmp > > we can now expect to succeed on hda10, but not hda11... > > [nathans@troppo mkfs]# ./mkfs.xfs -f -q -l logdev=/dev/hda11 /dev/hda10 > [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda11 > mkfs.xfs: write failed: No space left on device > [nathans@troppo mkfs]# ./mkfs.xfs -f -q /dev/hda10 > [nathans@troppo mkfs]# > > ... eureka - no error for the external log case! > > For bonus points, someone gets to explain why this is... cos I > thought it would fail. Anyway, my head hurts ;) - I'll have to > figure this one out tomorrow. > > Maximum blocksize which can be set in the kernel is PAGE_SIZE, > so there may be issues at 8192 too, for some architectures ... > mkfs.ext2 wont take us there though (disallows 8192 as a block > size). > > cheers. This one is wierd, I would expect the same error. I think this is a problem we need to fix in some other way eventually. The /dev/raw suggestion is a good one, probably not something we want to release without some testing though. I presume this would be something we could encapsulate in the libxfs device open and close code - we create a /dev/raw device for the partition and use that descriptor rather than opening the device directly. Steve From owner-linux-xfs@oss.sgi.com Mon Sep 11 07:41:09 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 07:40:49 -0700 Received: from [195.89.149.246] ([195.89.149.246]:55312 "EHLO dukat.scot.redhat.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 07:40:34 -0700 Received: (from sct@localhost) by dukat.scot.redhat.com (8.9.3/8.9.3) id PAA27904; Mon, 11 Sep 2000 15:39:34 +0100 Date: Mon, 11 Sep 2000 15:39:34 +0100 From: "Stephen C. Tweedie" To: sgi.bugs.xfs@fido.engr.sgi.com Cc: nathans@engr.sgi.com, linux-xfs@oss.sgi.com, Stephen Tweedie Subject: Re: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail Message-ID: <20000911153934.E18863@redhat.com> References: <200009110539.WAA87342@info.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200009110539.WAA87342@info.engr.sgi.com>; from pv@relay.sgi.com on Sun, Sep 10, 2000 at 10:39:16PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, On Sun, Sep 10, 2000 at 10:39:16PM -0700, nathans@engr.sgi.com wrote: > I think what we're really after is a way to call set_blocksize from > userspace Agreed. The filesystems themselves can call it, so it makes complete sense for fsck and mfks type binaries to be able to do the same. Cheers, Stephen From owner-linux-xfs@oss.sgi.com Mon Sep 11 07:48:39 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 07:48:20 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1541 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 07:48:12 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02208; Mon, 11 Sep 2000 07:54:49 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA58917; Mon, 11 Sep 2000 07:47:41 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA06352; Mon, 11 Sep 2000 07:45:05 -0700 (PDT) Date: Mon, 11 Sep 2000 07:45:05 -0700 (PDT) Message-Id: <200009111445.HAA06352@feature.engr.sgi.com> X-Pv-Incident: 801063 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (sct@redhat.com) Subject: ADD 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord Status : open Assigned Engineer : nathans Priority : 3 *Modified Date : 09/11/00 *Modified User : sct *Modified User Domain : redhat.com *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: "stephen c. tweedie" Date: Sep 11 2000 07:45:04AM [pvnews version: 1.71] ========================== Hi, On Sun, Sep 10, 2000 at 10:39:16PM -0700, nathans@engr.sgi.com wrote: > I think what we're really after is a way to call set_blocksize from > userspace Agreed. The filesystems themselves can call it, so it makes complete sense for fsck and mfks type binaries to be able to do the same. Cheers, Stephen From owner-linux-xfs@oss.sgi.com Mon Sep 11 08:07:10 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 08:06:50 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:25471 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 08:06:28 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA07651; Mon, 11 Sep 2000 07:58:47 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA06738; Mon, 11 Sep 2000 08:05:05 -0700 (PDT) Date: Mon, 11 Sep 2000 08:05:05 -0700 (PDT) Message-Id: <200009111505.IAA06738@feature.engr.sgi.com> X-Pv-Incident: 801241 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (jones@tacc.cc.utexas.edu.sgi.com) Subject: ADD 801241 - xfsdump can cause filesystem corruption To: dxm@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : ivanr Status : open Assigned Engineer : dxm Priority : 1 *Modified Date : 09/11/00 *Modified User : jones *Modified User Domain : tacc.cc.utexas.edu *Description : QA for xfsdump/xfsrestore revealed that it is possible for xfsdump to cause filesystem corruption. The test involves creating a filesystem, creating a whole buncha files, xfsdumping them to a file somewhere, then removing all the files. xfs_check reports lots of inodes with zero link counts, etc. It's probably due to xfsdump using bulkstat on the entire fs. The following is a script which will reliably (at least on bruce.melbourne) produce the error. Run it in cmd/xfs/stress - it needs the src/fill program, and make sure you fix the ..... ========================== ADDITIONAL INFORMATION (ADD) From: "william l. jones" Date: Sep 11 2000 08:05:04AM [pvnews version: 1.71] ========================== At 11:15 PM 9/10/00 -0700, you wrote: >View Incident: >http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1& >view_type=Bug&wi=801241 > > Status : open Priority : 1 > Assigned Engineer : dxm Submitter : ivanr >*Modified User : dxm *Modified User Domain : engr >*Description : >QA for xfsdump/xfsrestore revealed that it is possible for >xfsdump to cause filesystem corruption. The test involves >creating a filesystem, creating a whole buncha files, xfsdumping >them to a file somewhere, then removing all the files. xfs_check >reports lots of inodes with zero link counts, etc. It's probably >due to xfsdump using bulkstat on the entire fs. > >The following is a script which will reliably (at least on >bruce.melbourne) produce the error. Run it in cmd/xfs/stress - >it needs the src/fill program, and make sure you fix the > >..... > > >========================== >ADDITIONAL INFORMATION (ADD) >From: dxm@engr (BugWorks) >Date: Sep 10 2000 11:15:42PM >========================== > >xfs_open_by_handle is causing some kind of reference leak >which means deleted files stay in the agi_unlinked list >when the FS is unmounted instead of being passed to >xfs_iunlink_remove when their count hits zero >(ie before unmount). > >I've added qa 034 which isolates this bug... You should also add bulk_stat_single to the list of suspects. Bill Jones From owner-linux-xfs@oss.sgi.com Mon Sep 11 08:07:20 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 08:07:10 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1288 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 08:06:52 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA04760 for ; Mon, 11 Sep 2000 08:13:29 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA29853; Mon, 11 Sep 2000 10:05:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA90943; Mon, 11 Sep 2000 10:05:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id KAA13587; Mon, 11 Sep 2000 10:03:45 -0500 Message-Id: <200009111503.KAA13587@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs as root fs In-Reply-To: Message from Thomas Graichen of "11 Sep 2000 08:03:10 GMT." Date: Mon, 11 Sep 2000 10:03:45 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > *** /usr/tmp/TmpDir.15204-0/linux/fs/xfs/linux/xfs_super.c_1.86 Fri Sep 8 15:31:09 > > 2000 > > --- linux/fs/xfs/linux/xfs_super.c Fri Sep 8 14:44:54 2000 > > *************** > > *** 565,570 **** > > --- 565,573 ---- > > PVFS_SYNC(vfsp->vfs_fbhv, > > SYNC_ATTR|SYNC_WAIT|SYNC_CLOSE, > > sys_cred, error); > > + PVFS_SYNC(vfsp->vfs_fbhv, > > + SYNC_ATTR|SYNC_WAIT|SYNC_CLOSE, > > + sys_cred, error); > > if (error) { > > sb->s_flags=save; > > printk("XFS: Failed to sync for read-only remount\n"); > > but why this should help - i never got the "XFS: Failed to sync .." > line ... ok but maybe PVFS_SYNC does not do it's job completely > all the time - is that the idea? The issue here is not a failure, but the fact that there is some code in XFS at the moment which effectively makes a complete sync out of the filesystem take two sync calls, so currently the Unix myth about typing sync twice is actually true for XFS! This is not a problem doing a regular unmount, it only relates to the hoops we are making XFS jump through to make it remount read-only, not something it ever does on Irix. This relates to how we get unlinked files out of the system. We need to flush the inode to disk in a 'free' state, and we need to remove the inode from an on disk list of unlinked inodes. The second cannot happen before the first has completed. In order to keep sync processing time down to a minimum in normal operation these are handled in two passes. > > btw. i redid all on my machine at home: rebuild the tools after a > make realclean, built a fresh kernel (sources from friday 8.9.) > and re-mkfs.xfs'ed the filesystems - so far i was not able to > reproduce the problem again - but i will keep an eye on it > and try this patch then ... will do the same procedure as > above now for the two testmachines here at work too > > but what i discovered was something i remembered having read about > being fixed a few days ago (but could not find it in the mails): > after running xfs_repair on an (unmounted) xfs fs - mounting > it directly after that - unmounting it again ... now a new > mount try fails with log problems - running xfs_repair > (which does not find any errors) fixes the problem > so the fs is mountable after that ... it also > works in normal use (without the mount short > after the xfs_repair) ... but i'll look at > it closer and give more details (btw. all > the stuff was from fri 8.9. so _after_ i > read about the fix) Ugh!, I will give this a try. Steve > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Mon Sep 11 08:30:49 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 08:30:40 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:55565 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 08:30:33 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA08490 for ; Mon, 11 Sep 2000 08:37:10 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA52251; Mon, 11 Sep 2000 10:29:15 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id KAA00484; Mon, 11 Sep 2000 10:29:14 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e8BFTDe28217; Mon, 11 Sep 2000 10:29:13 -0500 Message-ID: <39BCFA48.44E40FB0@thebarn.com> Date: Mon, 11 Sep 2000 10:29:12 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: William L Jones CC: linux-xfs@oss.sgi.com Subject: Re: REASSIGN 801241 - xfsdump can cause filesystem corruption References: <200009110510.AAA29435@spica.cc.utexas.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing William L Jones wrote: > One small observation. If I create a xfs file system and then untar a set > of files to it and then run xfs_check I get errors. They look like the same > error that I get if run xfsdump and then remove the files before running > xfs_check. xfs_check will report errors if run on a mounted file system. xfs_repair shouldn't be run on a mounted file system, it will most likely cause fs corruption and or cause the system to crash when it finds an inconsistency. > > > If I umount the file system and run xfs_repair I don't find any errors. > > Bill Jones From owner-linux-xfs@oss.sgi.com Mon Sep 11 11:10:20 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 11:10:01 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32036 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 11:09:30 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA08036; Mon, 11 Sep 2000 11:16:08 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA11419; Mon, 11 Sep 2000 11:08:09 -0700 (PDT) Date: Mon, 11 Sep 2000 11:08:09 -0700 (PDT) Message-Id: <200009111808.LAA11419@feature.engr.sgi.com> X-Pv-Incident: 801241 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (jones@tacc.cc.utexas.edu.sgi.com) Subject: ADD 801241 - xfsdump can cause filesystem corruption To: dxm@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : ivanr Status : open Assigned Engineer : dxm Priority : 1 *Modified Date : 09/11/00 *Modified User : jones *Modified User Domain : tacc.cc.utexas.edu *Description : QA for xfsdump/xfsrestore revealed that it is possible for xfsdump to cause filesystem corruption. The test involves creating a filesystem, creating a whole buncha files, xfsdumping them to a file somewhere, then removing all the files. xfs_check reports lots of inodes with zero link counts, etc. It's probably due to xfsdump using bulkstat on the entire fs. The following is a script which will reliably (at least on bruce.melbourne) produce the error. Run it in cmd/xfs/stress - it needs the src/fill program, and make sure you fix the ..... ========================== ADDITIONAL INFORMATION (ADD) From: william l jones Date: Sep 11 2000 11:08:09AM [pvnews version: 1.71] ========================== One small observation. If I create a xfs file system and then untar a set of files to it and then run xfs_check I get errors. They look like the same error that I get if run xfsdump and then remove the files before running xfs_check. If I umount the file system and run xfs_repair I don't find any errors. Bill Jones From owner-linux-xfs@oss.sgi.com Mon Sep 11 13:03:11 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 13:02:51 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:32607 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 13:02:27 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA22596; Mon, 11 Sep 2000 12:54:41 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA73456; Mon, 11 Sep 2000 13:02:20 -0700 (PDT) Date: Mon, 11 Sep 2000 13:02:20 -0700 (PDT) Message-Id: <200009112002.NAA73456@info.engr.sgi.com> X-Pv-Incident: 797419 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: CLOSE 797419 - xfs_iget goes recursive and dies a horrible death To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797419 *Status : closed Priority : 1 Assigned Engineer : lord Submitter : lord Opened Date : 07/27/00 *Closed Date : 09/11/00 *Fixed By : lord *Fixed By Domain : sgi.com *Modified Date : 09/11/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: lord@sgi.com (BugWorks) Date: Sep 11 2000 01:02:19PM ========================== Messed up the send line in the take message. Checked in fix 2.4.0-test1-xfs:slinx:74156a Basic change is to introduce ihold which is iget without the create a new inode part. Apart from that some cleanup of the xfs iget and vnode code. This should close the race condition and has stood up to heavier dbench load than anything previous, along with NFS server activity. mod 2.4.0-test1-xfs:slinx:74156a header ======================================== - SM_Location: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs - Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 - 2.4.0-test1-xfs:slinx:74156a 09/11/00 - Files affected: linux/kernel/ksyms.c 1.57, linux/include/linux/fs.h 1.57, linux/fs/inode.c 1.28, linux/fs/xfs/xfs_iget.c 1.126, linux/fs/xfs/pseudo-inc/sys/vnode.h 1.29, linux/fs/xfs/linux/xfs_vnode.c 1.40, linux/fs/xfs/linux/xfs_iops.c 1.66 - Author: lord - linux/kernel/ksyms.c: export ihold4 to modules. - linux/include/linux/fs.h: prototype for ihold4 and definition of ihold - linux/fs/inode.c: Added ihold4 - this is iget4 without creating a new inode if there isn't one. - linux/fs/xfs/xfs_iget.c: get rid of confusing sim path, do not pass a dev_t to vn_alloc, replave vn_put with vn_rele - linux/fs/xfs/pseudo-inc/sys/vnode.h: remove dev_t from vn_alloc prototype, remove vn_put, in vnode tracing case call vn_rele, not vn_put. - linux/fs/xfs/linux/xfs_vnode.c: merge vn_put into vn_rele, remove dev_t from intitialization calls, it was not being used anymore. - linux/fs/xfs/linux/xfs_iops.c: vn_rele and vn_put have been folded into one - vn_rele From owner-linux-xfs@oss.sgi.com Mon Sep 11 15:59:01 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 15:58:51 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:62486 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 15:58:29 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA17813 for ; Mon, 11 Sep 2000 15:50:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id RAA00544 for ; Mon, 11 Sep 2000 17:55:56 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id RAA98934 for ; Mon, 11 Sep 2000 17:55:55 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id RAA31955; Mon, 11 Sep 2000 17:54:04 -0500 Message-Id: <200009112254.RAA31955@jen.americas.sgi.com> Date: Mon, 11 Sep 2000 17:54:04 -0500 Subject: TAKE - a couple of potential highmen fixes To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Sep 11 15:55:22 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74186a linux/fs/xfs/xfs_buf.h - 1.61 - Add PBF_MAPPABLE to metadata readahead calls. linux/fs/pagebuf/page_buf.c - 1.31 - Change GFP_USER to GFP_KERNEL for pagebufs required to be accessible from kernel space. From owner-linux-xfs@oss.sgi.com Mon Sep 11 18:59:14 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 18:59:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:51770 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 18:58:38 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA06012; Mon, 11 Sep 2000 18:50:56 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA72993; Mon, 11 Sep 2000 18:58:35 -0700 (PDT) Date: Mon, 11 Sep 2000 18:58:35 -0700 (PDT) Message-Id: <200009120158.SAA72993@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: crash.engr.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (tduffy@engr.sgi.com) Subject: UPDATE 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: tduffy@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 *CC List : tduffy Status : open Priority : 2 Assigned Engineer : lord Submitter : ananth Opened Date : 08/29/00 *Modified User : tduffy *Modified User Domain : engr *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (UPDATE) From: tduffy@engr (BugWorks) Date: Sep 11 2000 06:58:35PM ========================== so, I have managed to get waco back into a locked state again. The machine is alive but a few processes are wedged, including a vi and a split-include. lord, if you want, please grab the console and drop into the debugger. you will see the backtrace of split-include process 29241 is the standard stopped in xlog_grant_log_space: [1]kdb> btp 29241 EBP EIP Function(args) 0xe7cafd00 0xc0119bdd schedule+0x415 (0xf77f0d98) kernel .text 0xc0100000 0xc01197c8 0xc011a1b0 0xe7cafd3c 0xf88838e5 [xfs]_sv_wait+0xcd (0xf77f0d98, 0xf7cee914, 0x282, 0x0, 0x0) xfs .text 0xf8830060 0xf8883818 0xf8883900 0xe7cafd68 0xf8867fa5 [xfs]xlog_grant_log_space+0x139 (0xf7cee880, 0xf77f0d98, 0xf43ae400, 0x78228, 0xf7cee880) xfs .text 0xf8830060 0xf8867e6c 0xf88680d0 0xe7cafda0 0xf8866587 [xfs]xfs_log_reserve+0x7b (0xf43ae400, 0x268b8, 0x3, 0xee046bf4, 0x69) xfs .text 0xf8830060 0xf886650c 0xf8866594 0xe7cafdcc 0xf887390a [xfs]xfs_trans_reserve+0x76 (0xee046bc0, 0x29, 0x268b8, 0x0, 0x4) xfs .text 0xf8830060 0xf8873894 0xf88739b4 0xe7cafe7c 0xf887be5d [xfs]xfs_mkdir+0x20d (0xccbcc968, 0xc64d9120, 0xe7cafecc, 0xe7cafec8, 0x0) xfs .text 0xf8830060 0xf887bc50 0xf887c280 0xe7caff3c 0xf88824dc [xfs]linvfs_common_cr+0x11c (0xc75043a0, 0xc64d90c0, 0x1ed, 0x2, 0x0) xfs .text 0xf8830060 0xf88823c0 0xf888253c 0xe7caff58 0xf888282c [xfs]linvfs_mkdir+0x18 (0xc75043a0, 0xc64d90c0, 0x1ed) xfs .text 0xf8830060 0xf8882814 0xf8882830 0xe7caff7c 0xc0141614 vfs_mkdir+0xd8 (0xc75043a0, 0xc64d90c0, 0x1ed) kernel .text 0xc0100000 0xc014153c 0xc0141664 0xe7caffbc 0xc01416d5 sys_mkdir+0x71 (0x807ca8d, 0x1ed, 0x807ca92, 0x5, 0xf) kernel .text 0xc0100000 0xc0141664 0xc0141718 0xc010a860 system_call+0x34 kernel .text 0xc0100000 0xc010a82c 0xc010a864 btw, this is on the 2.4.0-4SGI_29smp kernel from PP 1.4 ALPHA 0009072336. -tduffy From owner-linux-xfs@oss.sgi.com Mon Sep 11 21:03:04 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 21:02:45 -0700 Received: from [61.129.40.19] ([61.129.40.19]:40453 "EHLO mailsrv.portalhands.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 21:02:27 -0700 Received: from LocalHost (home145 [10.168.2.145]) by mailsrv.portalhands.com (8.9.3/8.8.7) with SMTP id LAA25810 for ; Tue, 12 Sep 2000 11:54:53 +0800 Message-ID: <000801c01c6e$780be680$9102a80a@LocalHost> From: "albert liu" To: Subject: Date: Tue, 12 Sep 2000 12:03:53 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C01CB1.8554F320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C01CB1.8554F320 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 c3Vic2NyaWJlIGxpbnV4LXhmcyB5b3VyQGVtYWlsLmFkZHJlc3MNCg== ------=_NextPart_000_0005_01C01CB1.8554F320 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5zdWJzY3JpYmUgbGludXgt eGZzIDxBIA0KaHJlZj0ibWFpbHRvOnlvdXJAZW1haWwuYWRkcmVzcyI+eW91ckBlbWFpbC5hZGRy ZXNzPC9BPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0005_01C01CB1.8554F320-- From owner-linux-xfs@oss.sgi.com Mon Sep 11 21:03:04 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 21:02:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:18763 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 21:02:33 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA14509; Mon, 11 Sep 2000 20:54:52 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id VAA23620; Mon, 11 Sep 2000 21:00:45 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA12764; Mon, 11 Sep 2000 20:59:28 -0700 (PDT) Date: Mon, 11 Sep 2000 20:59:28 -0700 (PDT) Message-Id: <200009120359.UAA12764@info.engr.sgi.com> X-Pv-Incident: 768238 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 768238 - Volume Manager work for XFS on Linux To: n8992@sgi.com Cc: slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=768238 Status : open Priority : 1 Assigned Engineer : n8992 Submitter : mostek *Modified User : nathans *Modified User Domain : engr *Description : The interactions between XFS and volume managers on Linux need to be investigated, designed, and implemented. This includes enhancing slinx-xfs/cmd/xfs/sim/src/libdisk.c to also deal with volume managers. i. Install LVM on a machine and integrate with XFS. ii. Install/configure md on a machine and integrate with XFS. iii. port xlv_get_subvolumes() to a more generic routine and implement to handle multiple Linux volume managers. iv. libdisk needs to: ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Sep 11 2000 08:59:28PM ========================== Been asked on status of lvm and xfs user tools (mkfs) - here's the last I heard on this from Martin ... I believe this is the current status. Putting it here for posterity... On Jul 25, 11:38am, Martin K. Petersen wrote: > Subject: Re: LVM vs. kiobuf I/O > > >> - mkfs support for querying LVM stripe size/width > ... > Nathan> Also, from what you say above, I take it mkfs is now going to > Nathan> be linked with liblvm? > > ... Although liblvm is a part of the > LVM package, it isn't designed to be a generic library. I've been > doing all kinds of surgery to the include files etc., and I'm still > unable to build binaries linked to liblvm outside the LVM tree. > > Right now I'm more concerned about getting the LVM kiobuf support > running. > On Aug 1, 3:47pm, Martin K. Petersen wrote: > Subject: Re: LVM vs. kiobuf I/O > ... > [liblvm] > > Nathan> Does it go through the ioctl interface? perhaps you could > Nathan> make the calls directly & bypass the library altogether? > > I can do it via ioctls, yes, but I'd end up reinventing a lot of the > existing liblvm code. > > I'll consider it once the kiobuf support for LVM is complete. > From owner-linux-xfs@oss.sgi.com Mon Sep 11 21:19:54 2000 Received: by oss.sgi.com id ; Mon, 11 Sep 2000 21:19:44 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:51031 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 11 Sep 2000 21:19:21 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA02082; Mon, 11 Sep 2000 21:25:59 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id VAA15009; Mon, 11 Sep 2000 21:19:20 -0700 (PDT) Date: Mon, 11 Sep 2000 21:19:20 -0700 (PDT) Message-Id: <200009120419.VAA15009@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: REPRIORITIZE 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 Status : open *Priority : 4 Assigned Engineer : nathans Submitter : lord Opened Date : 09/06/00 *Severity : 3 *Modified User : nathans *Modified User Domain : engr *Description : Running mkfs to build an xfs filesystem after a partition has been mounted as ext2 has periodically failed for me. The failure is usually this: [root@lord /]# mkfs -t xfs -f -l size=16000b /dev/sda4 meta-data=/dev/sda4 isize=256 agcount=8, agsize=149104 blks data = bsize=4096 blocks=1192826, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 ..... ========================== ADDITIONAL INFORMATION (REPRIORITIZE) From: nathans@engr (BugWorks) Date: Sep 11 2000 09:19:19PM ========================== Been asked to prioritise this down as it does not need immediate attention before beta - with the initial change to mkfs, we are no longer at immediate risk. WRT the external log case from yesterday, this does not fail because the size of the log must be a multiple of the filesystem blocksize (mkfs enforces this), so we never attempt a write in the last sub-4K part of the device, so never hit the out-of-space condition. I imagine this will become a problem when attempting to mkfs an xfs filesystem using a block size of less than 4Kb, however - that puts our writes us back into the <4K window at the end of the device. From owner-linux-xfs@oss.sgi.com Tue Sep 12 04:50:07 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 04:49:57 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26983 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 04:49:37 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id EAA03051; Tue, 12 Sep 2000 04:56:15 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id EAA73649; Tue, 12 Sep 2000 04:49:36 -0700 (PDT) Date: Tue, 12 Sep 2000 04:49:36 -0700 (PDT) Message-Id: <200009121149.EAA73649@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: 192.82.201.223 webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: tduffy@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 Assigned Engineer : lord Submitter : ananth *Modified User : lord *Modified User Domain : sgi.com *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 12 2000 04:49:33AM ========================== So it appears timing is everything, because this morning there is nothing hung on the machine. Looks like the hang is not indefinite. Here is what needs dumping from a hang should it happen again. feed the first parameter of xlog_grant_log_space into the xlog kdb command. In the third line of output there is a parameter ICLOG, pass this to the xicall command. This should produce output like this: [0]kdb> xicall 0xf44d0000 xlog_in_core/header at 0xf44d0000 magicno: feedbabe cycle: 1519 version: 1 lsn: 0x0 tail_lsn: 0x5ef00001d4c len: 1060 prev_block: 8376 num_ops: 0 cycle_data: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -------------------------------------------------- data: 0xf44d0400 &forcesema: 0xf44d0000 next: 0xf4f80000 bp: 0xf70e6da0 log: 0xf7cee880 callb: 0x00000000 callb_tail: 0xf44d0020 roundoff: 476 size: 32256 (OFFSET: 0) trace: 0x00000000 refcnt: 0 bwritecnt: 0 state: state 0x1 ================================================= xlog_in_core/header at 0xf4f80000 magicno: feedbabe cycle: 1519 version: 1 lsn: 0x0 tail_lsn: 0x5ef000020f8 len: 224 prev_block: 8440 num_ops: 0 cycle_data: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -------------------------------------------------- data: 0xf4f80400 &forcesema: 0xf4f80000 next: 0xf44d0000 bp: 0xf70e6d00 log: 0xf7cee880 callb: 0x00000000 callb_tail: 0xf4f80020 roundoff: 288 size: 32256 (OFFSET: 0) trace: 0x00000000 refcnt: 0 bwritecnt: 0 state: state 0x1 ================================================= There are a couple of bp fields in this output. these need passing into the pb command. So from this example: [0]kdb> pb 0xf70e6da0 page_buf_t at 0xf70e6da0 pb_flags MAPPED ASYNC SYNC LOCKABLE FORECIO pb_target 0xf735a200 pb_hold 1 pb_next 0xf70e6da0 pb_prev 0xf70e6da0 pb_file_offset 0x0 pb_buffer_length 0x800 pb_addr 0xf44d0200 pb_bn 0x79a118 pb_count_desired 0x800 pb_io_remaining 0 pb_error 0 pba_kiovec[0] 0xf3012d40 pba_kiocnt 1 pb_iodonesema (0,0) pb_sema (0,0) pincount (0) last holder 0xf7538000 pb_fspriv 0xf44d0000 pb_fspriv2 0x00000001 [0]kdb> pb 0xf70e6d00 page_buf_t at 0xf70e6d00 pb_flags MAPPED ASYNC SYNC LOCKABLE FORECIO pb_target 0xf735a200 pb_hold 1 pb_next 0xf70e6d00 pb_prev 0xf70e6d00 pb_file_offset 0x0 pb_buffer_length 0x400 pb_addr 0xf4f80200 pb_bn 0x79a11c pb_count_desired 0x400 pb_io_remaining 0 pb_error 0 pba_kiovec[0] 0xf3012dc0 pba_kiocnt 1 pb_iodonesema (0,0) pb_sema (0,0) pincount (0) last holder 0xf7538000 pb_fspriv 0xf4f80000 pb_fspriv2 0x00000001 Also from the xlog output there is an mp: field on the fifth line , this needs feeding into the xmount command, and the xail command. If the hang happens again, please put all this info into the PV, it really looks like this is not a permanent hang, but a missed wakeup which is getting compensated for by something else in the system. From owner-linux-xfs@oss.sgi.com Tue Sep 12 06:41:01 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 06:40:41 -0700 Received: from tux.mkp.net ([130.225.60.11]:33806 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 06:40:36 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=tyra.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 13YqCn-0001Ke-00; Tue, 12 Sep 2000 15:34:34 +0200 Received: (from mkp@localhost) by tyra.mkp.net (8.9.3/8.9.3) id JAA30716; Tue, 12 Sep 2000 09:39:54 -0400 X-Authentication-Warning: tyra.mkp.net: mkp set sender to mkp@mkp.net using -f To: sgi.bugs.xfs@fido.engr.sgi.com Cc: n8992@sgi.com, slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Subject: Re: ADD 768238 - Volume Manager work for XFS on Linux References: <200009120359.UAA12764@info.engr.sgi.com> From: "Martin K. Petersen" Organization: mkp.net Date: 12 Sep 2000 09:39:54 -0400 In-Reply-To: pv@fddi-odin.corp.sgi.com's message of "Mon, 11 Sep 2000 20:59:28 -0700 (PDT)" Message-ID: Lines: 18 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Nathan> On Aug 1, 3:47pm, Martin K. Petersen wrote: >> Subject: Re: LVM vs. kiobuf I/O ... [liblvm] >> Nathan> Does it go through the ioctl interface? perhaps you could Nathan> make the calls directly & bypass the library altogether? >> >> I can do it via ioctls, yes, but I'd end up reinventing a lot of >> the existing liblvm code. >> >> I'll consider it once the kiobuf support for LVM is complete. Since our target changed a bit for beta, I'll attack the stripe size/width extracting code again... -- Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME From owner-linux-xfs@oss.sgi.com Tue Sep 12 06:46:41 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 06:46:31 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13165 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 06:46:25 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA00780; Tue, 12 Sep 2000 06:53:03 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA40103; Tue, 12 Sep 2000 06:45:04 -0700 (PDT) Date: Tue, 12 Sep 2000 06:45:04 -0700 (PDT) Message-Id: <200009121345.GAA40103@feature.engr.sgi.com> X-Pv-Incident: 768238 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (mkp@mkp.net.sgi.com) Subject: ADD 768238 - Volume Manager work for XFS on Linux To: n8992@sgi.com Cc: slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : mostek Status : open Assigned Engineer : n8992 Priority : 1 *Modified Date : 09/12/00 *Modified User : mkp *Modified User Domain : mkp.net *Description : The interactions between XFS and volume managers on Linux need to be investigated, designed, and implemented. This includes enhancing slinx-xfs/cmd/xfs/sim/src/libdisk.c to also deal with volume managers. i. Install LVM on a machine and integrate with XFS. ii. Install/configure md on a machine and integrate with XFS. iii. port xlv_get_subvolumes() to a more generic routine and implement to handle multiple Linux volume managers. iv. libdisk needs to: ..... ========================== ADDITIONAL INFORMATION (ADD) From: "martin k. petersen" Date: Sep 12 2000 06:45:04AM [pvnews version: 1.71] ========================== Nathan> On Aug 1, 3:47pm, Martin K. Petersen wrote: >> Subject: Re: LVM vs. kiobuf I/O ... [liblvm] >> Nathan> Does it go through the ioctl interface? perhaps you could Nathan> make the calls directly & bypass the library altogether? >> >> I can do it via ioctls, yes, but I'd end up reinventing a lot of >> the existing liblvm code. >> >> I'll consider it once the kiobuf support for LVM is complete. Since our target changed a bit for beta, I'll attack the stripe size/width extracting code again... -- Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME From owner-linux-xfs@oss.sgi.com Tue Sep 12 07:12:51 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 07:12:41 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:57378 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 07:12:14 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA28736 for ; Tue, 12 Sep 2000 07:04:33 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA58000 for ; Tue, 12 Sep 2000 09:10:57 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA67877 for ; Tue, 12 Sep 2000 09:10:56 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id JAA01236; Tue, 12 Sep 2000 09:08:59 -0500 Message-Id: <200009121408.JAA01236@jen.americas.sgi.com> Date: Tue, 12 Sep 2000 09:08:59 -0500 Subject: TAKE - a couple of kdb command tweaks To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Sep 12 07:10:22 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74219a linux/kdb/modules/kdbm_pg.c - 1.17 - a couple of debugging cleanups - change LONG_TERM to MAPPABLE in pagebuf flags, and dump a couple more erequest and buffer head fields. From owner-linux-xfs@oss.sgi.com Tue Sep 12 09:22:42 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 09:22:32 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5893 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 09:22:22 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA04275 for ; Tue, 12 Sep 2000 09:29:00 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA93437; Tue, 12 Sep 2000 11:21:03 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id LAA02211; Tue, 12 Sep 2000 11:21:03 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e8CGL2e05340; Tue, 12 Sep 2000 11:21:02 -0500 Message-ID: <39BE57EC.24832984@thebarn.com> Date: Tue, 12 Sep 2000 11:21:01 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Martin K. Petersen" CC: linux-xfs@oss.sgi.com Subject: Re: ADD 768238 - Volume Manager work for XFS on Linux References: <200009120359.UAA12764@info.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Martin K. Petersen" wrote: > Nathan> On Aug 1, 3:47pm, Martin K. Petersen wrote: > >> Subject: Re: LVM vs. kiobuf I/O ... [liblvm] > >> > Nathan> Does it go through the ioctl interface? perhaps you could > Nathan> make the calls directly & bypass the library altogether? > >> > >> I can do it via ioctls, yes, but I'd end up reinventing a lot of > >> the existing liblvm code. > >> > >> I'll consider it once the kiobuf support for LVM is complete. > > Since our target changed a bit for beta, I'll attack the stripe > size/width extracting code again... At this point we should just concentrate on why LVM is corrupting meta data. > > > -- > Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. > http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME From owner-linux-xfs@oss.sgi.com Tue Sep 12 10:59:53 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 10:59:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58471 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 10:59:20 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA01707; Tue, 12 Sep 2000 10:51:39 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA14681; Tue, 12 Sep 2000 10:57:33 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id KAA29189; Tue, 12 Sep 2000 10:56:16 -0700 (PDT) Date: Tue, 12 Sep 2000 10:56:16 -0700 (PDT) Message-Id: <200009121756.KAA29189@info.engr.sgi.com> X-Pv-Incident: 768249 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: REPRIORITIZE 768249 - XFS must be a 64 bit file system on Linux To: cattelan@engr.sgi.com Cc: slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=768249 Status : open *Priority : 3 Assigned Engineer : cattelan Submitter : mostek Opened Date : 09/23/99 *Modified User : cattelan *Modified User Domain : engr *Description : The 64 bit patch needs to be studied and carried through the XFS code. There are many types (as mentioned above) that are different sizes between XFS and Linux. The 64 bit issue deals with making sure we can do reads/writes/lseeks/fcntls/... with types which are large enough. i.) Linux VFS needs to be changed. ii.) new syscalls are needed. iii.) glibc issues (e.g. ftruncate64 will fail if the len parameter does not fit in 32 bits). ..... ========================== ADDITIONAL INFORMATION (REPRIORITIZE) From: cattelan@engr (BugWorks) Date: Sep 12 2000 10:56:15AM ========================== From owner-linux-xfs@oss.sgi.com Tue Sep 12 11:38:22 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 11:38:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8469 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 11:37:55 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA01289; Tue, 12 Sep 2000 11:44:33 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA01014; Tue, 12 Sep 2000 11:37:53 -0700 (PDT) Date: Tue, 12 Sep 2000 11:37:53 -0700 (PDT) Message-Id: <200009121837.LAA01014@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: ADD 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: tduffy@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 Assigned Engineer : lord Submitter : ananth *Modified User : ananth *Modified User Domain : engr *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: ananth@engr (BugWorks) Date: Sep 12 2000 11:37:52AM ========================== First, the system did get back to normal state after the apparent process hangs yesterday. I could compile, edit, etc. on that FS several times. Eventually the problem surfaced again. This time it is a "mv" command, pid 5031. I'm going to leave the system in kdb so the hung process doesn't go away. Following is the debug information requested. Tom, can you please leave the system in kdb until Steve gets a chance to look into things? BTW, I'm not at the office today. ---------- [0]kdb> btp 5031 EBP EIP Function(args) 0xc9f3dcf4 0xc0119bdd schedule+0x415 (0xf77f0cd0) kernel .text 0xc0100000 0xc01197c8 0xc011a1b0 0xc9f3dd30 0xf88838e5 [xfs]_sv_wait+0xcd (0xf77f0cd0, 0xf7cee914, 0x282, 0x0, 0x0) xfs .text 0xf8830060 0xf8883818 0xf8883900 0xc9f3dd5c 0xf8867fa5 [xfs]xlog_grant_log_space+0x139 (0xf7cee880, 0xf77f0cd0, 0xf43ae400, 0x9aa70, 0xf7cee880) xfs .text 0xf8830060 0xf8867e6c 0xf88680d0 0xc9f3dd94 0xf8866587 [xfs]xfs_log_reserve+0x7b (0xf43ae400, 0x4ab38, 0x2, 0xed2a0994, 0x69) xfs .text 0xf8830060 0xf886650c 0xf8866594 0xc9f3ddc0 0xf887390a [xfs]xfs_trans_reserve+0x76 (0xed2a0960, 0x3f, 0x4ab38, 0x0, 0x4) xfs .text 0xf8830060 0xf8873894 0xf88739b4 0xc9f3deac 0xf886fb80 [xfs]xfs_rename+0x394 (0xf1e65b94, 0xdc10c5e0, 0xf14d97c0, 0xd28c4580, 0xc9f3def4) xfs .text 0xf8830060 0xf886f7ec 0xf8870280 0xc9f3df00 0xf88829a2 [xfs]linvfs_rename+0x7a (0xf14d96e0, 0xc53192c0, 0xf14d96e0, 0xd28c4520) xfs .text 0xf8830060 0xf8882928 0xf8882a30 0xc9f3df24 0xc01428e8 vfs_rename_other+0x270 (0xf14d96e0, 0xc53192c0, 0xf14d96e0, 0xd28c4520) kernel .text 0xc0100000 0xc0142678 0xc0142934 0xc9f3df44 0xc0142960 vfs_rename+0x2c (0xf14d96e0, 0xc53192c0, 0xf14d96e0, 0xd28c4520) kernel .text 0xc0100000 0xc0142934 0xc0142974 0xc9f3dfbc 0xc0142b38 sys_rename+0x1c4 (0xbffff394, 0xbffff3d1, 0xbffff0ec, 0x1, 0xbffff3d1) kernel .text 0xc0100000 0xc0142974 0xc0142bfc 0xc010a860 system_call+0x34 kernel .text 0xc0100000 0xc010a82c 0xc010a864 [0]more> [0]kdb> xlog 0xf7cee880 xlog at 0xf7cee880 &flushsm: 0xf7cee880 tic_cnt: 100 tic_tcnt: 102 freelist: 0xf77f07a8 tail: 0xf77f0230 ICLOG: 0xf44d0000 &icloglock: 0xf7cee8b4 tail_lsn: 0x5f000002094 last_sync_lsn: 0x5f100001bdf mp: 0xf43ae400 xbuf: 0xf70e6e40 roundoff: 444 l_covered_state: need flags: log 0x0 <> dev: 0x811 logBBstart: 7962656 logsize: 4915200 logBBsize: 9600 curr_cycle: 1521 prev_cycle: 1521 curr_block: 7141 prev_block: 7135 iclog_bak: 0xf7cee904 iclog_size: 0x8000 (32768) num iclogs: 2 &grant_lock: 0xf7cee914 resHeadQ: 0xf77f0cd0 wrHeadQ: 0x00000000 GResCycle: 1521 GResBytes: 3655748 GWrCycle: 1521 GWrBytes: 3655748 GResBlocks: 7141 GResRemain: 0 GWrBlocks: 7141 GWrRemain: 0 [0]kdb> xicall 0xf44d0000 xlog_in_core/header at 0xf44d0000 magicno: feedbabe cycle: 1521 version: 1 lsn: 0x0 tail_lsn: 0x5f000002094 len: 3764 prev_block: 7116 num_ops: 0 cycle_data: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -------------------------------------------------- data: 0xf44d0400 &forcesema: 0xf44d0000 next: 0xf4f80000 bp: 0xf70e6da0 log: 0xf7cee880 callb: 0x00000000 callb_tail: 0xf44d0020 roundoff: 332 size: 32256 (OFFSET: 0) trace: 0x00000000 refcnt: 0 bwritecnt: 0 state: state 0x1 ================================================= xlog_in_core/header at 0xf4f80000 magicno: feedbabe cycle: 1521 version: 1 lsn: 0x0 tail_lsn: 0x5f000002094 len: 2448 prev_block: 7126 num_ops: 0 cycle_data: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -------------------------------------------------- data: 0xf4f80400 &forcesema: 0xf4f80000 next: 0xf44d0000 bp: 0xf70e6d00 log: 0xf7cee880 callb: 0x00000000 callb_tail: 0xf4f80020 roundoff: 112 size: 32256 (OFFSET: 0) trace: 0x00000000 refcnt: 0 bwritecnt: 0 state: state 0x1 ================================================= [0]kdb> pb 0xf70e6da0 page_buf_t at 0xf70e6da0 pb_flags MAPPED ASYNC SYNC LOCKABLE FORECIO pb_target 0xf735a200 pb_hold 1 pb_next 0xf70e6da0 pb_prev 0xf70e6da0 pb_file_offset 0x0 pb_buffer_length 0x1200 pb_addr 0xf44d0200 pb_bn 0x799bf6 pb_count_desired 0x1200 pb_io_remaining 0 pb_error 0 pba_kiovec[0] 0xf3012d40 pba_kiocnt 1 pb_iodonesema (0,0) pb_sema (0,0) pincount (0) last holder 0xf7538000 pb_fspriv 0xf44d0000 pb_fspriv2 0x00000001 [0]kdb> pb 0xf70e6d00 page_buf_t at 0xf70e6d00 pb_flags MAPPED ASYNC SYNC LOCKABLE FORECIO pb_target 0xf735a200 pb_hold 1 pb_next 0xf70e6d00 pb_prev 0xf70e6d00 pb_file_offset 0x0 pb_buffer_length 0xc00 pb_addr 0xf4f80200 pb_bn 0x799bff pb_count_desired 0xc00 pb_io_remaining 0 pb_error 0 pba_kiovec[0] 0xf3012dc0 pba_kiocnt 1 pb_iodonesema (0,0) pb_sema (0,0) pincount (0) last holder 0xf7538000 pb_fspriv 0xf4f80000 pb_fspriv2 0x00000001 [0]kdb> xmount 0xf43ae400 xfs_mount at 0xf43ae400 vfsp 0xf7715a60 tid 0x0 ail_lock 0xf43ae414 &ail 0xf43ae418 ail_gen 0x40270 &sb 0xf43ae424 sb_lock 0xf43ae4ec sb_bp 0xf70e6ee0 dev 0x811 logdev 0x811 rtdev 0x0 bsize 8 agfrotor 4 agirotor 1 ihash 0xf70d8000 ihsize 332 inodes 0xd0bcfc88 ilock 0xf43ae514 ireclaims 0x2c5f readio_log 0x10 readio_blocks 0x10 writeio_log 0x10 writeio_blocks 0x10 logbufs -1 logbsize -1 LOG 0xf7cee880 rsumlevels 0x0 rsumsize 0x0 rbmip 0x00000000 rsumip 0x00000000 rootip 0xf730cc88 dircook_elog 0 blkbit_log 15 blkbb_log 3 agno_log 4 agino_log 22 nreadaheads 4 inode cluster size 8192 blockmask 0xfff blockwsize 0x400 blockwmask 0x3ff alloc_mxr[lf,nd] 510 340 alloc_mnr[lf,nd] 255 170 bmap_dmxr[lfnr,ndnr] 254 254 bmap_dmnr[lfnr,ndnr] 127 127 inobt_mxr[lf,nd] 255 510 inobt_mnr[lf,nd] 127 255 ag_maxlevels 3 bm_maxlevels[d,a] 5 3 in_maxlevels 3 perag 0xf7cee980 &peraglock 0xf43ae5d8 &growlock 0xf43ae600 flags 0x0 <> ialloc_inos 64 ialloc_blks 4 litino 156 attroffset 120 da_node_ents 510 maxicount 8957888 inoalign_mask 1 resblks 0 resblks_avail 0 inoadd 0 quotainfo NULL [0]more> quotaflags 0x0 <> dalign 0 swidth 0 sinoalign 0 attr_magicpct 1515 dir_magicpct 1515 mk_sharedro 0 dirversion 2 dirblkfsbs 1 &dirops 0xf43ae6cc dirblksize 4096 dirdatablk 0x0 dirleafblk 0x800000 dirfreeblk 0x1000000 chsize 37 chash 0xf5bcec00 mountpoint "sd(8,17)" [0]kdb> xail 0xf43ae400 AIL for mp 0xf43ae400, oldest first [0] type inode flags: 0x1 lsn [5f0:2094] inode 0xf730cc88 logged 0 flags: 0x0 <> format: 0x1 lastfield: 0x0 <> From owner-linux-xfs@oss.sgi.com Tue Sep 12 12:47:33 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 12:47:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16414 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 12:47:00 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA07780; Tue, 12 Sep 2000 12:53:39 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id MAA41985; Tue, 12 Sep 2000 12:46:59 -0700 (PDT) Date: Tue, 12 Sep 2000 12:46:59 -0700 (PDT) Message-Id: <200009121946.MAA41985@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: tduffy@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 Assigned Engineer : lord Submitter : ananth *Modified User : lord *Modified User Domain : sgi.com *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 12 2000 12:46:58PM ========================== This appears to be caused by something failing to sync the root inode of the filesystem. There is one item in the AIL (in log, but modified in memory still). This is an inode: xnode 0xf730cc88 hash 0xf70d9800 next 0x00000000 prevp 0xf2595688 mount 0xf43ae400 mnext 0xd0bcfc88 mprev 0xf730ca7c vnode 0xf735a160 dev 811 ino 128[0:8:0] blkno 0x40 len 0x10 boffset 0x0 transp 0x00000000 &itemp 0xf3007de8 &lock 0xf730cd14 lock_ra 0x00000000 &iolock 0xf730cd3c udquotp 0x00000000 pdquotp 0x00000000 &flock 0xf730cd64 (1) &pinlock 0xf730cd8c pincount 0x0 &pinsema 0xf730cd7c &rlock 0xf730cda8 next_offset 0 io_offset 0 reada_blkno 0[0:0] io_size 0x0 last_req_sz 0x0 new_size 0 write off 0 gap list 0x00000000 readiolog 16, readioblocks 16, writeiolog 16, writeioblocks 16, maxiolog 16 flags 0x0 <> update_core 0x0 update size 0x0 gen 0x0 qbufs 0 delayed blks 0 chash 0xf44cfb10 cnext 0xca46a8d0 cprev 0xe7e13990 data fork bytes 0x2d real_bytes 0x30 lastex 0x0 u1:data 0xf7715920 broot 0x00000000 broot_bytes 0x0 ext_max 9 flags 0x1 u2 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 attr fork empty magic 0x494e mode 040777 (d---rwxrwxrwx) version 0x1 format 0x1 (local) nlink 0x5 uid 0x0 gid 0x0 projid 0x0 atime 0x39be151e:2de54480 mtime 0x39a6c3d3:2fc03e40 ctime 0x39a6c3d3:2fc03e40 size 0x2d nblocks 0 extsize 0x0 nextents 0x0 anextents 0x0 forkoff 0 aformat 0x2 (extents) dmevmask 0x0 dmstate 0x0 flags 0x0 <> gen 0x0 I will dig some more, but in the meantime, the machine is dead again - the xfs kdb commands are way too dangerous in the way we can crash the debugger. From owner-linux-xfs@oss.sgi.com Tue Sep 12 13:18:53 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 13:18:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59426 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 13:18:24 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA07381 for ; Tue, 12 Sep 2000 13:25:02 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id PAA20160 for ; Tue, 12 Sep 2000 15:17:07 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id PAA08323 for ; Tue, 12 Sep 2000 15:17:06 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e8CKH6t05971 for linux-xfs@oss.sgi.com; Tue, 12 Sep 2000 15:17:06 -0500 Date: Tue, 12 Sep 2000 15:17:06 -0500 From: Russell Cattelan Message-Id: <200009122017.e8CKH6t05971@gibble.americas.sgi.com> Subject: TAKE - Add the qlogic 2x00 (aka FC) To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This driver seems to clear up the data corruption that was occurring with the other qlogic driver. Note there is a bug with this driver: Once in a while while the routine qM_symbols will panic the system with a "Unable to handle kernel paging request at virtul address x" I'll try to track down the problem. -Russell Date: Tue Sep 12 13:09:29 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74248a linux/drivers/scsi/qla2x00.h - 1.1 linux/drivers/scsi/ql2100_fw.h - 1.1 linux/drivers/scsi/ql2200_fw.h - 1.1 linux/drivers/scsi/qla2x00.c - 1.1 linux/drivers/scsi/hosts.c - 1.19 linux/drivers/scsi/Makefile - 1.18 linux/drivers/scsi/Config.in - 1.15 - Added qlogic 2x00 driver From owner-linux-xfs@oss.sgi.com Tue Sep 12 14:04:03 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 14:03:54 -0700 Received: from hermes.mixx.net ([212.84.196.2]:54023 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 12 Sep 2000 14:03:34 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id AE3EDF814 for ; Tue, 12 Sep 2000 23:03:32 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 2E80D2CA6D; Tue, 12 Sep 2000 23:03:32 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs as root fs Date: 12 Sep 2000 21:03:32 GMT Organization: innominate AG, Berlin, Germany Lines: 43 Distribution: local Message-ID: References: <200009111503.KAA13587@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968792612 32573 10.0.0.69 (12 Sep 2000 21:03:32 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> btw. i redid all on my machine at home: rebuild the tools after a >> make realclean, built a fresh kernel (sources from friday 8.9.) >> and re-mkfs.xfs'ed the filesystems - so far i was not able to >> reproduce the problem again - but i will keep an eye on it >> and try this patch then ... will do the same procedure as >> above now for the two testmachines here at work too >> >> but what i discovered was something i remembered having read about >> being fixed a few days ago (but could not find it in the mails): >> after running xfs_repair on an (unmounted) xfs fs - mounting >> it directly after that - unmounting it again ... now a new >> mount try fails with log problems - running xfs_repair >> (which does not find any errors) fixes the problem >> so the fs is mountable after that ... it also >> works in normal use (without the mount short >> after the xfs_repair) ... but i'll look at >> it closer and give more details (btw. all >> the stuff was from fri 8.9. so _after_ i >> read about the fix) > Ugh!, I will give this a try. this is what i get for the failed mount retrys: Start mounting filesystem: ide0(3,5) XFS: xlog_find_verify_log_record: need to back-up XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed as said - it works perfectly again after an xfs_repair which does not show any error t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Tue Sep 12 14:47:53 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 14:47:34 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:14642 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 14:47:11 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA05805; Tue, 12 Sep 2000 14:39:30 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA41127; Tue, 12 Sep 2000 14:47:07 -0700 (PDT) Date: Tue, 12 Sep 2000 14:47:07 -0700 (PDT) Message-Id: <200009122147.OAA41127@info.engr.sgi.com> X-Pv-Incident: 800992 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: OBSERVE 800992 - pagebuf_init call to kmem_cache_create BUG() To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800992 *Status : observe Priority : 4 Assigned Engineer : dxm Submitter : dxm Opened Date : 09/05/00 *Closed Date : 09/12/00 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 09/12/00 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (OBSERVE) From: dxm@engr (BugWorks) Date: Sep 12 2000 02:47:07PM ========================== I haven't seen this problem since. I suspect it was caused by XFS getting into a funny state due to other problems. Keep and eye out for this one to see if it can happen again. From owner-linux-xfs@oss.sgi.com Tue Sep 12 14:50:23 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 14:50:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64556 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 14:50:03 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA09616; Tue, 12 Sep 2000 14:56:42 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA02321; Tue, 12 Sep 2000 14:49:32 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA00456; Tue, 12 Sep 2000 14:48:13 -0700 (PDT) Date: Tue, 12 Sep 2000 14:48:13 -0700 (PDT) Message-Id: <200009122148.OAA00456@info.engr.sgi.com> X-Pv-Incident: 801095 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: REPRIORITIZE 801095 - xfs_repair sucks memory in phase7 To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801095 Status : open *Priority : 4 Assigned Engineer : dxm Submitter : dxm Opened Date : 09/06/00 *Modified User : dxm *Modified User Domain : engr *Description : xfs_repair -n phase7 seems to leak memory big time, chewing up over 100Mb on sagan and causing processes to get nuked. ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 07 2000 08:15:50AM ========================== ..... ========================== ADDITIONAL INFORMATION (REPRIORITIZE) From: dxm@engr (BugWorks) Date: Sep 12 2000 02:48:13PM ========================== With the worst of the leakage gone, this is now low priority and not required for beta. From owner-linux-xfs@oss.sgi.com Tue Sep 12 14:51:33 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 14:51:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3117 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 14:51:09 -0700 Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA05423 for ; Tue, 12 Sep 2000 14:57:46 -0700 (PDT) mail_from (kenmcd@melbourne.sgi.com) Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id IAA96460 for ; Wed, 13 Sep 2000 08:49:50 +1100 (AEDT) X-Authentication-Warning: rattle.melbourne.sgi.com: kenmcd owned process doing -bs Date: Wed, 13 Sep 2000 08:49:50 +1100 From: Ken McDonell Reply-To: kenmcd@melbourne.sgi.com To: xfs@oss.sgi.com Subject: Re: xfs as root fs In-Reply-To: <39BD8649.D1FBDC9B@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 11 Sep 2000 08:03:10 GMT, Thomas Graichen wrote: > > but what i discovered was something i remembered having read about > being fixed a few days ago (but could not find it in the mails): > after running xfs_repair on an (unmounted) xfs fs - mounting > it directly after that - unmounting it again ... now a new > mount try fails with log problems - running xfs_repair > (which does not find any errors) fixes the problem > so the fs is mountable after that ... it also > works in normal use (without the mount short > after the xfs_repair) ... but i'll look at > it closer and give more details (btw. all > the stuff was from fri 8.9. so _after_ i > read about the fix) Thomas, if you still have the source tree that was used to make this kernel, can you please let me know which version of cmd/xfs/repair/phase2.c you have? The symptoms sound exactly like the problem Steve's take was aiming to fix, namely - repair (introduces error) - mount - umount - mount (2nd mount sees error) His fix was rev 1.30 of cmd/xfs/repair/phase2.c checked into the internal RCS tree at 11:42am PDT on Fri 9/8 ... it would not have appeared in the CVS tree until sometime later. From owner-linux-xfs@oss.sgi.com Tue Sep 12 15:18:44 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 15:18:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:45114 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 15:18:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA10150 for ; Tue, 12 Sep 2000 15:10:31 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29312; Wed, 13 Sep 2000 09:16:54 +1100 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA49038; Wed, 13 Sep 2000 09:16:53 +1100 (EST) Message-Id: <200009122216.JAA49038@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Chaitanya Tumuluri cc: linux-xfs@oss.sgi.com Subject: Re: QA 013 and kio/kiocluster. In-reply-to: Your message of "Tue, 12 Sep 2000 15:04:56 PDT." <200009122204.PAA71173@getafix.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Sep 2000 09:16:52 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Chaitanya Tumuluri writes: => Daniel, => => Is there anything special done to the stress scripts when they mount => and/or remount the TEST_DEV/TEST_DIR to use kio/kiocluster? The intent of the QA was that TEST_DIR wouldn't be mounted or unmounted by the tests, but it is. Mounting of SCRATCH_DEV is at the whim of the tests. Since there's no way of specifying mount options to QA (yet), it will remount the device back to the default options from time to time (eg when checking the FS). That's probably one to fix now that people are trying to test non-default mounts. For the moment, I'd modify linux/xfs_mount_opt.c in your work area so that your kernel defaults to the settings you'd like to use in the QA tests. I'll try to fix this and try out your other test hopefully later today. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Sep 12 16:35:45 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 16:35:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:31309 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 16:35:09 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA19776; Tue, 12 Sep 2000 16:27:27 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA80052; Tue, 12 Sep 2000 16:35:00 -0700 (PDT) Date: Tue, 12 Sep 2000 16:35:00 -0700 (PDT) Message-Id: <200009122335.QAA80052@info.engr.sgi.com> X-Pv-Incident: 801613 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 801613 - external log footer is incompatible with IRIX XFS To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801613 Submitter : dxm Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : XFS FSes with external logs are not compatible between IRIX and Linux. IRIX external log filesystems are unmountable on Linux XFS and Linux XFS external log filesystems on IRIX will be unmountable at best. This should be fixed for beta release. From owner-linux-xfs@oss.sgi.com Tue Sep 12 17:02:15 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 17:01:55 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35898 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 17:01:31 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA01761; Tue, 12 Sep 2000 17:08:10 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA40204; Tue, 12 Sep 2000 17:01:00 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA66834; Tue, 12 Sep 2000 16:59:40 -0700 (PDT) Date: Tue, 12 Sep 2000 16:59:40 -0700 (PDT) Message-Id: <200009122359.QAA66834@info.engr.sgi.com> X-Pv-Incident: 801613 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 801613 - external log footer is incompatible with IRIX XFS To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801613 Status : open Priority : 3 Assigned Engineer : dxm Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : XFS FSes with external logs are not compatible between IRIX and Linux. IRIX external log filesystems are unmountable on Linux XFS and Linux XFS external log filesystems on IRIX will be unmountable at best. This should be fixed for beta release. ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 12 2000 04:59:40PM ========================== My proposed fix is this: - do away with the log footer introduced in the Linux port - having both IRIX and Linux cope with logs with and without footers is a pain. Instead: - encode the FS uuid and "architecture" on which the log was created in the header of each log record. - This would allow: - Linux to check for matching UUID between FS and external log - Linux to check for clean "IRIX style" external logs, and still mount them - Either OS to detect logs containing dirty entries from the other OS and refuse to mount them. (Only clean FSes may be moved between IRIX & Linux) - Initially, IRIX would completely ignore the extra information an still happily mount clean Linux XFS FSes meaning that any changes to IRIX could be done at a leisurely pace. Issues: - handling of totally zeroed log (no entry in which to encode uuid) - either special case this (if the log is zeroed, it should be fine to use) - or have mkfs and repair generate a dummy first "unmount record" which contains the appropriate uuid etc. - the xlog_rec_header_t is padded out to 512 bytes in the log, allowing room for extra fields. The extra space may or may not be zeroed normally. This idea is still in its early stages, so I may have missed something here. Feedback welcome. From owner-linux-xfs@oss.sgi.com Tue Sep 12 17:25:45 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 17:25:36 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14908 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 17:25:12 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA01436 for ; Tue, 12 Sep 2000 17:31:50 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA66322 for linux-xfs@oss.sgi.com; Wed, 13 Sep 2000 11:22:37 +1100 (EST) Date: Wed, 13 Sep 2000 11:22:37 +1100 (EST) From: Daniel Moore Message-Id: <200009130022.LAA66322@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_logprint Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing two efence fixes. Modid: 2.4.0-test1-xfs:slinx:74271a Date: Tue Sep 12 17:22:20 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/logprint/log_misc.c - 1.70 - two efence fixes From owner-linux-xfs@oss.sgi.com Tue Sep 12 19:05:35 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 19:05:16 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:29701 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 19:04:56 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e8D24ga46247; Tue, 12 Sep 2000 21:04:43 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39BEE0B7.8050207@thebarn.com> Date: Tue, 12 Sep 2000 21:04:39 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.1-STABLE i386; en-US; m18) Gecko/20000813 X-Accept-Language: en MIME-Version: 1.0 To: kenmcd@melbourne.sgi.com, linux-xfs@oss.sgi.com Subject: Re: xfs as root fs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ken McDonell wrote: > On 11 Sep 2000 08:03:10 GMT, Thomas Graichen wrote: > > > > but what i discovered was something i remembered having read about > > being fixed a few days ago (but could not find it in the mails): > > after running xfs_repair on an (unmounted) xfs fs - mounting > > it directly after that - unmounting it again ... now a new > > mount try fails with log problems - running xfs_repair > > (which does not find any errors) fixes the problem > > so the fs is mountable after that ... it also > > works in normal use (without the mount short > > after the xfs_repair) ... but i'll look at > > it closer and give more details (btw. all > > the stuff was from fri 8.9. so _after_ i > > read about the fix) > > Thomas, if you still have the source tree that was used to make this > kernel, can you please let me know which version of > cmd/xfs/repair/phase2.c you have? > > The symptoms sound exactly like the problem Steve's take was aiming > to fix, namely > > - repair (introduces error) > - mount > - umount > - mount (2nd mount sees error) > > His fix was rev 1.30 of cmd/xfs/repair/phase2.c checked into the > internal RCS tree at 11:42am PDT on Fri 9/8 ... it would not have > appeared in the CVS tree until sometime later. Just a FYI/ Reminder here: The CVS tree version numbers are same as the "internal" version numbers. Also the tree is synced every hour, so any "TAKE" messages posted to the list shows up fairly quickly in the cvs repository. From owner-linux-xfs@oss.sgi.com Tue Sep 12 21:25:56 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 21:25:37 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:34060 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 21:25:13 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA19832 for ; Tue, 12 Sep 2000 21:17:30 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA13008 for linux-xfs@oss.sgi.com; Wed, 13 Sep 2000 15:23:51 +1100 (EST) Date: Wed, 13 Sep 2000 15:23:51 +1100 (EST) From: Daniel Moore Message-Id: <200009130423.PAA13008@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:74284a Date: Tue Sep 12 21:23:41 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/check - 1.8 - check we can source common.rc cmd/xfs/stress/common.config - 1.4 cmd/xfs/stress/common.dump - 1.13 cmd/xfs/stress/common.filter - 1.6 cmd/xfs/stress/common.rc - 1.28 cmd/xfs/stress/common.repair - 1.3 - add shell magic, make sure we return success on source From owner-linux-xfs@oss.sgi.com Tue Sep 12 21:48:15 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 21:48:05 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:34575 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 21:47:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA21337 for ; Tue, 12 Sep 2000 21:40:09 -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 PAA72247 for linux-xfs@oss.sgi.com; Wed, 13 Sep 2000 15:46:31 +1100 (EST) Date: Wed, 13 Sep 2000 15:46:31 +1100 (EST) From: Nathan Scott Message-Id: <200009130446.PAA72247@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cmds Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Fixes a build problem. Modid: 2.4.0-test1-xfs:slinx:74285a Date: Tue Sep 12 21:42:44 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/libxfs/init.c - 1.10 - allow us to build with an old linux/fs.h. also be gentler if BLKSETSIZE ioctl fails - warn, don't die - this isn't usually a disaster. From owner-linux-xfs@oss.sgi.com Wed Sep 13 06:52:36 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 06:52:17 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:9824 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 06:51:47 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA09263 for ; Wed, 13 Sep 2000 06:58:27 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id IAA29480; Wed, 13 Sep 2000 08:50:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id IAA90618; Wed, 13 Sep 2000 08:50:28 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA11702; Wed, 13 Sep 2000 08:48:21 -0500 Message-Id: <200009131348.IAA11702@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.3 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs as root fs In-Reply-To: Message from Thomas Graichen of "12 Sep 2000 21:03:32 GMT." Date: Wed, 13 Sep 2000 08:48:20 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > this is what i get for the failed mount retrys: > > Start mounting filesystem: ide0(3,5) > XFS: xlog_find_verify_log_record: need to back-up > XFS: failed to find log head > XFS: log mount/recovery failed > > XFS: log mount failed > > as said - it works perfectly again after an xfs_repair which does > not show any error > If you get a filesystem into this state, can you run xfs_logprint on it and send me the output. Just give logprint the block device name and no other argument, it should dump out the log contents in a fairly raw form. This problem was caused by the zeroing code missing a block of the log. I could not replicate the problem here, but it may be with your partition setup the fix was too simplistic. Steve From owner-linux-xfs@oss.sgi.com Wed Sep 13 09:01:30 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 09:01:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:7801 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 09:00:40 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA16806; Wed, 13 Sep 2000 08:52:59 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA00883; Wed, 13 Sep 2000 09:00:38 -0700 (PDT) Date: Wed, 13 Sep 2000 09:00:38 -0700 (PDT) Message-Id: <200009131600.JAA00883@info.engr.sgi.com> X-Pv-Incident: 800850 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: CLOSE 800850 - XFS + CONFIG_HIGHMEM4GB bug To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800850 *Status : closed Priority : 2 Assigned Engineer : lord Submitter : dxm Opened Date : 09/03/00 *Closed Date : 09/13/00 *Fixed By : lord *Fixed By Domain : sgi.com *Modified Date : 09/13/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : From: ananth ananthanarayanan (TAKE) Date: Sep 04 2000 06:20:03PM [pvnews version: 1.71] ---------------------------- Date: Mon Sep 4 18:13:03 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs ..... ========================== ADDITIONAL INFORMATION (CLOSE) From: lord@sgi.com (BugWorks) Date: Sep 13 2000 09:00:38AM ========================== I am closing this again - the last change I made appears to have made this a kiobuf specific problem now. There is a separate PV for this. From owner-linux-xfs@oss.sgi.com Wed Sep 13 11:26:50 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 11:26:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:55351 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 11:26:14 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA15825 for ; Wed, 13 Sep 2000 11:18:33 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA67499 for ; Wed, 13 Sep 2000 13:23:41 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id NAA10759 for ; Wed, 13 Sep 2000 13:23:40 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e8DINe211684 for linux-xfs@oss.sgi.com; Wed, 13 Sep 2000 13:23:40 -0500 Date: Wed, 13 Sep 2000 13:23:40 -0500 From: Russell Cattelan Message-Id: <200009131823.e8DINe211684@gibble.americas.sgi.com> Subject: TAKE - turn off concat_ok in cases of LVM device. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Sep 13 11:23:07 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74318a linux/fs/pagebuf/page_buf.c - 1.32 - Turn off buffer head concatination in the case of and LVM device. it appears lvm wasn't doing the right things in case of differing request sizes. This should be fixed in later version but for now this appears to allow striped devices to work correctly. From owner-linux-xfs@oss.sgi.com Wed Sep 13 11:56:20 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 11:56:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:44354 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 11:55:52 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA20884 for ; Wed, 13 Sep 2000 11:48:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA89804; Wed, 13 Sep 2000 13:53:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA45790; Wed, 13 Sep 2000 13:53:18 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA25193; Wed, 13 Sep 2000 13:51:09 -0500 Message-Id: <200009131851.NAA25193@jen.americas.sgi.com> Date: Wed, 13 Sep 2000 13:51:09 -0500 Subject: TAKE 800480 - fix endian bug in xfs tail pushing code To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing A dummy log sequence number gets built to determine if the log needs flushing to make room for a new transaction. This code was still endian sensitive since it used hard coded locations within the 64 bit LSN to store the cycle and block numbers. This meant that the comparison being done was basically meaningless and would lead to when tail pushing happened being somewhat variable. Date: Wed Sep 13 11:49:22 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74322a linux/fs/xfs/xfs_log.c - 1.221 - In calculating a threshold lsn for log flushing, do it in a byte order independent way. From owner-linux-xfs@oss.sgi.com Wed Sep 13 12:19:50 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 12:19:31 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:10827 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 12:19:15 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA25041; Wed, 13 Sep 2000 12:11:34 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id MAA22357; Wed, 13 Sep 2000 12:19:13 -0700 (PDT) Date: Wed, 13 Sep 2000 12:19:13 -0700 (PDT) Message-Id: <200009131919.MAA22357@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: CLOSE 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: tduffy@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 *Status : closed Priority : 2 Assigned Engineer : lord Submitter : ananth Opened Date : 08/29/00 *Closed Date : 09/13/00 *Fixed By : lord *Fixed By Domain : sgi.com *Modified Date : 09/13/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: lord@sgi.com (BugWorks) Date: Sep 13 2000 12:19:12PM ========================== Still not getting messages from ptools to bugworks... Fixed by this mod: A dummy log sequence number gets built to determine if the log needs flushing to make room for a new transaction. This code was still endian sensitive since it used hard coded locations within the 64 bit LSN to store the cycle and block numbers. This meant that the comparison being done was basically meaningless and would lead to when tail pushing happened being somewhat variable. Date: Wed Sep 13 11:49:22 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74322a linux/fs/xfs/xfs_log.c - 1.221 - In calculating a threshold lsn for log flushing, do it in a byte order independent way. From owner-linux-xfs@oss.sgi.com Wed Sep 13 12:27:22 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 12:27:12 -0700 Received: from hermes.mixx.net ([212.84.196.2]:46601 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 13 Sep 2000 12:26:50 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 5641EF80F for ; Wed, 13 Sep 2000 21:26:47 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id B6D7B2CA6D; Wed, 13 Sep 2000 21:26:46 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs as root fs Date: 13 Sep 2000 19:26:46 GMT Organization: innominate AG, Berlin, Germany Lines: 31 Distribution: local Message-ID: References: <39BD8649.D1FBDC9B@sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968873206 4302 10.0.0.69 (13 Sep 2000 19:26:46 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ken McDonell wrote: > Thomas, if you still have the source tree that was used to make this > kernel, can you please let me know which version of > cmd/xfs/repair/phase2.c you have? > The symptoms sound exactly like the problem Steve's take was aiming > to fix, namely > - repair (introduces error) > - mount > - umount > - mount (2nd mount sees error) > His fix was rev 1.30 of cmd/xfs/repair/phase2.c checked into the > internal RCS tree at 11:42am PDT on Fri 9/8 ... it would not have > appeared in the CVS tree until sometime later. it's 1.29 - so this should be the reason - somehow the update must have missed it ... will update again and come back if the error is still there (what i don't expect) thanks t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Sep 13 12:51:41 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 12:51:31 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:4438 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 12:51:08 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA00109 for ; Wed, 13 Sep 2000 12:43:26 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA01648 for ; Wed, 13 Sep 2000 14:49:49 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id OAA13820 for ; Wed, 13 Sep 2000 14:49:49 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e8DJnmB10193 for linux-xfs@oss.sgi.com; Wed, 13 Sep 2000 14:49:48 -0500 Date: Wed, 13 Sep 2000 14:49:48 -0500 From: Russell Cattelan Message-Id: <200009131949.e8DJnmB10193@gibble.americas.sgi.com> Subject: TAKE - fix typo To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Sep 13 12:49:13 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74328a linux/fs/pagebuf/page_buf.c - 1.33 - Fix typo from last checkin. From owner-linux-xfs@oss.sgi.com Wed Sep 13 14:16:42 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 14:16:32 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58743 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 14:16:12 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA16663; Wed, 13 Sep 2000 14:08:30 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA26476; Wed, 13 Sep 2000 14:15:40 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA89639; Wed, 13 Sep 2000 14:14:24 -0700 (PDT) Date: Wed, 13 Sep 2000 14:14:24 -0700 (PDT) Message-Id: <200009132114.OAA89639@info.engr.sgi.com> X-Pv-Incident: 797419 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: REOPEN 797419 - xfs_iget goes recursive and dies a horrible death To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797419 *Status : open Priority : 1 Assigned Engineer : lord Submitter : lord Project : xfs-linux Assigned Group : xfs-linux Opened Date : 07/27/00 *Closed Date : *Fixed By : *Fixed By Domain : *Verified Date : *Modified User : cattelan *Modified User Domain : engr *Description : xfs_iget has some conditions where it can end up recalling itself, this is allowed for, but there are cases in there where two threads are looking up the same inode which it does not cope with, the end result is usually this: xfs_iget_core: ambiguous vns: vp/0xc3012b00, invp/0xc22c1800 Unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: c889c115 *pde = 00000000 ..... ========================== ADDITIONAL INFORMATION (REOPEN) From: cattelan@engr (BugWorks) Date: Sep 13 2000 02:14:23PM ========================== This mod now causes nfsd to panic the system when a inode is reopened via and nfs call. NMI Watchdog detected LOCKUP on CPU0, registers: CPU: 0 EIP: 0010:[] EFLAGS: 00000086 eax: 00000287 ebx: c62be000 ecx: c59173d8 edx: c59172cc esi: c0f9f760 edi: c664a880 ebp: c66f1db0 esp: c66f1d70 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 626, stackpage=c66f1000) Stack: c62be000 c0f9f760 00000001 c6f96700 fffffff3 c664a884 c6cc7980 c758f810 00000002 00000000 c59172cc 000005c8 016f1db4 00000040 00000000 00000006 c66f1de4 c8871c12 c0f9f760 c62be000 00000000 00400044 00000000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f3 90 7e f8 e9 7a 69 fd ff 80 7e 18 00 f3 90 7e f8 e9 90 69 Entering kdb (current=0xc66f0000, pid 626) on processor 0 due to WatchDog Interr upt @ 0xc889af80 eax = 0x00000287 ebx = 0xc62be000 ecx = 0xc59173d8 edx = 0xc59172cc esi = 0xc0f9f760 edi = 0xc664a880 esp = 0xc66f1d70 eip = 0xc889af80 ebp = 0xc66f1db0 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000086 ds = 0xc0f90018 es = 0xc66f0018 origeax = 0x00000287 ®s = 0xc66f1d3c [0]kdb> bt EBP EIP Function(args) 0xc889af80 [xfs].text.lock+0xdb xfs .text.lock 0xc889aea5 0xc889aea5 0xc889b5f2 0xc66f1db0 0xc8871903 [xfs]xfs_iget_core+0x3fb (0xc0f9f760, 0xc62be000, 0x0, 0x4 00044, 0x0) xfs .text 0xc8842060 0xc8871508 0xc8871bac 0xc66f1de4 0xc8871c12 [xfs]xfs_vn_iget+0x2e (0xc0f9f760, 0xc62be000, 0x0, 0x4000 44, 0x0) xfs .text 0xc8842060 0xc8871be4 0xc8871c1c 0xc66f1e28 0xc889a9fa [xfs]vn_initialize+0xc6 (0xc7daaa60, 0xc0f9f680, 0x1) xfs .text 0xc8842060 0xc889a934 0xc889aa6c 0xc66f1e40 0xc8899c1c [xfs]linvfs_read_inode+0x20 (0xc0f9f680, 0xc0f9f680) xfs .text 0xc8842060 0xc8899bfc 0xc8899c44 0xc66f1e5c 0xc014587a get_new_inode+0xca (0xc62bfc00, 0x400044, 0xc12f9b78, 0x0, 0x0) kernel .text 0xc0100000 0xc01457b0 0xc014590c 0xc66f1e88 0xc0145be1 iget4+0xdd (0xc62bfc00, 0x400044, 0x0, 0x0) kernel .text 0xc0100000 0xc0145b04 0xc0145bec 0xc66f1ea8 0xc88eecdd [nfsd]nfsd_iget+0x19 (0xc62bfc00, 0x400044, 0x2) nfsd .text 0xc88ed060 0xc88eecc4 0xc88eedb4 0xc66f1edc 0xc88ef15c [nfsd]find_fh_dentry+0x20 (0xc62bfc00, 0x400044, 0x2, 0x40 0080, 0x1) nfsd .text 0xc88ed060 0xc88ef13c 0xc88ef458 0xc66f1f10 0xc88ef6d9 [nfsd]fh_verify+0x281 (0xc62ae200, 0xc66b1e00, 0x0, 0x0) nfsd .text 0xc88ed060 0xc88ef458 0xc88ef8ec 0xc66f1f34 0xc88edbf1 [nfsd]nfsd_proc_getattr+0x91 (0xc62ae200, 0xc62ae000, 0xc6 6b1e00) nfsd .text 0xc88ed060 0xc88edb60 0xc88edbfc From owner-linux-xfs@oss.sgi.com Wed Sep 13 14:56:01 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 14:55:41 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2344 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 14:55:17 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA04226; Wed, 13 Sep 2000 15:01:56 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA12140; Wed, 13 Sep 2000 14:54:45 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA85612; Wed, 13 Sep 2000 14:52:09 -0700 (PDT) Date: Wed, 13 Sep 2000 14:52:09 -0700 (PDT) Message-Id: <200009132152.OAA85612@feature.engr.sgi.com> X-Pv-Incident: 800480 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (lord@sgi.com) Subject: TAKE 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: tduffy@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : ananth *Status : closed Assigned Engineer : lord *Fixed By : lord *Fixed By Domain : sgi.com *Closed Date : 09/13/00 Priority : 2 *Modified Date : 09/13/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: lord@sgi.com (BugWorks) Date: Sep 13 2000 12:19:12PM ========================== Still not getting messages from ptools to bugworks... Fixed by this mod: ..... ========================== ADDITIONAL INFORMATION (TAKE) From: steve lord Date: Sep 13 2000 02:52:09PM [pvnews version: 1.71] ========================== A dummy log sequence number gets built to determine if the log needs flushing to make room for a new transaction. This code was still endian sensitive since it used hard coded locations within the 64 bit LSN to store the cycle and block numbers. This meant that the comparison being done was basically meaningless and would lead to when tail pushing happened being somewhat variable. Date: Wed Sep 13 11:49:22 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74322a linux/fs/xfs/xfs_log.c - 1.221 - In calculating a threshold lsn for log flushing, do it in a byte order independent way. Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 12 2000 12:46:58PM ========================== This appears to be caused by something failing to sync the root inode of the filesystem. There is one item in the AIL (in log, but modified in memory still). This is an inode: xnode 0xf730cc88 hash 0xf70d9800 next 0x00000000 prevp 0xf2595688 mount 0xf43ae400 mnext 0xd0bcfc88 mprev 0xf730ca7c vnode 0xf735a160 dev 811 ino 128[0:8:0] blkno 0x40 len 0x10 boffset 0x0 transp 0x00000000 &itemp 0xf3007de8 &lock 0xf730cd14 lock_ra 0x00000000 &iolock 0xf730cd3c udquotp 0x00000000 pdquotp 0x00000000 &flock 0xf730cd64 (1) &pinlock 0xf730cd8c pincount 0x0 &pinsema 0xf730cd7c &rlock 0xf730cda8 next_offset 0 io_offset 0 reada_blkno 0[0:0] io_size 0x0 last_req_sz 0x0 new_size 0 write off 0 gap list 0x00000000 readiolog 16, readioblocks 16, writeiolog 16, writeioblocks 16, maxiolog 16 flags 0x0 <> update_core 0x0 update size 0x0 gen 0x0 qbufs 0 delayed blks 0 chash 0xf44cfb10 cnext 0xca46a8d0 cprev 0xe7e13990 data fork bytes 0x2d real_bytes 0x30 lastex 0x0 u1:data 0xf7715920 broot 0x00000000 broot_bytes 0x0 ext_max 9 flags 0x1 u2 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 attr fork empty magic 0x494e mode 040777 (d---rwxrwxrwx) version 0x1 format 0x1 (local) nlink 0x5 uid 0x0 gid 0x0 projid 0x0 atime 0x39be151e:2de54480 mtime 0x39a6c3d3:2fc03e40 ctime 0x39a6c3d3:2fc03e40 size 0x2d nblocks 0 extsize 0x0 nextents 0x0 anextents 0x0 forkoff 0 aformat 0x2 (extents) dmevmask 0x0 dmstate 0x0 flags 0x0 <> gen 0x0 I will dig some more, but in the meantime, the machine is dead again - the xfs kdb commands are way too dangerous in the way we can crash the debugger. From owner-linux-xfs@oss.sgi.com Wed Sep 13 15:06:02 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 15:05:42 -0700 Received: from hermes.mixx.net ([212.84.196.2]:22285 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 13 Sep 2000 15:05:22 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id F0000F81E for ; Thu, 14 Sep 2000 00:05:16 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id D18622CA6D; Thu, 14 Sep 2000 00:05:16 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs as root fs Date: 13 Sep 2000 22:05:16 GMT Organization: innominate AG, Berlin, Germany Lines: 34 Distribution: local Message-ID: References: <39BD8649.D1FBDC9B@sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968882716 19980 10.0.0.69 (13 Sep 2000 22:05:16 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > Ken McDonell wrote: >> Thomas, if you still have the source tree that was used to make this >> kernel, can you please let me know which version of >> cmd/xfs/repair/phase2.c you have? >> The symptoms sound exactly like the problem Steve's take was aiming >> to fix, namely >> - repair (introduces error) >> - mount >> - umount >> - mount (2nd mount sees error) >> His fix was rev 1.30 of cmd/xfs/repair/phase2.c checked into the >> internal RCS tree at 11:42am PDT on Fri 9/8 ... it would not have >> appeared in the CVS tree until sometime later. > it's 1.29 - so this should be the reason - somehow the update must > have missed it ... will update again and come back if the error > is still there (what i don't expect) ok - that it was - error is gone now after an update ... also: steve since the two times sync i did not see the xfs_repair problems with xfs as a root fs anymore ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Sep 13 17:59:24 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 17:59:05 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:19094 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 17:58:55 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id TAA08186; Wed, 13 Sep 2000 19:58:51 -0500 (CDT) Date: Wed, 13 Sep 2000 19:58:51 -0500 (CDT) Message-Id: <200009140058.TAA08186@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com cc: jones@spica.cc.utexas.edu Subject: Can any one explain this behavior? Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing If you create and mount a xfs file system then untar a few files and directories in to it then run xfs_check you get errors. If you do a sync and then run xfs_check on the file system you still get errors. If you umount and mount the file system then the errors go away. I think this is has to do with the way the log transactions are handled and that their is no problem. But I would like to know for sure! Bill Jones From owner-linux-xfs@oss.sgi.com Wed Sep 13 18:05:55 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 18:05:34 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58422 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 18:05:19 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA16144 for ; Wed, 13 Sep 2000 17:57:37 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA11443; Thu, 14 Sep 2000 12:04:00 +1100 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id MAA26966; Thu, 14 Sep 2000 12:03:59 +1100 (EST) Message-Id: <200009140103.MAA26966@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: William L Jones cc: linux-xfs@oss.sgi.com Subject: Re: Can any one explain this behavior? In-reply-to: Your message of "Wed, 13 Sep 2000 19:58:51 CDT." <200009140058.TAA08186@spica.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Sep 2000 12:03:59 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing William L Jones writes: => => => If you create and mount a xfs file system then untar a few files and direct => ories in to it => then run xfs_check you get errors. If you do a sync and then run xfs_chec => k on the => file system you still get errors. If you umount and mount the file system t => hen => the errors go away. => => I think this is has to do with the way the log transactions are handled and => that their is => no problem. => => But I would like to know for sure! This is definitely a FAQ. xfs_check and xfs_repair should only be run on unmounted filesystems. Otherwise they will most likely report FS corruption as the FS is seldom completely consistent whilst mounted. There's good odds that a just mounted FS is consistent. Actually I was thinking it would be a good idea to make xfs_check and xfs_repair fail or at least warn before checking a mounted FS... ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Sep 13 18:10:04 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 18:09:55 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42294 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 18:09:42 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA06884 for ; Wed, 13 Sep 2000 18:16:21 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id UAA44719; Wed, 13 Sep 2000 20:08:06 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id UAA65220; Wed, 13 Sep 2000 20:08:06 -0500 (CDT) From: Steve Lord Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id UAA22210; Wed, 13 Sep 2000 20:05:53 -0500 Message-Id: <200009140105.UAA22210@jen.americas.sgi.com> To: William L Jones cc: linux-xfs@oss.sgi.com, jones@spica.cc.utexas.edu Subject: Re: Can any one explain this behavior? In-reply-to: Your message of "Wed, 13 Sep 2000 19:58:51 CDT Date: Wed, 13 Sep 2000 20:05:53 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > If you create and mount a xfs file system then untar a few files and director ies in to it > then run xfs_check you get errors. If you do a sync and then run xfs_check on the > file system you still get errors. If you umount and mount the file system the n > the errors go away. > > I think this is has to do with the way the log transactions are handled and t hat their is > no problem. > > But I would like to know for sure! > > > Bill Jones Running check on a mounted filesystem will not always get you a good picture of the world. One issue is that the data buffered in memory by XFS will not be visible via the block device interface - the buffering is in different places. Also, I think the XFS user space makes the correct calls to flush data out of the block device driver down to disk, but xfs_check is almost certainly not doing that since it is a read-only operation. Chances are if you run it twice it could pick up old data cached by a previous run. Steve From owner-linux-xfs@oss.sgi.com Wed Sep 13 18:12:04 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 18:11:54 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47158 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 18:11:35 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA01576 for ; Wed, 13 Sep 2000 18:18:14 -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 MAA13676 for linux-xfs@oss.sgi.com; Thu, 14 Sep 2000 12:10:15 +1100 (EST) Date: Thu, 14 Sep 2000 12:10:15 +1100 (EST) From: Nathan Scott Message-Id: <200009140110.MAA13676@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_zero_eof Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Cherrypick this change from my SIM-less workarea - might help with a real problem. Found this after cleaning up the headers a whole lot... cheers. Modid: 2.4.0-test1-xfs:slinx:74352a Date: Wed Sep 13 18:07:30 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/xfs_inode.c - 1.302 linux/fs/xfs/xfs_rw.c - 1.326 - pass the right number of arguments into xfs_zero_eof(). linux/fs/xfs/xfs_rw.h - 1.55 - match the xfs_zero_eof declaration up with the current source. From owner-linux-xfs@oss.sgi.com Wed Sep 13 18:19:44 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 18:19:24 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7479 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 18:19:15 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA06513 for ; Wed, 13 Sep 2000 18:25:54 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA11586; Thu, 14 Sep 2000 12:17:52 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Daniel Moore cc: William L Jones , linux-xfs@oss.sgi.com Subject: Re: Can any one explain this behavior? In-reply-to: Your message of "Thu, 14 Sep 2000 12:03:59 +1100." <200009140103.MAA26966@clouds.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Sep 2000 12:17:52 +1100 Message-ID: <3339.968894272@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 14 Sep 2000 12:03:59 +1100, Daniel Moore wrote: >Actually I was thinking it would be a good idea to make xfs_check and >xfs_repair fail or at least warn before checking a mounted FS... # e2fsck /dev/hda3 e2fsck 1.15, 18-Jul-1999 for EXT2 FS 0.5b, 95/08/09 /dev/hda3 is mounted. WARNING!!! Running e2fsck on a mounted filesystem may cause SEVERE filesystem damage. Do you really want to continue (y/n)? From owner-linux-xfs@oss.sgi.com Wed Sep 13 18:25:05 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 18:24:54 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:45975 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 18:24:35 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id UAA08447; Wed, 13 Sep 2000 20:24:32 -0500 (CDT) Date: Wed, 13 Sep 2000 20:24:32 -0500 (CDT) Message-Id: <200009140124.UAA08447@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com cc: jones@spica.cc.utexas.edu Subject: Should open_by_inode have a special dentry ops? Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Shouldn't open_by_inode have a dentry_operations table like the one found in xfs_iops.c? I think it should. This may be the source of the reference leak that was noticed after using xfxdump. If it does, doesn't that indicate that their may be problems exporting a xfs file system in linux. NFS also creates its own dentries from inodes gained by iget? Bill Jones From owner-linux-xfs@oss.sgi.com Wed Sep 13 19:08:15 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 19:08:05 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:10305 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 19:07:42 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA21251; Wed, 13 Sep 2000 19:00:01 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA14264; Wed, 13 Sep 2000 19:07:10 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA48763; Wed, 13 Sep 2000 19:05:48 -0700 (PDT) Date: Wed, 13 Sep 2000 19:05:48 -0700 (PDT) Message-Id: <200009140205.TAA48763@info.engr.sgi.com> X-Pv-Incident: 801763 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 801763 - freed kmem modified on log mount failure To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com, ptg@melbourne.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801763 Submitter : dxm Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : ptg Category : software Customer Reported : F Priority : 2 Project : xfs Status : open Description : On log mount failure, xfs_log_mount follows this code path: xfs_log_mount xlog_alloc_log xlog_recover (fails) xlog_unalloc_log set bit in log->l_flags where the bit is set in the log structure which has just been freed. This bug could potentially corrupt data, but is presumably infrequently excercised, hence the priority. This bug is also present in linux-xfs. From owner-linux-xfs@oss.sgi.com Wed Sep 13 19:13:55 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 19:13:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:7746 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 19:13:33 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA21748; Wed, 13 Sep 2000 19:05:52 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA59236; Wed, 13 Sep 2000 19:13:28 -0700 (PDT) Date: Wed, 13 Sep 2000 19:13:28 -0700 (PDT) Message-Id: <200009140213.TAA59236@info.engr.sgi.com> X-Pv-Incident: 801764 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 801764 - xfs_check and xfs_repair should fail if device mounted To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801764 Submitter : dxm Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 4 Project : xfs-linux Status : open Description : both "xfs_check" and "xfs_repair -n" may be run on a mounted filesystem and will usually produce lots of warnings about filesystem corruption due to the inconsistent state the FS is in. Both tools should fail or at least warn that the FS is mounted before proceeding. xfs_logprint should also warn when run on a mounted FS, but can still be useful when mounted. From owner-linux-xfs@oss.sgi.com Wed Sep 13 19:20:55 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 19:20:45 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:46906 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 19:20:26 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA07034; Wed, 13 Sep 2000 19:27:06 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA89148; Wed, 13 Sep 2000 19:20:21 -0700 (PDT) Date: Wed, 13 Sep 2000 19:20:21 -0700 (PDT) Message-Id: <200009140220.TAA89148@info.engr.sgi.com> X-Pv-Incident: 801763 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 801763 - freed kmem modified on log mount failure To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com, ptg@melbourne.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801763 Status : open Priority : 2 Assigned Engineer : dxm Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : On log mount failure, xfs_log_mount follows this code path: xfs_log_mount xlog_alloc_log xlog_recover (fails) xlog_unalloc_log set bit in log->l_flags where the bit is set in the log structure which has ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 13 2000 07:20:20PM ========================== Fixed in linux-xfs: Modid: 2.4.0-test1-xfs:slinx:74363a Date: Wed Sep 13 19:19:39 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-tot Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/xfs_log.c - 1.222 - pv 801763 don't modify freed memory on mount fail From owner-linux-xfs@oss.sgi.com Wed Sep 13 19:21:15 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 19:20:55 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:10819 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 19:20:39 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA22345 for ; Wed, 13 Sep 2000 19:12:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id VAA67266 for ; Wed, 13 Sep 2000 21:18:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id VAA94027 for ; Wed, 13 Sep 2000 21:18:06 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id VAA23768; Wed, 13 Sep 2000 21:15:53 -0500 Message-Id: <200009140215.VAA23768@jen.americas.sgi.com> Date: Wed, 13 Sep 2000 21:15:53 -0500 Subject: TAKE 797419 - another iget fix To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Once more with feeling.... messing with the vnode flag in here was deadlocking with the nfs call down from iget. We double trip on the lock in the vnode. Date: Wed Sep 13 19:15:33 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74362a linux/fs/xfs/xfs_iget.c - 1.128 - remove VN_FLAGSET and VN_FLAGCLR calls from xfs_iget, the state is not used on Linux, and it can cause a deadlock when called via read_inode. From owner-linux-xfs@oss.sgi.com Wed Sep 13 19:47:15 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 19:46:55 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:11080 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 19:46:28 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA25453; Wed, 13 Sep 2000 19:38:46 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA19004; Wed, 13 Sep 2000 19:45:56 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA99580; Wed, 13 Sep 2000 19:44:38 -0700 (PDT) Date: Wed, 13 Sep 2000 19:44:38 -0700 (PDT) Message-Id: <200009140244.TAA99580@info.engr.sgi.com> X-Pv-Incident: 800992 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: REOPEN 800992 - pagebuf_init call to kmem_cache_create BUG() To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800992 *Status : open Priority : 4 Assigned Engineer : dxm Submitter : dxm Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/05/00 *Closed Date : *Fixed By : *Fixed By Domain : *Verified Date : *Modified User : dxm *Modified User Domain : engr *Description : On my test box, I'd been playing with xfs, then umounted, rmmoded and insmoded the modules. When pagebuf was insmoded, this kernel BUG() was tripped. I'll see if I can get some more info on this one. kmem_cache_destroy: Can't free all objects c116d764 kernel BUG at slab.c:806! Entering kdb (0xc215e000) Panic: invalid operand ..... ========================== ADDITIONAL INFORMATION (REOPEN) From: dxm@engr (BugWorks) Date: Sep 13 2000 07:44:37PM ========================== With XFS (and pagebuf) as modules, and after a failed mount, warning messages are generated on module unload and a kernel BUG() is triggered on reload of the module. This is repeatable - I just couldn't rember how I did it earlier. kmem_cache_destroy: Can't free all objects c116dcdc kmem_cache_destroy: Can't free all objects c116dd40 kernel BUG at slab.c:806! Entering kdb (current=0xc2012000, pid 1002) Panic: invalid operand due to panic @ 0xc0125e0e eax = 0x0000001a ebx = 0xc116dd38 ecx = 0xc02a2eec edx = 0xc11c7260 esi = 0xc116dd33 edi = 0xc48a0921 esp = 0xc2013e60 eip = 0xc0125e0e ebp = 0xc2013ea0 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xc2013e2c kdb> From owner-linux-xfs@oss.sgi.com Wed Sep 13 19:51:15 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 19:50:55 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:62536 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 19:50:43 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA25966; Wed, 13 Sep 2000 19:43:02 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA12529; Wed, 13 Sep 2000 19:50:40 -0700 (PDT) Date: Wed, 13 Sep 2000 19:50:40 -0700 (PDT) Message-Id: <200009140250.TAA12529@info.engr.sgi.com> X-Pv-Incident: 800992 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: REPRIORITIZE 800992 - pagebuf_init call to kmem_cache_create BUG() To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800992 Status : open *Priority : 2 Assigned Engineer : dxm Submitter : dxm Opened Date : 09/05/00 *Modified User : dxm *Modified User Domain : engr *Description : On my test box, I'd been playing with xfs, then umounted, rmmoded and insmoded the modules. When pagebuf was insmoded, this kernel BUG() was tripped. I'll see if I can get some more info on this one. kmem_cache_destroy: Can't free all objects c116d764 kernel BUG at slab.c:806! Entering kdb (0xc215e000) Panic: invalid operand ..... ========================== ADDITIONAL INFORMATION (REPRIORITIZE) From: dxm@engr (BugWorks) Date: Sep 13 2000 07:50:40PM ========================== Easily triggered and causes a panic. PS. This bug is assigned to me, but if someone else wants it/or can shed some light on it, that'd be just peachy. From owner-linux-xfs@oss.sgi.com Wed Sep 13 19:53:45 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 19:53:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:23369 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 19:53:20 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA26232 for ; Wed, 13 Sep 2000 19:45:39 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id VAA76089 for ; Wed, 13 Sep 2000 21:50:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id VAA27747 for ; Wed, 13 Sep 2000 21:50:47 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id VAA23868; Wed, 13 Sep 2000 21:48:34 -0500 Message-Id: <200009140248.VAA23868@jen.americas.sgi.com> Date: Wed, 13 Sep 2000 21:48:34 -0500 Subject: TAKE 795642 - fix for remount readonly To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The remount readonly code path needs to go through sync twice. Unlinked inodes have two phases of work to go through before they are clean on disk. These are both handled via sync, and will not be handled in the same pass. Date: Wed Sep 13 19:48:37 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74367a linux/fs/xfs/linux/xfs_super.c - 1.87 - Call sync twice in the remount readonly case to deal with removed inodes correctly. From owner-linux-xfs@oss.sgi.com Wed Sep 13 19:55:15 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 19:54:56 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:39497 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 19:54:45 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA26353; Wed, 13 Sep 2000 19:47:04 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA89363; Wed, 13 Sep 2000 19:54:43 -0700 (PDT) Date: Wed, 13 Sep 2000 19:54:43 -0700 (PDT) Message-Id: <200009140254.TAA89363@info.engr.sgi.com> X-Pv-Incident: 800992 webPV: 192.82.201.52 webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800992 - pagebuf_init call to kmem_cache_create BUG() To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800992 Status : open Priority : 2 Assigned Engineer : dxm Submitter : dxm *Modified User : lord *Modified User Domain : sgi.com *Description : On my test box, I'd been playing with xfs, then umounted, rmmoded and insmoded the modules. When pagebuf was insmoded, this kernel BUG() was tripped. I'll see if I can get some more info on this one. kmem_cache_destroy: Can't free all objects c116d764 kernel BUG at slab.c:806! Entering kdb (0xc215e000) Panic: invalid operand ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 13 2000 07:54:43PM ========================== > PS. This bug is assigned to me, but if someone else wants > it/or can shed some light on it, that'd be just peachy. See my previous add for a way to track this down to specific pagebufs, although it looks like we are leaking something in a failed mount case which narrows it down somewhat. If it is this simple to hit then renabling pagebuf tracing as well as the previous suggestion will probably even tell you where the buffers were allocated. From owner-linux-xfs@oss.sgi.com Wed Sep 13 19:55:35 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 19:55:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29501 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 19:55:00 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA06511 for ; Wed, 13 Sep 2000 20:01:39 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA66152 for linux-xfs@oss.sgi.com; Thu, 14 Sep 2000 13:52:25 +1100 (EST) Date: Thu, 14 Sep 2000 13:52:25 +1100 (EST) From: Daniel Moore Message-Id: <200009140252.NAA66152@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - move sb_blocksize check Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:74368a Date: Wed Sep 13 19:52:04 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-tot Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/xfs_mount.c - 1.238 - sb_blocksize check should be after we know this is actually an XFS FS remove supurfluous \ns in errors From owner-linux-xfs@oss.sgi.com Wed Sep 13 20:41:36 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 20:41:16 -0700 Received: from hermes.mixx.net ([212.84.196.2]:4115 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 13 Sep 2000 20:40:51 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 21D08F81D for ; Thu, 14 Sep 2000 05:40:50 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 65B1C2CA6D; Thu, 14 Sep 2000 05:40:49 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs/ppc status Date: 14 Sep 2000 03:40:49 GMT Organization: innominate AG, Berlin, Germany Lines: 11 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968902849 17255 10.0.0.69 (14 Sep 2000 03:40:49 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing just set up my ppc machine freshly and tried the current state of XFS on ppc and it looks so far quite promising (but i did not test it too much ... will do harder soon) ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Sep 13 20:44:36 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 20:44:15 -0700 Received: from hermes.mixx.net ([212.84.196.2]:7955 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 13 Sep 2000 20:44:09 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 56E2CF81D for ; Thu, 14 Sep 2000 05:44:07 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 119212CA6D; Thu, 14 Sep 2000 05:44:07 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs_repair at full disk Date: 14 Sep 2000 03:44:07 GMT Organization: innominate AG, Berlin, Germany Lines: 16 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968903047 17255 10.0.0.69 (14 Sep 2000 03:44:07 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing while testing xfs on the ppc i ran into the following problem with xfs_repair (which works fine btw. on ppc now - and this problem also looks more generic - i don't think this is a ppc issue) ... ok i ran xfs_repair on a _full_ (unmounted :-) filesystem and in phase 6 it ended with a fatal error at "ensuring existence of lost+found dir" with "ran out of disk space!" ... i had no time to verify this on i386 yet - maybe someone might try this out ... i think this should not happen ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Sep 13 21:02:07 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 21:01:47 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:50257 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 21:01:18 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA00904 for ; Wed, 13 Sep 2000 20:53:36 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12860; Thu, 14 Sep 2000 14:58:44 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA18230; Thu, 14 Sep 2000 14:58:41 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009141458.ZM18218@wobbly.melbourne.sgi.com> Date: Thu, 14 Sep 2000 14:58:39 -0400 In-Reply-To: Thomas Graichen "xfs_repair at full disk" (Sep 14, 3:44am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: xfs_repair at full disk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi there Thomas, On Sep 14, 3:44am, Thomas Graichen wrote: > Subject: xfs_repair at full disk > while testing xfs on the ppc i ran into the following problem with > xfs_repair (which works fine btw. on ppc now - and this problem also That's good to hear. > looks more generic - i don't think this is a ppc issue) ... ok i ran > xfs_repair on a _full_ (unmounted :-) filesystem and in phase 6 it > ended with a fatal error at "ensuring existence of lost+found dir" > with "ran out of disk space!" ... i had no time to verify this on > i386 yet - maybe someone might try this out ... i think this should > not happen ... > >From a quick look at the code, right after it prints that message, repair calls into "mk_orphanage" which creates a new transaction (for the lost+found subdir) - first calling libxfs_trans_reserve to check whether there's enough space available to do that ... I would guess you're seeing a failure there (can you confirm with gdb/ltrace?). If so, I think this is expected behavior ... we can't create a new directory without enough space to do so. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Sep 13 22:21:27 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 22:21:07 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:65091 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 22:20:53 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA02085 for ; Wed, 13 Sep 2000 22:27: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 QAA55111 for linux-xfs@oss.sgi.com; Thu, 14 Sep 2000 16:18:59 +1100 (EST) Date: Thu, 14 Sep 2000 16:18:59 +1100 (EST) From: Nathan Scott Message-Id: <200009140518.QAA55111@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Remove a bunch of dead code in the quota stuff. Needed to do this as part of the sim cleanup (cscope giving false matches on routines which really no longer exist). I've checked it in now cos, for the most part, its not part of the compiled kernel source so is very low/zero impact. cheers. Modid: 2.4.0-test1-xfs:slinx:74371a Date: Wed Sep 13 22:14:56 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/Makefile - 1.107 - add a comment re quotas. linux/fs/xfs/linux/xfs_globals.c - 1.16 - add ndquot, needed to get quotas compiled. linux/fs/xfs/xfs_dquot.c - 1.50 linux/fs/xfs/xfs_dquot_item.c - 1.19 linux/fs/xfs/xfs_qm.c - 1.53 linux/fs/xfs/xfs_qm.h - 1.15 linux/fs/xfs/xfs_qm_syscalls.c - 1.40 linux/fs/xfs/xfs_trans_dquot.c - 1.26 - update the source, get it compilable - remove references to routines like bflush, atomicAddUint, etc which no longer exist. linux/fs/xfs/xfs_quota_priv.h - 1.12 - fix typo in a macro. linux/fs/xfs/xfs_vfsops.c - 1.288 - put back reference to qm mutex which really is needed, add ndquot, remove bogus extern. linux/fs/xfs/xfsidbg.c - 1.151 - one liner for changes to quota stuff. linux/fs/xfs/xfsquotasstubs.c - 1.10 - put back reference to qm mutex which really is needed. From owner-linux-xfs@oss.sgi.com Thu Sep 14 07:03:38 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 07:03:19 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:23089 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 07:03:16 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA13735; Thu, 14 Sep 2000 06:55:35 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA92449; Thu, 14 Sep 2000 07:02:45 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA08559; Thu, 14 Sep 2000 07:00:06 -0700 (PDT) Date: Thu, 14 Sep 2000 07:00:06 -0700 (PDT) Message-Id: <200009141400.HAA08559@feature.engr.sgi.com> X-Pv-Incident: 797419 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (lord@sgi.com) Subject: TAKE 797419 - xfs_iget goes recursive and dies a horrible death To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord *Status : closed Assigned Engineer : lord *Fixed By : lord *Fixed By Domain : sgi.com *Closed Date : 09/14/00 Priority : 1 *Modified Date : 09/14/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: lord@sgi.com (BugWorks) Date: Sep 11 2000 01:02:19PM ========================== Messed up the send line in the take message. Checked in fix 2.4.0-test1-xfs:slinx:74156a Basic change is to introduce ihold which is iget without the ..... ========================== ADDITIONAL INFORMATION (TAKE) From: steve lord Date: Sep 14 2000 07:00:06AM [pvnews version: 1.71] ========================== Once more with feeling.... messing with the vnode flag in here was deadlocking with the nfs call down from iget. We double trip on the lock in the vnode. Date: Wed Sep 13 19:15:33 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74362a linux/fs/xfs/xfs_iget.c - 1.128 - remove VN_FLAGSET and VN_FLAGCLR calls from xfs_iget, the state is not used on Linux, and it can cause a deadlock when called via read_i node. Description : xfs_iget has some conditions where it can end up recalling itself, this is allowed for, but there are cases in there where two threads are looking up the same inode which it does not cope with, the end result is usually this: xfs_iget_core: ambiguous vns: vp/0xc3012b00, invp/0xc22c1800 Unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: c889c115 *pde = 00000000 ..... ========================== ADDITIONAL INFORMATION (REOPEN) From: cattelan@engr (BugWorks) Date: Sep 13 2000 02:14:23PM ========================== This mod now causes nfsd to panic the system when a inode is reopened via and nfs call. NMI Watchdog detected LOCKUP on CPU0, registers: CPU: 0 EIP: 0010:[] EFLAGS: 00000086 eax: 00000287 ebx: c62be000 ecx: c59173d8 edx: c59172cc esi: c0f9f760 edi: c664a880 ebp: c66f1db0 esp: c66f1d70 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 626, stackpage=c66f1000) Stack: c62be000 c0f9f760 00000001 c6f96700 fffffff3 c664a884 c6cc7980 c758f810 00000002 00000000 c59172cc 000005c8 016f1db4 00000040 00000000 00000006 c66f1de4 c8871c12 c0f9f760 c62be000 00000000 00400044 00000000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f3 90 7e f8 e9 7a 69 fd ff 80 7e 18 00 f3 90 7e f8 e9 90 69 Entering kdb (current=0xc66f0000, pid 626) on processor 0 due to WatchDog Interr upt @ 0xc889af80 eax = 0x00000287 ebx = 0xc62be000 ecx = 0xc59173d8 edx = 0xc59172cc esi = 0xc0f9f760 edi = 0xc664a880 esp = 0xc66f1d70 eip = 0xc889af80 ebp = 0xc66f1db0 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000086 ds = 0xc0f90018 es = 0xc66f0018 origeax = 0x00000287 ®s = 0xc66f1d3c [0]kdb> bt EBP EIP Function(args) 0xc889af80 [xfs].text.lock+0xdb xfs .text.lock 0xc889aea5 0xc889aea5 0xc889b5f2 0xc66f1db0 0xc8871903 [xfs]xfs_iget_core+0x3fb (0xc0f9f760, 0xc62be000, 0x0, 0x4 00044, 0x0) xfs .text 0xc8842060 0xc8871508 0xc8871bac 0xc66f1de4 0xc8871c12 [xfs]xfs_vn_iget+0x2e (0xc0f9f760, 0xc62be000, 0x0, 0x4000 44, 0x0) xfs .text 0xc8842060 0xc8871be4 0xc8871c1c 0xc66f1e28 0xc889a9fa [xfs]vn_initialize+0xc6 (0xc7daaa60, 0xc0f9f680, 0x1) xfs .text 0xc8842060 0xc889a934 0xc889aa6c 0xc66f1e40 0xc8899c1c [xfs]linvfs_read_inode+0x20 (0xc0f9f680, 0xc0f9f680) xfs .text 0xc8842060 0xc8899bfc 0xc8899c44 0xc66f1e5c 0xc014587a get_new_inode+0xca (0xc62bfc00, 0x400044, 0xc12f9b78, 0x0, 0x0) kernel .text 0xc0100000 0xc01457b0 0xc014590c 0xc66f1e88 0xc0145be1 iget4+0xdd (0xc62bfc00, 0x400044, 0x0, 0x0) kernel .text 0xc0100000 0xc0145b04 0xc0145bec 0xc66f1ea8 0xc88eecdd [nfsd]nfsd_iget+0x19 (0xc62bfc00, 0x400044, 0x2) nfsd .text 0xc88ed060 0xc88eecc4 0xc88eedb4 0xc66f1edc 0xc88ef15c [nfsd]find_fh_dentry+0x20 (0xc62bfc00, 0x400044, 0x2, 0x40 0080, 0x1) nfsd .text 0xc88ed060 0xc88ef13c 0xc88ef458 0xc66f1f10 0xc88ef6d9 [nfsd]fh_verify+0x281 (0xc62ae200, 0xc66b1e00, 0x0, 0x0) nfsd .text 0xc88ed060 0xc88ef458 0xc88ef8ec 0xc66f1f34 0xc88edbf1 [nfsd]nfsd_proc_getattr+0x91 (0xc62ae200, 0xc62ae000, 0xc6 6b1e00) nfsd .text 0xc88ed060 0xc88edb60 0xc88edbfc From owner-linux-xfs@oss.sgi.com Thu Sep 14 07:03:38 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 07:03:19 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:20017 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 07:03:13 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA13716; Thu, 14 Sep 2000 06:55:32 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA26080; Thu, 14 Sep 2000 07:02:42 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA09050; Thu, 14 Sep 2000 07:00:05 -0700 (PDT) Date: Thu, 14 Sep 2000 07:00:05 -0700 (PDT) Message-Id: <200009141400.HAA09050@feature.engr.sgi.com> X-Pv-Incident: 795642 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (lord@sgi.com) Subject: PARTIAL TAKE 795642 - remount -o remount,ro doesn't leave FS consistent To: cattelan@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : dxm Status : open Assigned Engineer : cattelan Priority : 3 *Modified Date : 09/14/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : From: steve lord (PARTIAL) Date: Sep 14 2000 07:00:04AM [pvnews version: 1.71] ---------------------------- The remount readonly code path needs to go through sync twice. Unlinked inodes have two phases of work to go through before they are clean on disk. These are both handled via sync, and will not be handled in the same pass. Date: Wed Sep 13 19:48:37 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74367a linux/fs/xfs/linux/xfs_super.c - 1.87 - Call sync twice in the remount readonly case to deal with removed ino des correctly. Description : Remounting an XFS filesystem R/O can leave the FS in an inconsistent state. (Playing with this for long enough can hang mount up...) Reproduce with QA 013 or: #!/bin/sh DEV=/dev/hda6 MNT=/mnt/arch0 ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: cattelan@engr (BugWorks) Date: Sep 08 2000 02:08:59PM ========================== From owner-linux-xfs@oss.sgi.com Thu Sep 14 07:56:18 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 07:56:08 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:867 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 07:56:02 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA00055 for ; Thu, 14 Sep 2000 08:02:42 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA65261; Thu, 14 Sep 2000 09:54:22 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA00416; Thu, 14 Sep 2000 09:54:22 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA26026; Thu, 14 Sep 2000 09:52:04 -0500 Message-Id: <200009141452.JAA26026@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.3 To: William L Jones cc: linux-xfs@oss.sgi.com, jones@spica.cc.utexas.edu Subject: Re: Should open_by_inode have a special dentry ops? In-Reply-To: Message from William L Jones of "Wed, 13 Sep 2000 20:24:32 CDT." <200009140124.UAA08447@spica.cc.utexas.edu> Date: Thu, 14 Sep 2000 09:51:58 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > Shouldn't open_by_inode have a dentry_operations table like the one found in xfs_iops.c? > I think it should. This may be the source of the reference leak that was noti ced > after using xfxdump. > > If it does, doesn't that indicate that their may be problems exporting a xfs file system > in linux. NFS also creates its own dentries from inodes gained by iget? > > > Bill Jones You may have a point here, if we do not go into the vnode layer when dropping the reference count it will fail to call the xfs inactive code. Steve From owner-linux-xfs@oss.sgi.com Thu Sep 14 11:36:20 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 11:36:01 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:49165 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 11:35:35 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA22049 for ; Thu, 14 Sep 2000 11:27:53 -0700 (PDT) mail_from (cattelan@gibble.americas.sgi.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA89550 for ; Thu, 14 Sep 2000 13:33:02 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id NAA08449 for ; Thu, 14 Sep 2000 13:33:01 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e8EIX0U09665 for linux-xfs@oss.sgi.com; Thu, 14 Sep 2000 13:33:00 -0500 Date: Thu, 14 Sep 2000 13:33:00 -0500 From: Russell Cattelan Message-Id: <200009141833.e8EIX0U09665@gibble.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Sep 14 11:32:36 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74403a linux/fs/Config.in - 1.40 - Remove CONFIG KIO... not used anymore. From owner-linux-xfs@oss.sgi.com Thu Sep 14 12:23:11 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 12:22:51 -0700 Received: from hermes.mixx.net ([212.84.196.2]:8209 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 14 Sep 2000 12:22:39 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 2CAC6F809 for ; Thu, 14 Sep 2000 21:22:37 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id C17472CA6E; Thu, 14 Sep 2000 21:22:36 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: Can any one explain this behavior? Date: 14 Sep 2000 19:22:36 GMT Organization: innominate AG, Berlin, Germany Lines: 30 Distribution: local Message-ID: References: <200009140058.TAA08186@spica.cc.utexas.edu> <200009140103.MAA26966@clouds.melbourne.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 968959356 31864 10.0.0.69 (14 Sep 2000 19:22:36 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel Moore wrote: > William L Jones writes: > => > => > => If you create and mount a xfs file system then untar a few files and direct > => ories in to it > => then run xfs_check you get errors. If you do a sync and then run xfs_chec > => k on the > => file system you still get errors. If you umount and mount the file system t > => hen > => the errors go away. > => > => I think this is has to do with the way the log transactions are handled and > => that their is > => no problem. > => > => But I would like to know for sure! > This is definitely a FAQ. is added to the FAQ now .... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Sep 14 18:46:43 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 18:46:33 -0700 Received: from [211.32.117.45] ([211.32.117.45]:23058 "EHLO s-mail13.hanmail.net") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 18:46:18 -0700 Received: from www31.hanmail.net (www31.hanmail.net [211.32.117.211]) by s-mail13.hanmail.net (8.10.0/8.9.1) with ESMTP id e8F1jJ212540; Fri, 15 Sep 2000 10:45:19 +0900 Received: (from hanadmin@localhost) by www31.hanmail.net (8.10.0/8.9.1) id e8F1iW720118; Fri, 15 Sep 2000 10:44:32 +0900 (KST) X-Originating-IP: [211.203.204.167] From: =?ISO-8859-1?Q? "=C3=D6=C0=B6=BF=F8" ?= Reply-To: =?ISO-8859-1?Q? "=C3=D6=C0=B6=BF=F8" ?= Organization: To: linux-xfs@oss.sgi.com Subject: please mail X-Mailer: Daum Web Mailer 1.0 Date: Fri, 15 Sep 2000 10:44:32 KST Message-Id: <20000915104432.HM.U0000000000mkdG@www31.hanmail.net> MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing mailling list XFS why complie error? header file error? let me know how to solving.... ================================================== żě¸Ž ŔÎĹÍłÝ, Daum Ćňťý ž˛´Â šŤˇá E-mail ÁÖźŇ ÇѸŢŔĎłÝ Áöą¸ĂĚ ÇŃąŰ °Ëťöź­şń˝ş Daum FIREBALL http://www.daum.net From owner-linux-xfs@oss.sgi.com Thu Sep 14 18:56:12 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 18:56:03 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:14713 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 18:55:47 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA14727 for ; Thu, 14 Sep 2000 18:48:05 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA23584; Fri, 15 Sep 2000 12:53:14 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA19730; Fri, 15 Sep 2000 12:53:11 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009151253.ZM19828@wobbly.melbourne.sgi.com> Date: Fri, 15 Sep 2000 12:53:08 -0400 In-Reply-To: =?iso-8859-1?Q?_=22=C3=D6=C0=B6=BF=F8=22__=3Crosebird00=40han?= =?iso-8859-1?Q?mail=2Enet=3E _______=22please_mail=22_=28Sep_15=2C_10=3A44am=29?= References: <20000915104432.HM.U0000000000mkdG@www31.hanmail.net> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: =?iso-8859-1?B?IsPWwLa/+CIg?= Subject: Re: please mail Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.110009151253.ZM19828.melbourne.sgi.com" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --PART-BOUNDARY=.110009151253.ZM19828.melbourne.sgi.com Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u hello =C3=D6=C0=B6=BF=F8, On Sep 15, 10:44am, =C3=D6=C0=B6=BF=F8 wrote: > Subject: please mail > mailling list > = > XFS why complie error? > = > header file error? > = could you send the error message you see? the code in the source tree seems to compile for me at the moment. cheers. -- = Nathan --PART-BOUNDARY=.110009151253.ZM19828.melbourne.sgi.com-- From owner-linux-xfs@oss.sgi.com Thu Sep 14 19:03:43 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 19:03:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21288 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 19:03:11 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA01075; Thu, 14 Sep 2000 19:09:52 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA70076; Thu, 14 Sep 2000 19:03:08 -0700 (PDT) Date: Thu, 14 Sep 2000 19:03:08 -0700 (PDT) Message-Id: <200009150203.TAA70076@info.engr.sgi.com> X-Pv-Incident: 801241 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 801241 - xfsdump can cause filesystem corruption To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801241 Status : open Priority : 1 Assigned Engineer : dxm Submitter : ivanr *Modified User : dxm *Modified User Domain : engr *Description : QA for xfsdump/xfsrestore revealed that it is possible for xfsdump to cause filesystem corruption. The test involves creating a filesystem, creating a whole buncha files, xfsdumping them to a file somewhere, then removing all the files. xfs_check reports lots of inodes with zero link counts, etc. It's probably due to xfsdump using bulkstat on the entire fs. The following is a script which will reliably (at least on bruce.melbourne) produce the error. Run it in cmd/xfs/stress - it needs the src/fill program, and make sure you fix the ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 14 2000 07:03:07PM ========================== *** comment from linux-xfs *** Subject: Should open_by_inode have a special dentry ops? Date: Wed, 13 Sep 2000 20:24:32 -0500 (CDT) (Thu 12:24 EST) From: William L Jones Shouldn't open_by_inode have a dentry_operations table like the one found in xfs_iops.c? I think it should. This may be the source of the reference leak that was noticed after using xfxdump. If it does, doesn't that indicate that their may be problems exporting a xfs file system in linux. NFS also creates its own dentries from inodes gained by iget? Bill Jones *** comment from linux-xfs *** Subject: Re: Should open_by_inode have a special dentry ops? Date: Thu, 14 Sep 2000 09:51:58 -0500 (Fri 01:51 EST) From: Steve Lord You may have a point here, if we do not go into the vnode layer when dropping the reference count it will fail to call the xfs inactive code. Steve *** I've got a fix for this bug based on these two posts, and will hopefully slip it into the beta release. From owner-linux-xfs@oss.sgi.com Thu Sep 14 19:08:13 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 19:07:54 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:45178 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 19:07:37 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA15454; Thu, 14 Sep 2000 18:59:56 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA07391; Thu, 14 Sep 2000 19:07:06 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA39948; Thu, 14 Sep 2000 19:05:49 -0700 (PDT) Date: Thu, 14 Sep 2000 19:05:49 -0700 (PDT) Message-Id: <200009150205.TAA39948@info.engr.sgi.com> X-Pv-Incident: 801764 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: REASSIGN 801764 - xfs_check and xfs_repair should fail if device mounted To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801764 Status : open Priority : 4 *Assigned Engineer : nathans Submitter : dxm Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/13/00 *Modified User : nathans *Modified User Domain : engr *Description : both "xfs_check" and "xfs_repair -n" may be run on a mounted filesystem and will usually produce lots of warnings about filesystem corruption due to the inconsistent state the FS is in. Both tools should fail or at least warn that the FS is mounted before proceeding. xfs_logprint should also warn when run on a mounted FS, but can still be useful when mounted. ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: nathans@engr (BugWorks) Date: Sep 14 2000 07:05:49PM ========================== hi, I have a (trivial) fix which does this: $ logprint/xfs_logprint /dev/hda5 xfs_logprint: /dev/hda5 contains a mounted filesystem ...[carries on]... $ sh db/xfs_check.sh /dev/hda5 xfs_check: /dev/hda5 contains a mounted filesystem fatal error -- couldn't initialize XFS library [exit] $ sudo repair/xfs_repair -n /dev/hda6 xfs_repair: /dev/hda6 contains a mounted filesystem fatal error -- couldn't initialize XFS library [exit] for the folks cloning the tree - is this a beta candidate, or shall I wait and check in the change later? many thanks. From owner-linux-xfs@oss.sgi.com Thu Sep 14 20:55:04 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 20:54:44 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26156 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 20:54:35 -0700 Received: from bruce.melbourne.sgi.com (root@bruce.melbourne.sgi.com [134.14.55.176]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA07867 for ; Thu, 14 Sep 2000 21:01:15 -0700 (PDT) mail_from (fsgqa@bruce.melbourne.sgi.com) Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id OAA27342 for linux-xfs@oss.sgi.com; Fri, 15 Sep 2000 14:54:58 +1100 Date: Fri, 15 Sep 2000 14:54:58 +1100 From: FSG QA Message-Id: <200009150354.OAA27342@bruce.melbourne.sgi.com> Subject: TAKE - qa cleanups To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing required for auto-qa. Doesn't touch anything incuded in release. Date: Thu Sep 14 20:53:01 PDT 2000 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa-normal/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74446a cmd/xfs/stress/check - 1.9 - must be root to run XFS QA cmd/xfs/stress/common.filter - 1.7 - clean $tmp cmd/xfs/stress/common.rc - 1.29 - use remount ro/rw for _fs_check cmd/xfs/stress/group - 1.36 - add excluded tests to auto-qa cmd/xfs/stress/008 - 1.4 cmd/xfs/stress/011 - 1.4 cmd/xfs/stress/012 - 1.3 cmd/xfs/stress/014 - 1.3 - clean $tmp cmd/xfs/stress/017.out - 1.3 - fix. From owner-linux-xfs@oss.sgi.com Thu Sep 14 20:55:04 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 20:54:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:37388 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 20:54:16 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA22301; Thu, 14 Sep 2000 20:46:35 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA66297; Thu, 14 Sep 2000 20:53:45 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA56905; Thu, 14 Sep 2000 20:52:27 -0700 (PDT) Date: Thu, 14 Sep 2000 20:52:27 -0700 (PDT) Message-Id: <200009150352.UAA56905@info.engr.sgi.com> X-Pv-Incident: 801063 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: CLOSE 801063 - mkfs.xfs after having ext2 mounted on a device can fail To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801063 *Status : closed Priority : 4 Assigned Engineer : nathans Submitter : lord Opened Date : 09/06/00 *Closed Date : 09/14/00 *Fixed By : nathans *Fixed By Domain : engr *Modified Date : 09/14/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : From: nathan scott (PARTIAL) Date: Sep 07 2000 05:15:10PM [pvnews version: 1.71] ---------------------------- Steve, Please let me know whether this fixes your write error. I've also put a mkfs binary at babylon:/tmp/mkfs.xfs - could you run this one too, then send me the output and ..... ========================== ADDITIONAL INFORMATION (CLOSE) From: nathans@engr (BugWorks) Date: Sep 14 2000 08:52:27PM ========================== This has been fixed with Martin's BLKSETSIZE changes. From owner-linux-xfs@oss.sgi.com Thu Sep 14 22:25:54 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 22:25:44 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39215 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 22:25:25 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA04820; Thu, 14 Sep 2000 22:32:07 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id WAA12319; Thu, 14 Sep 2000 22:24:54 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA60308; Thu, 14 Sep 2000 22:23:36 -0700 (PDT) Date: Thu, 14 Sep 2000 22:23:36 -0700 (PDT) Message-Id: <200009150523.WAA60308@info.engr.sgi.com> X-Pv-Incident: 800992 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 800992 - pagebuf_init call to kmem_cache_create BUG() To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800992 Status : open Priority : 2 Assigned Engineer : dxm Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : On my test box, I'd been playing with xfs, then umounted, rmmoded and insmoded the modules. When pagebuf was insmoded, this kernel BUG() was tripped. I'll see if I can get some more info on this one. kmem_cache_destroy: Can't free all objects c116d764 kernel BUG at slab.c:806! Entering kdb (0xc215e000) Panic: invalid operand ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 14 2000 10:23:35PM ========================== Ok, so it turns out that I never noticed this before because it's only an issue if CONFIG_XFS_VNODE_TRACING is enabled _and_ you fail a mount. On a failed unmount, linvfs_read_super does not do a ktrace_free on the buffer it allocates with ktrace_alloc. The ktrace_free is normally done by linvfs_put_super but this is not called since the mount failed. This patch also stops a leaked inode on mount fail and gotos the right place if the pagebuf daemons fail to start. Could someone rv for me? Steve? Ta. (beta worthy?) --- /usr/tmp/p_rdiff_a0PybF/xfs_super.c Fri Sep 15 16:19:57 2000 +++ /build1/people/dxm/isms/slinx-xfs/linux/fs/xfs/linux/xfs_super.c Fri Sep 15 16:14:29 2000 @@ -174,7 +174,7 @@ /* first mount pagebuf delayed write daemon not running yet */ if (pagebuf_daemon_start() < 0) { - goto fail_vnrele; + goto fail_daemon; } /* Setup the uap structure */ @@ -299,6 +299,15 @@ fail_vfsop: vfs_deallocate(vfsp); +#ifdef CONFIG_XFS_VNODE_TRACING + ktrace_free(cvp->v_trace); + + cvp->v_trace = NULL; +#endif /* CONFIG_XFS_VNODE_TRACING */ + + kfree(cvp->v_inode); + +fail_daemon: MOD_DEC_USE_COUNT; return(NULL); From owner-linux-xfs@oss.sgi.com Thu Sep 14 22:27:23 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 22:27:03 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:33815 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 22:26:56 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA27846; Thu, 14 Sep 2000 22:19:15 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA52311; Thu, 14 Sep 2000 22:26:52 -0700 (PDT) Date: Thu, 14 Sep 2000 22:26:52 -0700 (PDT) Message-Id: <200009150526.WAA52311@info.engr.sgi.com> X-Pv-Incident: 801241 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 801241 - xfsdump can cause filesystem corruption To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801241 *Status : closed Priority : 1 Assigned Engineer : dxm Submitter : ivanr Opened Date : 09/07/00 *Closed Date : 09/14/00 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 09/14/00 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Sep 14 2000 10:26:51PM ========================== Well it appears that bugworks ate my TAKE, so I'll CLOSE instead. trivial fix, important bug, definite beta material Date: Thu Sep 14 19:21:02 PDT 2000 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa-normal/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74444a linux/fs/xfs/linux/xfs_iops.c - 1.68 - pv 801241 rv lord add function linvfs_set_dentry_ops to set dentry ops linux/fs/xfs/linux/xfs_iops.h - 1.7 - pv 801241 rv lord export linvfs_set_dentry_ops linux/fs/xfs/linux/xfs_ioctl.c - 1.19 - pv 801241 rv lord call linvfs_set_dentry_ops to prevent refernce leak on dput From owner-linux-xfs@oss.sgi.com Thu Sep 14 22:27:54 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 22:27:34 -0700 Received: from lips.borg.umn.edu ([160.94.232.50]:10513 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 22:27:30 -0700 Received: from phuck.thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e8F5RSE35186 for ; Fri, 15 Sep 2000 00:27:28 -0500 (CDT) Received: from thebarn.com (localhost [127.0.0.1]) by phuck.thebarn.com (8.9.3/8.9.2) with ESMTP id AAA03203 for ; Fri, 15 Sep 2000 00:27:12 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39C1B32F.8BC096A7@thebarn.com> Date: Fri, 15 Sep 2000 00:27:12 -0500 From: Russell Cattelan Organization: Moo Solutions X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Ok the first beta candiate is finally built Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ftp;//oss.sgi.com/projects/xfs/download/BETA-c1/ I haven't tested it as of yet, so I don't know if will work or not. Give it a try... send comments. I'm tired... more tomorrow. -Russell. From owner-linux-xfs@oss.sgi.com Fri Sep 15 07:58:35 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 07:58:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:48742 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 15 Sep 2000 07:58:04 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA07005; Fri, 15 Sep 2000 07:50:22 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA39972; Fri, 15 Sep 2000 07:58:02 -0700 (PDT) Date: Fri, 15 Sep 2000 07:58:02 -0700 (PDT) Message-Id: <200009151458.HAA39972@info.engr.sgi.com> X-Pv-Incident: 800992 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800992 - pagebuf_init call to kmem_cache_create BUG() To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800992 Status : open Priority : 2 Assigned Engineer : dxm Submitter : dxm *Modified User : lord *Modified User Domain : sgi.com *Description : On my test box, I'd been playing with xfs, then umounted, rmmoded and insmoded the modules. When pagebuf was insmoded, this kernel BUG() was tripped. I'll see if I can get some more info on this one. kmem_cache_destroy: Can't free all objects c116d764 kernel BUG at slab.c:806! Entering kdb (0xc215e000) Panic: invalid operand ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 15 2000 07:58:01AM ========================== Code change looks OK to me. Since it is isolated I would throw it into the tree as well. From owner-linux-xfs@oss.sgi.com Fri Sep 15 08:24:34 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 08:24:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:44908 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 15 Sep 2000 08:24:08 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA09927 for ; Fri, 15 Sep 2000 08:16:26 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA67164; Fri, 15 Sep 2000 10:21:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA70961; Fri, 15 Sep 2000 10:21:33 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id KAA16614; Fri, 15 Sep 2000 10:19:05 -0500 Message-Id: <200009151519.KAA16614@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Russell Cattelan cc: linux-xfs@oss.sgi.com Subject: Re: Ok the first beta candiate is finally built In-Reply-To: Message from Russell Cattelan of "Fri, 15 Sep 2000 00:27:12 CDT." <39C1B32F.8BC096A7@thebarn.com> Date: Fri, 15 Sep 2000 10:19:04 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > ftp;//oss.sgi.com/projects/xfs/download/BETA-c1/ > > I haven't tested it as of yet, so I don't know if will work or not. > > Give it a try... send comments. > > I'm tired... more tomorrow. > > -Russell. > I guess the next step is to put the RPMs these depend on out there, plus a kernel source rpm. These dependencies tripped me up: devfsd is needed by kernel-smp-2.4.0-4SGI_9 modutils >= 2.3.14 is needed by kernel-smp-2.4.0-4SGI_9 modutils is easy to get, devfsd is not so easy. Steve From owner-linux-xfs@oss.sgi.com Fri Sep 15 08:46:44 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 08:46:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:19570 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 15 Sep 2000 08:45:58 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA12619 for ; Fri, 15 Sep 2000 08:38:17 -0700 (PDT) mail_from (mann@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA70665 for ; Fri, 15 Sep 2000 10:43:26 -0500 (CDT) Received: from fsgi632.americas.sgi.com (fsgi632.americas.sgi.com [128.162.184.134]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA03169 for ; Fri, 15 Sep 2000 10:43:25 -0500 (CDT) Received: from sgi.com by fsgi632.americas.sgi.com (SGI-8.9.3/SGI-client-1.6c) via ESMTP id KAA03623; Fri, 15 Sep 2000 10:43:24 -0500 (CDT) Message-ID: <39C2439A.FCBE2171@sgi.com> Date: Fri, 15 Sep 2000 10:43:23 -0500 From: Mark Nordstrand X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Ok the first beta candiate is finally built References: <200009151519.KAA16614@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > > ftp;//oss.sgi.com/projects/xfs/download/BETA-c1/ > > > > I haven't tested it as of yet, so I don't know if will work or not. > > > > Give it a try... send comments. > > > > I'm tired... more tomorrow. > > > > -Russell. > > > > I guess the next step is to put the RPMs these depend on out there, plus > a kernel source rpm. > > These dependencies tripped me up: > > devfsd is needed by kernel-smp-2.4.0-4SGI_9 > modutils >= 2.3.14 is needed by kernel-smp-2.4.0-4SGI_9 > > modutils is easy to get, devfsd is not so easy. > > Steve I tripped on: initscripts >= 5.00 is needed by kernel-2.4.0-4SGI_9 devfsd is needed by kernel-2.4.0-4SGI_9 followed by: depmod: invalid option -- i depmod 2.3.16 once initscripts and devfsd were installed. Mark From owner-linux-xfs@oss.sgi.com Fri Sep 15 12:57:40 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 12:57:31 -0700 Received: from [12.125.238.14] ([12.125.238.14]:1803 "EHLO rnd04") by oss.sgi.com with ESMTP id ; Fri, 15 Sep 2000 12:57:16 -0700 Received: from randell.com (rnd15 [195.180.82.185]) by rnd04 (8.9.3/8.9.3) with ESMTP id PAA06081 for ; Fri, 15 Sep 2000 15:57:16 -0400 Message-ID: <39C27F18.CCE993CD@randell.com> Date: Fri, 15 Sep 2000 15:57:12 -0400 From: Jeff Hengesbach X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: lilo on full XFS setup Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I know the FAQ says xfs works well on /, but I have observed this: -On a setup using only xfs partitions, lilo will not install the mbr correctly. This installation has no ext2 partitions. Have to use a boot disk(xfs kernel) to boot with. Lilo does not complain when ran -On a setup where /boot is left ext2 and everything else xfs, works fine. I just have /boot listed as (ro,defaults) in fstab to prevent its corruption. I also observed this during a xfs conversion - when after dumping the ext2 system to the new xfs partitions then running lilo to create an entry for the xfs setup while it is running on ext2 fs - But if I reboot to xfs setup and run lilo - bad news, must use boot disk to boot to ext2 setup and run lilo from there.... Great work so far to the team. The kernel is the cvs version from 9/12 or 9/13. IDE drive - 450Mhz K6-2. Jeff H From owner-linux-xfs@oss.sgi.com Fri Sep 15 13:07:40 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 13:07:30 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17741 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 15 Sep 2000 13:07:16 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA26390 for ; Fri, 15 Sep 2000 12:59:34 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id PAA50234; Fri, 15 Sep 2000 15:05:15 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id PAA17775; Fri, 15 Sep 2000 15:05:14 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e8FK5EY15439; Fri, 15 Sep 2000 15:05:14 -0500 Message-ID: <39C280F8.BDD007BD@thebarn.com> Date: Fri, 15 Sep 2000 15:05:12 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Hengesbach CC: "linux-xfs@oss.sgi.com" Subject: Re: lilo on full XFS setup References: <39C27F18.CCE993CD@randell.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jeff Hengesbach wrote: > I know the FAQ says xfs works well on /, but I have observed this: > > -On a setup using only xfs partitions, lilo will not install the mbr > correctly. This installation has no ext2 partitions. Have to use a boot > disk(xfs kernel) to boot with. Lilo does not complain when ran > > -On a setup where /boot is left ext2 and everything else xfs, works > fine. I just have /boot listed as (ro,defaults) in fstab to prevent its > corruption. I also observed this during a xfs conversion - when after > dumping the ext2 system to the new xfs partitions then running lilo to > create an entry for the xfs setup while it is running on ext2 fs - But > if I reboot to xfs setup and run lilo - bad news, must use boot disk to > boot to ext2 setup and run lilo from there.... > > Great work so far to the team. > > The kernel is the cvs version from 9/12 or 9/13. IDE drive - 450Mhz > K6-2. > > Jeff H Yes...that is a know problem the FAQ does need to up be updated to it does not work. It is on our list of things to fix... after we get the beta release out the door. -Russell From owner-linux-xfs@oss.sgi.com Fri Sep 15 13:11:11 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 13:10:50 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:43854 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 15 Sep 2000 13:10:35 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA27120 for ; Fri, 15 Sep 2000 13:02:48 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id PAA62513; Fri, 15 Sep 2000 15:08:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA90814; Fri, 15 Sep 2000 15:08:45 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id PAA17867; Fri, 15 Sep 2000 15:06:15 -0500 Message-Id: <200009152006.PAA17867@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jeff Hengesbach cc: "linux-xfs@oss.sgi.com" Subject: Re: lilo on full XFS setup In-Reply-To: Message from Jeff Hengesbach of "Fri, 15 Sep 2000 15:57:12 EDT." <39C27F18.CCE993CD@randell.com> Date: Fri, 15 Sep 2000 15:06:15 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > I know the FAQ says xfs works well on /, but I have observed this: > > -On a setup using only xfs partitions, lilo will not install the mbr > correctly. This installation has no ext2 partitions. Have to use a boot > disk(xfs kernel) to boot with. Lilo does not complain when ran > > -On a setup where /boot is left ext2 and everything else xfs, works > fine. I just have /boot listed as (ro,defaults) in fstab to prevent its > corruption. I also observed this during a xfs conversion - when after > dumping the ext2 system to the new xfs partitions then running lilo to > create an entry for the xfs setup while it is running on ext2 fs - But > if I reboot to xfs setup and run lilo - bad news, must use boot disk to > boot to ext2 setup and run lilo from there.... > > Great work so far to the team. > > The kernel is the cvs version from 9/12 or 9/13. IDE drive - 450Mhz > K6-2. > > Jeff H Yes, I have seen the same thing. I have had a couple of reports of successful lilo installation, but never achieved it myself. In my case lilo gets to the LIL- state and hangs. I got as far as running strace on lilo and looking at the difference. Yhe Are you using a complex lilo.conf file or just a single kernel entry? Steve From owner-linux-xfs@oss.sgi.com Fri Sep 15 13:15:10 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 13:14:51 -0700 Received: from [12.125.238.14] ([12.125.238.14]:5902 "EHLO rnd04") by oss.sgi.com with ESMTP id ; Fri, 15 Sep 2000 13:14:39 -0700 Received: from randell.com (rnd15 [195.180.82.185]) by rnd04 (8.9.3/8.9.3) with ESMTP id QAA06100; Fri, 15 Sep 2000 16:14:37 -0400 Message-ID: <39C28328.2F3C7BFF@randell.com> Date: Fri, 15 Sep 2000 16:14:32 -0400 From: Jeff Hengesbach X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: "linux-xfs@oss.sgi.com" Subject: Re: lilo on full XFS setup References: <200009152006.PAA17867@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > > > I know the FAQ says xfs works well on /, but I have observed this: > > > > -On a setup using only xfs partitions, lilo will not install the mbr > > correctly. This installation has no ext2 partitions. Have to use a boot > > disk(xfs kernel) to boot with. Lilo does not complain when ran > > > > -On a setup where /boot is left ext2 and everything else xfs, works > > fine. I just have /boot listed as (ro,defaults) in fstab to prevent its > > corruption. I also observed this during a xfs conversion - when after > > dumping the ext2 system to the new xfs partitions then running lilo to > > create an entry for the xfs setup while it is running on ext2 fs - But > > if I reboot to xfs setup and run lilo - bad news, must use boot disk to > > boot to ext2 setup and run lilo from there.... > > > > Great work so far to the team. > > > > The kernel is the cvs version from 9/12 or 9/13. IDE drive - 450Mhz > > K6-2. > > > > Jeff H > > Yes, I have seen the same thing. I have had a couple of reports of successful > lilo installation, but never achieved it myself. > > In my case lilo gets to the LIL- state and hangs. I got as far as running > strace on lilo and looking at the difference. Yhe > > Are you using a complex lilo.conf file or just a single kernel entry? > > Steve During my attempts, I went from a lilo with 3 entries to just the 1 - no different result wise though. I experienced the LIL- as well. From owner-linux-xfs@oss.sgi.com Fri Sep 15 13:55:10 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 13:55:00 -0700 Received: from [12.125.238.14] ([12.125.238.14]:63240 "EHLO rnd04") by oss.sgi.com with ESMTP id ; Fri, 15 Sep 2000 13:54:41 -0700 Received: from randell.com (rnd15 [195.180.82.185]) by rnd04 (8.9.3/8.9.3) with ESMTP id QAA06123 for ; Fri, 15 Sep 2000 16:54:42 -0400 Message-ID: <39C28C8C.B179790E@randell.com> Date: Fri, 15 Sep 2000 16:54:36 -0400 From: Jeff Hengesbach X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: "majordomo@oss.sgi.com" Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing list end From owner-linux-xfs@oss.sgi.com Fri Sep 15 15:20:00 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 15:19:50 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13833 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 15 Sep 2000 15:19:40 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA02168 for ; Fri, 15 Sep 2000 15:26:21 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA29726 for linux-xfs@oss.sgi.com; Sat, 16 Sep 2000 09:18:20 +1100 (EST) Date: Sat, 16 Sep 2000 09:18:20 +1100 (EST) From: Daniel Moore Message-Id: <200009152218.JAA29726@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 800992 panic on insmod after failed mount Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing another one for beta... Modid: 2.4.0-test1-xfs:slinx:74540a Date: Fri Sep 15 15:13:36 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/linux/xfs_super.c - 1.88 - pv 800992 rv lord don't leak ktrace buffer or inode on mount fail From owner-linux-xfs@oss.sgi.com Fri Sep 15 16:47:51 2000 Received: by oss.sgi.com id ; Fri, 15 Sep 2000 16:47:41 -0700 Received: from hermes.mixx.net ([212.84.196.2]:30728 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 15 Sep 2000 16:47:22 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 932ECF81D for ; Sat, 16 Sep 2000 01:47:19 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 3D0EE2CA6D; Sat, 16 Sep 2000 01:47:19 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: lilo on full XFS setup Date: 15 Sep 2000 23:47:19 GMT Organization: innominate AG, Berlin, Germany Lines: 20 Distribution: local Message-ID: References: <39C27F18.CCE993CD@randell.com> <39C280F8.BDD007BD@thebarn.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 969061639 4672 10.0.0.69 (15 Sep 2000 23:47:19 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: >> I know the FAQ says xfs works well on /, but I have observed this: >> >> -On a setup using only xfs partitions, lilo will not install the mbr >> correctly. This installation has no ext2 partitions. Have to use a boot >> disk(xfs kernel) to boot with. Lilo does not complain when ran > Yes...that is a know problem the FAQ does need to up be updated > to it does not work. done ... btw. - the information that it works came from you or steve :-) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sat Sep 16 02:28:06 2000 Received: by oss.sgi.com id ; Sat, 16 Sep 2000 02:27:57 -0700 Received: from hermes.mixx.net ([212.84.196.2]:45841 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 16 Sep 2000 02:27:39 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 44DCDF814 for ; Sat, 16 Sep 2000 11:27:37 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id F074A2CA6D; Sat, 16 Sep 2000 11:27:36 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs seems to be stable on ppc now Date: 16 Sep 2000 09:27:36 GMT Organization: innominate AG, Berlin, Germany Lines: 18 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 969096456 23581 10.0.0.69 (16 Sep 2000 09:27:36 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing it really looks like xfs is now really stable on ppc too - haven't seen any problem so far and run the imac now with xfs as root fs - i hope that i'm not too early happy but so far it looks really good ... for anybody else who want's to try it http://innominate.org/~graichen/projects/xfs/ppc-xfs-diff.000914 is a diff to the sgi xfs cvs tree ... t p.s.: those tests were done on a SuSE 6.4 ppc system btw. -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sat Sep 16 02:44:36 2000 Received: by oss.sgi.com id ; Sat, 16 Sep 2000 02:44:26 -0700 Received: from hermes.mixx.net ([212.84.196.2]:64273 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 16 Sep 2000 02:44:10 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id BEA90F814 for ; Sat, 16 Sep 2000 11:44:07 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 771FD2CA6D; Sat, 16 Sep 2000 11:44:07 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs seems to be stable on ppc now Date: 16 Sep 2000 09:44:07 GMT Organization: innominate AG, Berlin, Germany Lines: 15 Distribution: local Message-ID: References: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 969097447 23581 10.0.0.69 (16 Sep 2000 09:44:07 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > it really looks like xfs is now really stable on ppc too - haven't > seen any problem so far and run the imac now with xfs as root fs ... btw. - i will start looking deeper into linux/alpha starting next week - maybe it also works better now ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sat Sep 16 15:30:12 2000 Received: by oss.sgi.com id ; Sat, 16 Sep 2000 15:29:52 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:13983 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sat, 16 Sep 2000 15:29:30 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id RAA16461 for ; Sat, 16 Sep 2000 17:29:27 -0500 (CDT) Message-Id: <4.2.0.58.20000916163556.0193c950@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 16 Sep 2000 17:31:38 -0500 To: linux-xfs@oss.sgi.com From: "William L. Jones" Subject: Just a small reminder Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The use the dentry d_iput function creates a problem with nfsd. It to creates a dentry from an iget like open_by_filehndle and will cause vnode reference problems. Couldn't this problem be solved cleaner by using the linux provided iop functions like put_inode and clear_inode. Then the nfs would not have special case for xfs. Given the way the vn_rele works currently is their a problem with it marking the vnode inactive. Linux will retain the inode in its cache until it decides to prune it, which means it may reuse it. Wouldn't it be better to mark it inactive in a clear_inode call? Bill Jones From owner-linux-xfs@oss.sgi.com Sun Sep 17 06:55:37 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 06:55:28 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:52805 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 06:55:10 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA07572 for ; Sun, 17 Sep 2000 07:01:54 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id IAA69536; Sun, 17 Sep 2000 08:53:53 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id IAA46720; Sun, 17 Sep 2000 08:53:52 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id IAA27556; Sun, 17 Sep 2000 08:51:05 -0500 Message-Id: <200009171351.IAA27556@jen.americas.sgi.com> To: "William L. Jones" cc: linux-xfs@oss.sgi.com Subject: Re: Just a small reminder From: lord@sgi.com In-reply-to: Your message of "Sat, 16 Sep 2000 17:31:38 CDT Date: Sun, 17 Sep 2000 08:50:59 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > The use the dentry d_iput function creates a problem with nfsd. It to > creates a dentry from an iget like open_by_filehndle and will cause > vnode reference problems. Couldn't this problem be solved cleaner > by using the linux provided iop functions like put_inode and clear_inode. > Then the nfs would not have special case for xfs. > > > Given the way the vn_rele works currently is their a problem with it > marking the vnode inactive. Linux will retain > the inode in its cache until it decides to prune it, which means it may > reuse it. Wouldn't it be > better to mark it inactive in a clear_inode call? > > > Bill Jones Yes, I am aware of this. The issues here are that the put_inode method is racey in that it always calls put inode, then does an atomic decrement and lock on the count. Only if the count hits zero does it obtain a lock and do special processing. It is quite possible we would call the inactive code, and then have something else grab a reference count. Using d_iput is not perfect either as we cannot hold a lock across all of it. Marking the vnode inactive is not a problem here, we do not remove the inode from the system at this point, that is done in the clear inode phase. In fact XFS will keep xfs inodes after the linux inode has gone in some cases. We cannot use clear_inode to call inactive, as you only get here on inode reuse. This is a long time later. Steve From owner-linux-xfs@oss.sgi.com Sun Sep 17 10:09:59 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 10:09:50 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:49850 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 10:09:36 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id MAA25307; Sun, 17 Sep 2000 12:09:30 -0500 (CDT) Message-Id: <4.2.0.58.20000917115310.00a1e750@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 17 Sep 2000 12:11:41 -0500 To: lord@sgi.com From: "William L. Jones" Subject: Re: Just a small reminder Cc: linux-xfs@oss.sgi.com In-Reply-To: <200009171351.IAA27556@jen.americas.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 08:50 AM 9/17/00 -0500, lord@sgi.com wrote: > > > > > > The use the dentry d_iput function creates a problem with nfsd. It to > > creates a dentry from an iget like open_by_filehndle and will cause > > vnode reference problems. Couldn't this problem be solved cleaner > > by using the linux provided iop functions like put_inode and clear_inode. > > Then the nfs would not have special case for xfs. > > > > > > Given the way the vn_rele works currently is their a problem with it > > marking the vnode inactive. Linux will retain > > the inode in its cache until it decides to prune it, which means it may > > reuse it. Wouldn't it be > > better to mark it inactive in a clear_inode call? > > > > > > Bill Jones > >Yes, I am aware of this. The issues here are that the put_inode method is >racey in that it always calls put inode, then does an atomic decrement and >lock on the count. Only if the count hits zero does it obtain a lock and do >special processing. It is quite possible we would call the inactive code, >and then have something else grab a reference count. But you have the same problem with the current code. Their is no difference between using dcache d_iput or the supper operation put_inode.! In both cases most of the iput work is done after the call to vn_rele. The second method is better since it works with nfsd. Can xfs_inactive sleep? It it can then both methods have a problem because it is possible to have a d_iput or iput running vn_rele at the same time and i_count will be greater then 1! >Using d_iput is not perfect either as we cannot hold a lock across all of it. > >Marking the vnode inactive is not a problem here, we do not remove the inode >from the system at this point, that is done in the clear inode phase. In >fact XFS will keep xfs inodes after the linux inode has gone in some cases. >We cannot use clear_inode to call inactive, as you only get here on inode >reuse. This is a long time later. I found the clear_inode code! >Steve From owner-linux-xfs@oss.sgi.com Sun Sep 17 10:26:19 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 10:26:00 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:6075 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 10:25:41 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id MAA25416; Sun, 17 Sep 2000 12:25:34 -0500 (CDT) Message-Id: <4.2.0.58.20000917121659.00a30260@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 17 Sep 2000 12:27:45 -0500 To: "William L. Jones" , lord@sgi.com From: "William L. Jones" Subject: Re: Just a small reminder Cc: linux-xfs@oss.sgi.com In-Reply-To: <4.2.0.58.20000917115310.00a1e750@127.0.0.1> References: <200009171351.IAA27556@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 12:11 PM 9/17/00 -0500, William L. Jones wrote: >At 08:50 AM 9/17/00 -0500, lord@sgi.com wrote: >> > >> > >> > The use the dentry d_iput function creates a problem with nfsd. It to >> > creates a dentry from an iget like open_by_filehndle and will cause >> > vnode reference problems. Couldn't this problem be solved cleaner >> > by using the linux provided iop functions like put_inode and clear_inode. >> > Then the nfs would not have special case for xfs. >> > >> > >> > Given the way the vn_rele works currently is their a problem with it >> > marking the vnode inactive. Linux will retain >> > the inode in its cache until it decides to prune it, which means it may >> > reuse it. Wouldn't it be >> > better to mark it inactive in a clear_inode call? >> > >> > >> > Bill Jones >> >>Yes, I am aware of this. The issues here are that the put_inode method is >>racey in that it always calls put inode, then does an atomic decrement and >>lock on the count. Only if the count hits zero does it obtain a lock and do >>special processing. It is quite possible we would call the inactive code, >>and then have something else grab a reference count. > > >But you have the same problem with the current code. Their >is no difference between using dcache d_iput or the supper operation >put_inode.! > >In both cases most of the iput work is done after the call to vn_rele. >The second method is better since it works with nfsd. > >Can xfs_inactive sleep? It it can then both methods have a problem because >it is possible to have a d_iput or iput running vn_rele at the same time >and i_count will be greater then 1! Oops! If we get to xfs_inactive it is the last iput. I still worry that it is possible for two iput to be done at the same time give that the that vn_rele does a VN_LOCK. If you are doing a lock you can sleep! Still this may only be a mpp thing! Using d_iput is not perfect either as we cannot hold a lock across all of it. >>Marking the vnode inactive is not a problem here, we do not remove the inode >>from the system at this point, that is done in the clear inode phase. In >>fact XFS will keep xfs inodes after the linux inode has gone in some cases. >>We cannot use clear_inode to call inactive, as you only get here on inode >>reuse. This is a long time later. > >I found the clear_inode code! > >>Steve > > From owner-linux-xfs@oss.sgi.com Sun Sep 17 14:20:29 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 14:20:20 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:51975 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 14:19:56 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA06225; Sun, 17 Sep 2000 14:12:14 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA81097; Sun, 17 Sep 2000 14:19:54 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA57599; Sun, 17 Sep 2000 14:18:36 -0700 (PDT) Date: Sun, 17 Sep 2000 14:18:36 -0700 (PDT) Message-Id: <200009172118.OAA57599@info.engr.sgi.com> X-Pv-Incident: 800992 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 800992 - pagebuf_init call to kmem_cache_create BUG() To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800992 *Status : closed Priority : 2 Assigned Engineer : dxm Submitter : dxm Opened Date : 09/05/00 *Closed Date : 09/17/00 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 09/17/00 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (OBSERVE) From: dxm@engr (BugWorks) Date: Sep 12 2000 02:47:07PM ========================== I haven't seen this problem since. I suspect it was caused by XFS getting into a funny state due to other problems. Keep and eye out for this one to see if it can happen again. ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Sep 17 2000 02:18:36PM ========================== another one for beta... Modid: 2.4.0-test1-xfs:slinx:74540a Date: Fri Sep 15 15:13:36 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/linux/xfs_super.c - 1.88 - pv 800992 rv lord don't leak ktrace buffer or inode on mount fail From owner-linux-xfs@oss.sgi.com Sun Sep 17 15:19:20 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 15:19:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:59408 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 15:18:57 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA11484; Sun, 17 Sep 2000 15:11:16 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA86682; Sun, 17 Sep 2000 15:18:56 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA27027; Sun, 17 Sep 2000 15:17:38 -0700 (PDT) Date: Sun, 17 Sep 2000 15:17:38 -0700 (PDT) Message-Id: <200009172217.PAA27027@info.engr.sgi.com> X-Pv-Incident: 802017 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 802017 - ASSERT fail in xlog_get_bp on small mem machine To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017 Submitter : dxm Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, the only way I can mount my XFS partition is by running xfs_repair on it to zero the log before mounting it. xlog_get_bp should at least fail nicely if it can't get the memory required but preferably the log code should be able to work around this somehow (and/or request less memory?). XFS assertion failed: bp, file: xfs_log_recover.c, line: 153 kernel BUG at xfs_debug.c:50! Entering kdb (current=0xc1838000, pid 1082) Panic: invalid operand due to panic @ 0xc288ba49 eax = 0x0000001e ebx = 0x00000000 ecx = 0xc02a2eec edx = 0x00000000 esi = 0x0000257f edi = 0x00000000 esp = 0xc18398b4 eip = 0xc288ba49 ebp = 0xc18398c0 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xc1839880 kdb> bt EBP EIP Function(args) 0xc18398c0 0xc288ba49 [xfs]assfail+0x2d (0xc28a5000, 0xc28a4fe0, 0x99) xfs .text 0xc281d060 0xc288ba1c 0xc288ba50 0xc18398d8 0xc286a08e [xfs]xlog_get_bp+0x5e (0x100, 0xc13ce000) xfs .text 0xc281d060 0xc286a030 0xc286a098 0xc1839920 0xc286b278 [xfs]xlog_find_zeroed+0x16c (0xc1dcf480, 0xc1839988) xfs .text 0xc281d060 0xc286b10c 0xc286b38c 0xc1839990 0xc286a7a3 [xfs]xlog_find_head+0x1f (0xc1dcf480, 0xc1839a0c) xfs .text 0xc281d060 0xc286a784 0xc286ad9c 0xc18399e0 0xc286adb9 [xfs]xlog_find_tail+0x1d (0xc1dcf480, 0xc1839a0c, 0xc1839a14, 0x0, 0x306) xfs .text 0xc281d060 0xc286ad9c 0xc286b10c 0xc1839a1c 0xc286e55d [xfs]xlog_recover+0x21 (0xc1dcf480, 0x0, 0xc13ce000) xfs .text 0xc281d060 0xc286e53c 0xc286e5f8 0xc1839a3c 0xc2866b7b [xfs]xfs_log_mount+0xc7 (0xc13ce000, 0x306, 0x32360, 0x0, 0x2580) xfs .text 0xc281d060 0xc2866ab4 0xc2866bb4 0xc1839b58 0xc287300a [xfs]xfs_mountfs_int+0xa76 (0xc0be4ee0, 0xc13ce000, 0x306, 0x4) xfs .text 0xc281d060 0xc2872594 0xc28734e4 0xc1839b70 0xc28734fb [xfs]xfs_mountfs+0x17 (0xc0be4ee0, 0xc13ce000, 0x306) xfs .text 0xc281d060 0xc28734e4 0xc2873500 0xc1839be8 0xc287efa9 [xfs]xfs_cmountfs+0x58d (0xc0be4ee0, 0x306, 0x306, 0x0, 0x2) xfs .text 0xc281d060 0xc287ea1c 0xc287f02c 0xc1839c70 0xc287f1e9 [xfs]xfs_mount+0xe9 (0xc0be4ee0, 0xc09b06e0, 0xc1839eb4, 0xc28ae080, 0xc0be4ee0) xfs .text 0xc281d060 0xc287f100 0xc287f2d4 more> 0xc1839c98 0xc287f2f5 [xfs]xfs_vfsmount+0x21 (0xc0be4ee0, 0xc09b06e0, 0xc1839eb4, 0x0, 0xc28ae080) xfs .text 0xc281d060 0xc287f2d4 0xc287f30c 0xc1839ec8 0xc28942f2 [xfs]linvfs_read_super+0x236 (0xc09b0400, 0x0, 0x0) xfs .text 0xc281d060 0xc28940bc 0xc2894450 0xc1839ee8 0xc012f645 read_super+0x105 (0x306, 0xc17b9520, 0xc28adca8, 0x0, 0x0) kernel .text 0xc0100000 0xc012f540 0xc012f69c 0xc1839f38 0xc012f83c get_sb_bdev+0x138 (0xc28adca8, 0xc124d000, 0x0, 0x0) kernel .text 0xc0100000 0xc012f704 0xc012f890 0xc1839f8c 0xc013034a do_mount+0x19e (0xc124d000, 0xc0833000, 0xc1ebb000, 0xc0ed0000, 0x0) kernel .text 0xc0100000 0xc01301ac 0xc0130460 0xc1839fbc 0xc01304dc sys_mount+0x7c (0x8059a40, 0x8059a50, 0x8059a60, 0xc0ed0000, 0x0) kernel .text 0xc0100000 0xc0130460 0xc0130520 0xc0108f08 system_call+0x34 kernel .text 0xc0100000 0xc0108ed4 0xc0108f0c From owner-linux-xfs@oss.sgi.com Sun Sep 17 15:21:40 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 15:21:31 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:3601 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 15:21:23 -0700 Received: from feature.engr.sgi.com (feature.engr.sgi.com [130.62.40.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA11556; Sun, 17 Sep 2000 15:13:41 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA16519; Sun, 17 Sep 2000 15:20:03 -0700 (PDT) Date: Sun, 17 Sep 2000 15:20:03 -0700 (PDT) Message-Id: <200009172220.PAA16519@feature.engr.sgi.com> X-Pv-Incident: 802017 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (nb@sgi.com) Subject: ADD 802017 - ASSERT fail in xlog_get_bp on small mem machine To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : dxm Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 09/17/00 *Modified User : nb *Modified User Domain : sgi.com *Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, ..... ========================== ADDITIONAL INFORMATION (ADD) From: neil bannister Date: Sep 17 2000 03:20:03PM [pvnews version: 1.71] ========================== Hello, I will be out of the office from 09/07 onwards and back in the office 09/18. In my abscence please contaact Troy McCorkell @ vnet 233-5760 or 651-683-5760 or tdm@sgi.com. Thanks Neil Bannister From owner-linux-xfs@oss.sgi.com Sun Sep 17 15:26:10 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 15:26:00 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:20241 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 15:25:53 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA11762; Sun, 17 Sep 2000 15:18:12 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA78882; Sun, 17 Sep 2000 15:25:52 -0700 (PDT) Date: Sun, 17 Sep 2000 15:25:52 -0700 (PDT) Message-Id: <200009172225.PAA78882@info.engr.sgi.com> X-Pv-Incident: 802017 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: REASSIGN 802017 - ASSERT fail in xlog_get_bp on small mem machine To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017 Status : open Priority : 3 *Assigned Engineer : dxm *Assigned Domain : engr Submitter : dxm Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/17/00 *Modified User : dxm *Modified User Domain : engr *Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: dxm@engr (BugWorks) Date: Sep 17 2000 03:25:51PM ========================== Reassigning to me but up for grabs. I guess I should make it clearer that the ASSERT in xlog_get_bp fails due to XFS_ngetrbuf returning a NULL buffer because it can't score enough memory. From owner-linux-xfs@oss.sgi.com Sun Sep 17 17:04:22 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 17:04:12 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:37060 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 17:03:55 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id TAA28601; Sun, 17 Sep 2000 19:03:52 -0500 (CDT) Date: Sun, 17 Sep 2000 19:03:52 -0500 (CDT) Message-Id: <200009180003.TAA28601@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com cc: jones@spica.cc.utexas.edu Subject: put_inode patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The following is a share file that contains patchs to xfs_ioctl.c, xfs_iops.c, xfs_super.c and xfs_vnode.c in fs/xfs/linux. The patchs removes the use of the dentry_operations d_iput and replaces it with the super_operations put_inode. Bill Jones ------------------------------------------------------------------------------------- #!/bin/sh # This is a shell archive (produced by GNU sharutils 4.2). # To extract the files from this archive, save it to some FILE, remove # everything before the `!/bin/sh' line above, then type `sh FILE'. # # Made on 2000-09-17 18:51 CDT by . # Source directory was `/usr/src/xfs/xfs/linux/fs/xfs/linux'. # # Existing files will *not* be overwritten unless `-c' is specified. # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 278 -rw-r--r-- xfs_ioctl.c.patch # 2190 -rw-r--r-- xfs_iops.c.patch # 704 -rw-r--r-- xfs_super.c.patch # 1701 -rw-r--r-- xfs_vnode.c.patch # save_IFS="${IFS}" IFS="${IFS}:" gettext_dir=FAILED locale_dir=FAILED first_param="$1" for dir in $PATH do if test "$gettext_dir" = FAILED && test -f $dir/gettext \ && ($dir/gettext --version >/dev/null 2>&1) then set `$dir/gettext --version 2>&1` if test "$3" = GNU then gettext_dir=$dir fi fi if test "$locale_dir" = FAILED && test -f $dir/shar \ && ($dir/shar --print-text-domain-dir >/dev/null 2>&1) then locale_dir=`$dir/shar --print-text-domain-dir` fi done IFS="$save_IFS" if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED then echo=echo else TEXTDOMAINDIR=$locale_dir export TEXTDOMAINDIR TEXTDOMAIN=sharutils export TEXTDOMAIN echo="$gettext_dir/gettext -s" fi if mkdir _sh00752; then $echo 'x -' 'creating lock directory' else $echo 'failed to create lock directory' exit 1 fi # ============= xfs_ioctl.c.patch ============== if test -f 'xfs_ioctl.c.patch' && test "$first_param" != -c; then $echo 'x -' SKIPPING 'xfs_ioctl.c.patch' '(file already exists)' else $echo 'x -' extracting 'xfs_ioctl.c.patch' '(text)' sed 's/^X//' << 'SHAR_EOF' > 'xfs_ioctl.c.patch' && *** xfs_ioctl.c.orig Sun Sep 17 00:10:08 2000 --- xfs_ioctl.c Sun Sep 17 00:10:25 2000 *************** *** 448,454 **** X put_unused_fd(new_fd); X return -XFS_ERROR(ENOMEM); X } - linvfs_set_dentry_ops(dentry); X X /* X * Keep nfsd happy. --- 448,453 ---- SHAR_EOF chmod 0644 'xfs_ioctl.c.patch' || $echo 'restore of' 'xfs_ioctl.c.patch' 'failed' if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \ && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then md5sum -c << SHAR_EOF >/dev/null 2>&1 \ || $echo 'xfs_ioctl.c.patch:' 'MD5 check failed' b6d9297a64ffacd36070d809b8a7f548 xfs_ioctl.c.patch SHAR_EOF else shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'xfs_ioctl.c.patch'`" test 278 -eq "$shar_count" || $echo 'xfs_ioctl.c.patch:' 'original size' '278,' 'current size' "$shar_count!" fi fi # ============= xfs_iops.c.patch ============== if test -f 'xfs_iops.c.patch' && test "$first_param" != -c; then $echo 'x -' SKIPPING 'xfs_iops.c.patch' '(file already exists)' else $echo 'x -' extracting 'xfs_iops.c.patch' '(text)' sed 's/^X//' << 'SHAR_EOF' > 'xfs_iops.c.patch' && *** xfs_iops.c.orig Sun Sep 17 00:17:28 2000 --- xfs_iops.c Sun Sep 17 13:06:59 2000 *************** *** 87,104 **** X X #include /* For copy_from_user */ X - static struct dentry_operations linvfs_dops; - - /* - * assign dentry ops to a dentry to prevent reference leak on dput - */ - - void - linvfs_set_dentry_ops(struct dentry *dentry) - { - ASSERT(dentry); - dentry->d_op = &linvfs_dops; - } X X /* X * Pull the link count and size up from the xfs inode to the linux inode --- 87,92 ---- *************** *** 175,181 **** X linvfs_set_inode_ops(ip); X error = linvfs_revalidate_core(ip); X validate_fields(dir); - linvfs_set_dentry_ops(dentry); X d_instantiate(dentry, ip); X } X --- 163,168 ---- *************** *** 222,228 **** X VN_RELE(cvp); X return ERR_PTR(-EACCES); X } - linvfs_set_dentry_ops(dentry); X linvfs_set_inode_ops(ip); X error = linvfs_revalidate_core(ip); X } --- 209,214 ---- *************** *** 254,260 **** X ip->i_ctime = CURRENT_TIME; X VN_HOLD(vp); X validate_fields(ip); - linvfs_set_dentry_ops(dentry); X d_instantiate(dentry, ip); X } X return -error; --- 240,245 ---- *************** *** 325,331 **** X } else { X linvfs_set_inode_ops(ip); X error = linvfs_revalidate_core(ip); - linvfs_set_dentry_ops(dentry); X d_instantiate(dentry, ip); X } X } --- 310,315 ---- *************** *** 918,939 **** X } X } X - /* This is used to wrap iput calls from above the vfs layer, we can - * add our own locking to kill races between xfs_iget and iput. - */ - - STATIC - void linvfs_d_iput(struct dentry *dentry, struct inode *inode) - { - vnode_t *vp = LINVFS_GET_VP(inode); - - if (vp) { - vn_rele(vp); - } else { - iput(inode); - } - } - X X struct address_space_operations linvfs_aops = { X readpage: linvfs_read_full_page, --- 902,907 ---- *************** *** 990,999 **** X attr_set: linvfs_attr_set, X attr_remove: linvfs_attr_remove, X attr_list: linvfs_attr_list, - }; - - static struct dentry_operations linvfs_dops = - { - d_iput: linvfs_d_iput, X }; X --- 958,962 ---- SHAR_EOF chmod 0644 'xfs_iops.c.patch' || $echo 'restore of' 'xfs_iops.c.patch' 'failed' if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \ && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then md5sum -c << SHAR_EOF >/dev/null 2>&1 \ || $echo 'xfs_iops.c.patch:' 'MD5 check failed' 0d5e2b5e78d82eb60968e7d91022f28a xfs_iops.c.patch SHAR_EOF else shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'xfs_iops.c.patch'`" test 2190 -eq "$shar_count" || $echo 'xfs_iops.c.patch:' 'original size' '2190,' 'current size' "$shar_count!" fi fi # ============= xfs_super.c.patch ============== if test -f 'xfs_super.c.patch' && test "$first_param" != -c; then $echo 'x -' SKIPPING 'xfs_super.c.patch' '(file already exists)' else $echo 'x -' extracting 'xfs_super.c.patch' '(text)' sed 's/^X//' << 'SHAR_EOF' > 'xfs_super.c.patch' && *** xfs_super.c.orig Sun Sep 17 00:16:16 2000 --- xfs_super.c Sun Sep 17 15:38:41 2000 *************** *** 426,431 **** --- 426,438 ---- X } X } X + void + linvfs_put_inode(struct inode *inode) + { + void vn_put_inode(struct inode *); /* fix me put me in a header */ + + vn_put_inode(inode); + } X X void X linvfs_put_super( *************** *** 598,608 **** --- 604,616 ---- X X X + X static struct super_operations linvfs_sops = { X read_inode: linvfs_read_inode, X #ifdef CONFIG_XFS_VNODE_TRACING X write_inode: linvfs_write_inode, X #endif + put_inode: linvfs_put_inode, X delete_inode: linvfs_delete_inode, X clear_inode: linvfs_clear_inode, X put_super: linvfs_put_super, SHAR_EOF chmod 0644 'xfs_super.c.patch' || $echo 'restore of' 'xfs_super.c.patch' 'failed' if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \ && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then md5sum -c << SHAR_EOF >/dev/null 2>&1 \ || $echo 'xfs_super.c.patch:' 'MD5 check failed' 2ab9e8ecc3e86494b6005875bf3acdf5 xfs_super.c.patch SHAR_EOF else shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'xfs_super.c.patch'`" test 704 -eq "$shar_count" || $echo 'xfs_super.c.patch:' 'original size' '704,' 'current size' "$shar_count!" fi fi # ============= xfs_vnode.c.patch ============== if test -f 'xfs_vnode.c.patch' && test "$first_param" != -c; then $echo 'x -' SKIPPING 'xfs_vnode.c.patch' '(file already exists)' else $echo 'x -' extracting 'xfs_vnode.c.patch' '(text)' sed 's/^X//' << 'SHAR_EOF' > 'xfs_vnode.c.patch' && *** xfs_vnode.c.orig Sun Sep 17 00:15:31 2000 --- xfs_vnode.c Sun Sep 17 15:39:06 2000 *************** *** 583,600 **** X return vp; X } X - X /* ! * Release a vnode. Decrements reference count and calls ! * VOP_INACTIVE on last reference. X */ X void X vn_rele(struct vnode *vp) X { X int s; X int vcnt; X /* REFERENCED */ X int cache; X X XFS_STATS_INC(vn_rele); X --- 583,617 ---- X return vp; X } X X /* ! * Release a vnode. X */ X void X vn_rele(struct vnode *vp) X { + iput(LINVFS_GET_IP(vp)); + + } + + /* + * Call VOP_INACTIVE on last reference. + */ + void + vn_put_inode(struct inode *inode) + { X int s; X int vcnt; X /* REFERENCED */ X int cache; + struct vnode *vp; + + vp = vn_address(inode); + + /* + * If we were given a bum vnode just return. + * (This will happen on an umount.) + */ + if(vp == NULL) return; X X XFS_STATS_INC(vn_rele); X *************** *** 607,615 **** X ASSERT(vcnt > 0); X X /* ! * Note that we are allowing for the fact that the ! * i_count won't be decremented until we do the ! * 'iput' below. X */ X if (vcnt == 1) { X /* --- 624,632 ---- X ASSERT(vcnt > 0); X X /* ! * Since we always get called from put_inode we know ! * that i_count won't be decremented after we ! * return. X */ X if (vcnt == 1) { X /* *************** *** 638,655 **** X X vp->v_flag &= ~(VINACT|VWAIT|VRECLM|VGONE); X - vn_trace_exit(vp, "vn_rele", (inst_t *)__return_address); - - VN_UNLOCK(vp, s); - - iput(LINVFS_GET_IP(vp)); - - return; X } X X VN_UNLOCK(vp, s); - - iput(LINVFS_GET_IP(vp)); X X vn_trace_exit(vp, "vn_rele", (inst_t *)__return_address); X } --- 655,663 ---- SHAR_EOF chmod 0644 'xfs_vnode.c.patch' || $echo 'restore of' 'xfs_vnode.c.patch' 'failed' if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \ && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then md5sum -c << SHAR_EOF >/dev/null 2>&1 \ || $echo 'xfs_vnode.c.patch:' 'MD5 check failed' 30a63d1de11fd54646f3c87c67ef695a xfs_vnode.c.patch SHAR_EOF else shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'xfs_vnode.c.patch'`" test 1701 -eq "$shar_count" || $echo 'xfs_vnode.c.patch:' 'original size' '1701,' 'current size' "$shar_count!" fi fi rm -fr _sh00752 exit 0 From owner-linux-xfs@oss.sgi.com Sun Sep 17 17:51:33 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 17:51:22 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:59420 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 17:50:54 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA18411; Sun, 17 Sep 2000 17:42:43 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA21385; Sun, 17 Sep 2000 17:50:23 -0700 (PDT) Date: Sun, 17 Sep 2000 17:50:23 -0700 (PDT) Message-Id: <200009180050.RAA21385@info.engr.sgi.com> X-Pv-Incident: 802021 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 802021 - hang in _pagebuf_find_lockable_buffer To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802021 Submitter : nathans Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 1 Project : xfs-linux Status : open Description : An XFS qa run hung my desktop machine over the weekend. This was using the top-of-tree source as of Sunday morning (localtime) - I don't think anything has been checked in since - in qa test number 013 (fsstress). The machine was responsive to ping, but not to telnet/rlogin, the kernel backtrace was as follows... Entering kdb (current=0xc4622000, pid 5038) due to Keyboard Entry kdb> bt EBP EIP Function(args) 0xc4623a1c 0xc0175976 _pagebuf_find_lockable_buffer+0x1c2 (0xc5aa80e0, 0xc5aa6200, 0x8000, 0x0, 0x2000) kernel .text 0xc0100000 0xc01757b4 0xc0175990 0xc4623a50 0xc01759ba _pagebuf_get_lockable_buffer+0x2a (0xc5aa80e0, 0xc5aa6200, 0x8000, 0x0, 0x2000) kernel .text 0xc0100000 0xc0175990 0xc0175a48 0xc4623a94 0xc017143f pagebuf_get+0x10b (0xc5aa80e0, 0x8000, 0x0, 0x2000, 0x2201) kernel .text 0xc0100000 0xc0171334 0xc017154c 0xc4623ac4 0xc01d45b0 xfs_trans_read_buf+0x48 (0xc5fa8800, 0x0, 0xc5fa8964, 0x40, 0x0) kernel .text 0xc0100000 0xc01d4568 0xc01d4af0 0xc4623b24 0xc01b6fff xfs_itobp+0x133 (0xc5fa8800, 0x0, 0xc43b6930, 0xc4623bec, 0xc4623bf0) kernel .text 0xc0100000 0xc01b6ecc 0xc01b7154 0xc4623c10 0xc01be777 xfs_bulkstat+0x87f (0xc5fa8800, 0x0, 0xc4623c9c, 0xc4623c94, 0xc01bd9b0) kernel .text 0xc0100000 0xc01bdef8 0xc01bea74 0xc4623f6c 0xc01e54f0 xfs_ioctl+0x540 (0xc1a590b8, 0xc34fa360, 0xc4e798a0, 0xc0105865, 0xbffffb14) kernel .text 0xc0100000 0xc01e4fb0 0xc01e5ea0 0xc4623f90 0xc01e4422 linvfs_ioctl+0x56 (0xc34fa360, 0xc4e798a0, 0xc0105865, 0xbffffb14, 0xc4622000) kernel .text 0xc0100000 0xc01e43cc 0xc01e442c 0xc4623fbc 0xc0136cf4 sys_ioctl+0x174 (0x3, 0xc0105865, 0xbffffb14, 0xbffffb34, 0xbffffc74) kernel .text 0xc0100000 0xc0136b80 0xc0136d10 0xc0108e28 system_call+0x34 kernel .text 0xc0100000 0xc0108df4 0xc0108e2c kdb> kdb> rd eax = 0x00000000 ebx = 0xc46239bc ecx = 0x00002000 edx = 0x0000a000 esi = 0xc3ff4e40 edi = 0xc46239c0 esp = 0xc4623994 eip = 0xc0175976 ebp = 0xc4623a1c ss = 0x00000018 cs = 0x00000010 eflags = 0x00000207 ds = 0xc4620018 es = 0xc0170018 origeax = 0xffffff01 ®s = 0xc4623960 kdb> id 0xc0175976 0xc0175976 _pagebuf_find_lockable_buffer+0x1c2: movl 0x20(%ebp),%ecx 0xc0175979 _pagebuf_find_lockable_buffer+0x1c5: movl $0x0,(%ecx) 0xc017597f _pagebuf_find_lockable_buffer+0x1cb: nop 0xc0175980 _pagebuf_find_lockable_buffer+0x1cc: xorl %eax,%eax 0xc0175982 _pagebuf_find_lockable_buffer+0x1ce: leal 0xffffff78(%ebp),%esp 0xc0175988 _pagebuf_find_lockable_buffer+0x1d4: popl %ebx 0xc0175989 _pagebuf_find_lockable_buffer+0x1d5: popl %esi 0xc017598a _pagebuf_find_lockable_buffer+0x1d6: popl %edi 0xc017598b _pagebuf_find_lockable_buffer+0x1d7: movl %ebp,%esp 0xc017598d _pagebuf_find_lockable_buffer+0x1d9: popl %ebp 0xc017598e _pagebuf_find_lockable_buffer+0x1da: ret 0xc017598f _pagebuf_find_lockable_buffer+0x1db: nop 0xc0175990 _pagebuf_get_lockable_buffer: pushl %ebp 0xc0175991 _pagebuf_get_lockable_buffer+0x1: movl %esp,%ebp 0xc0175993 _pagebuf_get_lockable_buffer+0x3: subl $0x4,%esp 0xc0175996 _pagebuf_get_lockable_buffer+0x6: pushl %edi kdb> From owner-linux-xfs@oss.sgi.com Sun Sep 17 22:17:35 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 22:17:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:55 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 22:16:54 -0700 Received: from feature.engr.sgi.com (feature.engr.sgi.com [130.62.40.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA01935; Sun, 17 Sep 2000 22:08:42 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id WAA26898; Sun, 17 Sep 2000 22:15:04 -0700 (PDT) Date: Sun, 17 Sep 2000 22:15:04 -0700 (PDT) Message-Id: <200009180515.WAA26898@feature.engr.sgi.com> X-Pv-Incident: 801764 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (nathans@engr.sgi.com) Subject: TAKE 801764 - xfs_check and xfs_repair should fail if device mounted To: nathans@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : dxm *Status : closed Assigned Engineer : nathans *Fixed By : nathans *Fixed By Domain : engr *Closed Date : 09/17/00 Priority : 4 *Modified Date : 09/17/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : From: nathan scott (TAKE) Date: Sep 17 2000 10:15:04PM [pvnews version: 1.71] ---------------------------- Got the green light for this to go into beta. Also rolled the version number for xfs-cmds to 1.0.5 for official beta. Modid: 2.4.0-test1-xfs:slinx:74557a Date: Sun Sep 17 22:09:48 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/CHANGELOG - 1.5 - document change to version number for beta. cmd/xfs/VERSION - 1.6 - change version number for beta. cmd/xfs/db/init.c - 1.28 - fix inappropriate use of usage() after library init() failure. cmd/xfs/db/xfs_check.sh - 1.5 cmd/xfs/db/xfs_check64.sh - 1.3 - don't allow check to run on mounted filesystems. cmd/xfs/include/libxfs.h - 1.15 cmd/xfs/libxfs/init.c - 1.11 cmd/xfs/logprint/logprint.c - 1.47 - add libxfs_ismounted for checking whether device is mounted. cmd/xfs/repair/init.c - 1.13 - don't allow repair -n to run on mounted filesystems. Description : both "xfs_check" and "xfs_repair -n" may be run on a mounted filesystem and will usually produce lots of warnings about filesystem corruption due to the inconsistent state the FS is in. Both tools should fail or at least warn that the FS is mounted before proceeding. xfs_logprint should also warn when run on a mounted FS, but can still be useful when mounted. ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: nathans@engr (BugWorks) Date: Sep 14 2000 07:05:49PM ========================== hi, I have a (trivial) fix which does this: $ logprint/xfs_logprint /dev/hda5 xfs_logprint: /dev/hda5 contains a mounted filesystem ...[carries on]... $ sh db/xfs_check.sh /dev/hda5 xfs_check: /dev/hda5 contains a mounted filesystem fatal error -- couldn't initialize XFS library [exit] $ sudo repair/xfs_repair -n /dev/hda6 xfs_repair: /dev/hda6 contains a mounted filesystem fatal error -- couldn't initialize XFS library [exit] for the folks cloning the tree - is this a beta candidate, or shall I wait and check in the change later? many thanks. From owner-linux-xfs@oss.sgi.com Sun Sep 17 23:10:46 2000 Received: by oss.sgi.com id ; Sun, 17 Sep 2000 23:10:36 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24668 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 17 Sep 2000 23:10:10 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA08394; Sun, 17 Sep 2000 23:16:15 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA67923; Sun, 17 Sep 2000 23:09:29 -0700 (PDT) Date: Sun, 17 Sep 2000 23:09:29 -0700 (PDT) Message-Id: <200009180609.XAA67923@info.engr.sgi.com> X-Pv-Incident: 801764 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: REOPEN 801764 - xfs_check and xfs_repair should fail if device mounted To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801764 *Status : open Priority : 4 Assigned Engineer : nathans Submitter : dxm Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/13/00 *Closed Date : *Fixed By : *Fixed By Domain : *Verified Date : *Modified User : nathans *Modified User Domain : engr *Description : both "xfs_check" and "xfs_repair -n" may be run on a mounted filesystem and will usually produce lots of warnings about filesystem corruption due to the inconsistent state the FS is in. Both tools should fail or at least warn that the FS is mounted before proceeding. xfs_logprint should also warn when run on a mounted FS, but can still be useful when mounted. ..... ========================== ADDITIONAL INFORMATION (REOPEN) From: nathans@engr (BugWorks) Date: Sep 17 2000 11:09:28PM ========================== I've backed this fix out... it works but is too simplistic an approach for the general case. We should allow these tools to run on a filesystem which is mounted read-only - this change currently disallows _all_ mounted filesystems, which is too strict. From owner-linux-xfs@oss.sgi.com Mon Sep 18 07:43:30 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 07:43:20 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:2942 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 07:42:50 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA07735; Mon, 18 Sep 2000 07:34:28 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA34591; Mon, 18 Sep 2000 07:42:08 -0700 (PDT) Date: Mon, 18 Sep 2000 07:42:08 -0700 (PDT) Message-Id: <200009181442.HAA34591@info.engr.sgi.com> X-Pv-Incident: 802017 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 802017 - ASSERT fail in xlog_get_bp on small mem machine To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017 Status : open Priority : 3 Assigned Engineer : dxm Submitter : dxm *Modified User : lord *Modified User Domain : sgi.com *Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 18 2000 07:42:08AM ========================== Ideally we do need a better way for recovery to run without chewing up large chunks of memory. Without looking at the code I bet this is the case where we are asking for a 128K buffer to read log space into. This is actually half the amount which Irix would use at this point. A single buffer is requested which would cover the maximum number of iclogs * the max size of an iclog. On Irix we can have 8 32K byte iclogs, on Linux this was reduced to 4. So what we really need here is a change in the algorithm used in xlog_find_zeroed() so that disk I/O can be done in smaller chunks rather than reading one large chunk and processing it. An interim fix would be to make the mount fail cleanly. From owner-linux-xfs@oss.sgi.com Mon Sep 18 07:58:50 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 07:58:40 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10616 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 07:58:08 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA00550 for ; Mon, 18 Sep 2000 08:04:21 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA08555; Mon, 18 Sep 2000 09:56:16 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA92987; Mon, 18 Sep 2000 09:56:16 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id JAA32353; Mon, 18 Sep 2000 09:53:18 -0500 Message-Id: <200009181453.JAA32353@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "William L. Jones" cc: lord@sgi.com, linux-xfs@oss.sgi.com Subject: Re: Just a small reminder Date: Mon, 18 Sep 2000 09:53:13 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The real problem here is that two threads can end up attempting to manipulate inode state based on the reference count crossing through 1. What we actually need is synchronization between these threads. Based on the code after your patch: Consider vn_hold - which wraps around igrab and vn_rele which calls iput and ends up in vn_put_inode. These both manipulate the inode count. A thread doing a vn_hold racing with a thread in vn_put_inode will block whilst vn_put_inode is checking the hold count. But once we release the lock in the vnode and call xfs_inactive the vn_hold will continue and bump the count. So we now have one thread doing the inactive processing and another thread bumping the hold count. If this was an unlinked inode then inactive will start the work of removing it from the disk. At the same time the thread doing the vn_hold will carry on using the inode, this is bad. The code currently in the tree does have a similar race in it - I am not sure yet if it is a narrower window than with your patch, it survives a dbench load of 100, I will test the patch which will help the NFS server end of things. There is still work to do on this either way, and trying to do this without modifying iput is non-trivial to say the least. Steve From owner-linux-xfs@oss.sgi.com Mon Sep 18 09:04:51 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 09:04:41 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:58081 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 09:04:12 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id LAA07529; Mon, 18 Sep 2000 11:03:22 -0500 (CDT) Message-Id: <4.2.0.58.20000918110228.00a21780@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 18 Sep 2000 11:05:36 -0500 To: Steve Lord , "William L. Jones" From: "William L. Jones" Subject: Re: Just a small reminder Cc: lord@sgi.com, linux-xfs@oss.sgi.com In-Reply-To: <200009181453.JAA32353@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thanks for taking a look! I suspect that you may have to reach into the inode.c to really fix the problem. The mod I gave you has all the same problem as the d_iput method but it will help with nfsd issue. Bill Jones At 09:53 AM 9/18/00 -0500, Steve Lord wrote: >The real problem here is that two threads can end up attempting to manipulate >inode state based on the reference count crossing through 1. What we actually >need is synchronization between these threads. > >Based on the code after your patch: > >Consider vn_hold - which wraps around igrab and vn_rele which calls iput >and ends up in vn_put_inode. These both manipulate the inode count. > >A thread doing a vn_hold racing with a thread in vn_put_inode will block >whilst >vn_put_inode is checking the hold count. But once we release the lock in the >vnode and call xfs_inactive the vn_hold will continue and bump the count. > >So we now have one thread doing the inactive processing and another thread >bumping the hold count. If this was an unlinked inode then inactive will start >the work of removing it from the disk. At the same time the thread doing the >vn_hold will carry on using the inode, this is bad. > >The code currently in the tree does have a similar race in it - I am not sure >yet if it is a narrower window than with your patch, it survives a dbench load >of 100, I will test the patch which will help the NFS server end of things. > >There is still work to do on this either way, and trying to do this without >modifying iput is non-trivial to say the least. > >Steve > From owner-linux-xfs@oss.sgi.com Mon Sep 18 12:21:22 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 12:21:12 -0700 Received: from rf-mail1.echostar.com ([205.172.144.40]:47882 "EHLO rf-exch2.echostar.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 12:21:03 -0700 Received: from echostar.com (linux10.echostar.com [172.20.50.110]) by rf-exch2.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SYW4AND0; Mon, 18 Sep 2000 13:20:44 -0600 Message-ID: <39C66B11.E477FD4F@echostar.com> Date: Mon, 18 Sep 2000 13:20:49 -0600 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-test6 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Making holes were data used to be or head trunc. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing How can I make holes where there is currently data with XFS? Can I lop off the front of a file easily? Thanks, Ian Nelson From owner-linux-xfs@oss.sgi.com Mon Sep 18 12:31:22 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 12:31:12 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2844 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 12:30:50 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA00254 for ; Mon, 18 Sep 2000 12:37:35 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA08852; Mon, 18 Sep 2000 14:29:32 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA23400; Mon, 18 Sep 2000 14:29:32 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id OAA07020; Mon, 18 Sep 2000 14:26:32 -0500 Message-Id: <200009181926.OAA07020@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: ian.nelson@echostar.com cc: "linux-xfs@oss.sgi.com" Subject: Re: Making holes were data used to be or head trunc. In-Reply-To: Message from "Ian S. Nelson" of "Mon, 18 Sep 2000 13:20:49 MDT." <39C66B11.E477FD4F@echostar.com> Date: Mon, 18 Sep 2000 14:26:32 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > How can I make holes where there is currently data with XFS? > > Can I lop off the front of a file easily? > > Thanks, > Ian Nelson There is an ioctl to unreserve space in a file from a file. This part of XFS has not had much exposure and is known to have problems when there is data still present in buffers which overlaps the place a hole is being created. XFS_IOC_FREESP is the ioctl code, include/linux/xfs_fs.h defines the types and ioctl codes for this. Here is an extract from the irix man page, I do not think we have any documentation for this on Linux right now (so this is not correct when it comes to type names and header files). F_FREESP Alter storage space associated with a section of the ordinary file fildes. The section is specified by a variable of data type struct flock pointed to by the third argument arg. The data type struct flock is defined in the header file [see fcntl(5)] and contains the following members: l_whence is 0, 1, or 2 to indicate that the relative offset l_start will be measured from the start of the file, the current position, or the end of the file, respectively. l_start is the offset from the position specified in l_whence. l_len is the size of the section. An l_len of 0 frees up to the end of the file; in this case, the end of file (i.e., file size) is set to the beginning of the section freed. Any data previously written into this section is no longer accessible. If the section specified is beyond the current end of file, the file is grown and filled with zeroes. The l_len field is currently ignored, and should be set to 0. The structure you would pass in would be of type xfs_flock64 Steve From owner-linux-xfs@oss.sgi.com Mon Sep 18 14:02:02 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 14:01:52 -0700 Received: from [134.6.67.21] ([134.6.67.21]:46854 "EHLO mcoexc03.mlm.maxtor.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 14:01:33 -0700 Received: by mcoexc03.mlm.maxtor.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 15:02:32 -0600 Message-ID: <09D1E9BD9C30D311919200A0C9DD5C2C02536FAA@mcaexc01.msj.maxtor.com> From: "Davida, Joe" To: "'linux-xfs@oss.sgi.com'" Subject: Benchmark test Suites Date: Mon, 18 Sep 2000 14:59:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Looking for Linux XFS benchmark test suites. Also, planning to purchase a MIPS machine pre-installed with Linux 2.4 and latest XFS. Any idea on vendors, prices? Configurations? Cheers, Joe From owner-linux-xfs@oss.sgi.com Mon Sep 18 14:29:42 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 14:29:32 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5164 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 14:29:21 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA09067 for ; Mon, 18 Sep 2000 14:36:06 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA58634; Mon, 18 Sep 2000 14:24:08 -0700 (PDT) Message-ID: <39C68972.A69F1F61@sgi.com> Date: Mon, 18 Sep 2000 14:30:26 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Davida, Joe" CC: "'linux-xfs@oss.sgi.com'" Subject: Re: Benchmark test Suites References: <09D1E9BD9C30D311919200A0C9DD5C2C02536FAA@mcaexc01.msj.maxtor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Davida, Joe" wrote: > > Looking for Linux XFS benchmark test suites. We usually run things like bonnie, lmdd and dbench; all of these are available on the web ... -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Sep 18 14:32:12 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 14:32:03 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:57211 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 14:31:56 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA03648 for ; Mon, 18 Sep 2000 14:24:12 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id QAA99560; Mon, 18 Sep 2000 16:30:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id QAA37014; Mon, 18 Sep 2000 16:30:36 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id QAA07616; Mon, 18 Sep 2000 16:27:36 -0500 Message-Id: <200009182127.QAA07616@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Davida, Joe" cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Benchmark test Suites In-Reply-To: Message from "Davida, Joe" of "Mon, 18 Sep 2000 14:59:45 MDT." <09D1E9BD9C30D311919200A0C9DD5C2C02536FAA@mcaexc01.msj.maxtor.com> Date: Mon, 18 Sep 2000 16:27:35 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Looking for Linux XFS benchmark test suites. We use stuff like aim, dbench, bonnie++, lmbench the latter three are certainly out on the web - look at www.freshmeat.net for locations. I am not sure on the status of aim - the company which developed it is gone, but the code is probably not open source. A side note on this is that we are not done with performance on xfs yet, and with the introduction of a new VM into 2.4.0-test9 things will have to change. > > Also, planning to purchase a MIPS machine pre-installed > with Linux 2.4 and latest XFS. Any idea on vendors, > prices? Configurations? Off the top of my head the only people I can think of selling Mips Linux boxes is cobalt. These are not a generic system at all, but there are almost certainly others. I doubt anyone is selling a 2.4 based system - there are a couple of distributions which have put out betas with an option of installing 2.4. We use redhat 6.2 here and you do not have to upgrade much to use 2.4 - see the Changes file in the kernel Documentation directory. I know no one is distributing machines with XFS on Linux. Also, we have not done any testing of Linux XFS on Mips beyond booting on an SGI platform and looking at a couple of filesystems. Steve > > Cheers, > > Joe From owner-linux-xfs@oss.sgi.com Mon Sep 18 15:24:13 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 15:24:03 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:50959 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 15:23:53 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA11723 for ; Mon, 18 Sep 2000 15:16:10 -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 JAA69562 for linux-xfs@oss.sgi.com; Tue, 19 Sep 2000 09:22:33 +1100 (EST) Date: Tue, 19 Sep 2000 09:22:33 +1100 (EST) From: Nathan Scott Message-Id: <200009182222.JAA69562@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing looks like the new kdb will be merged pre-beta, so i'll sneak this one-liner in now too. cheers. Modid: 2.4.0-test1-xfs:slinx:74604a Date: Mon Sep 18 15:20:32 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/kdb/modules/kdbm_pg.c - 1.18 - fix a typo in a string literal. From owner-linux-xfs@oss.sgi.com Mon Sep 18 15:46:42 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 15:46:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:14102 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 15:46:24 -0700 Received: from feature.engr.sgi.com (feature.engr.sgi.com [130.62.40.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA14811; Mon, 18 Sep 2000 15:38:41 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA56369; Mon, 18 Sep 2000 15:45:04 -0700 (PDT) Date: Mon, 18 Sep 2000 15:45:04 -0700 (PDT) Message-Id: <200009182245.PAA56369@feature.engr.sgi.com> X-Pv-Incident: 802017 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (dxm@melbourne.sgi.com) Subject: ADD 802017 - ASSERT fail in xlog_get_bp on small mem machine To: dxm@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : dxm Status : open Assigned Engineer : dxm Priority : 3 *Modified Date : 09/18/00 *Modified User : dxm *Modified User Domain : melbourne *Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, ..... ========================== ADDITIONAL INFORMATION (ADD) From: daniel moore Date: Sep 18 2000 03:45:04PM [pvnews version: 1.71] ========================== lord@sgi.com writes: => Ideally we do need a better way for recovery to run without => chewing up large chunks of memory. Without looking at the => code I bet this is the case where we are asking for a 128K => buffer to read log space into. This is actually half the amount => which Irix would use at this point. A single buffer is requested => which would cover the maximum number of iclogs * the max size of => an iclog. On Irix we can have 8 32K byte iclogs, on Linux this => was reduced to 4. Yep find_zeroed is asking for 128k. => => So what we really need here is a change in the algorithm used => in xlog_find_zeroed() so that disk I/O can be done in smaller => chunks rather than reading one large chunk and processing it. Other places in log_recover ask for buffers up to 128k too. => An interim fix would be to make the mount fail cleanly. That bit is easy. I actually hacked home copy last night so it uses single block reads and writes instead of using large buffers. This works ok, but I'm wondering if it would be worth the effort to change the code so it works with the largest buffer it can get. ie so if it can't get 128k, it tries for 64k and works with that etc... Would it be worth me checking in a change to make the mount fail cleanly for beta? From owner-linux-xfs@oss.sgi.com Mon Sep 18 16:14:22 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 16:14:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48698 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 16:14:12 -0700 Received: from kao1.melbourne.sgi.com (kao1.melbourne.sgi.com [134.14.55.179]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA04877 for ; Mon, 18 Sep 2000 16:20:56 -0700 (PDT) mail_from (kaos@kao1.melbourne.sgi.com) Received: (from kaos@localhost) by kao1.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA37584; Tue, 19 Sep 2000 10:11:35 +1100 (EST) Date: Tue, 19 Sep 2000 10:11:35 +1100 (EST) From: Keith Owens Message-Id: <200009182311.KAA37584@kao1.melbourne.sgi.com> To: sgi.bugs.slinx@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE - Upgrade xfs to kdb v1.4. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Upgrade xfs to kdb v1.4 Modid: 2.4.0-test1-xfs:slinx:74606a Date: Mon Sep 18 16:10:34 PDT 2000 Workarea: kao1.melbourne.sgi.com:/hosts/sherman/home/kaos/isms/slinx/2.4.0-test1-xfs Author: kaos The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/Documentation/Configure.help - 1.58 linux/Documentation/kdb/kdb.mm - 1.8 linux/Documentation/kdb/kdb_bt.man - 1.5 linux/arch/i386/config.in - 1.45 linux/arch/i386/kernel/traps.c - 1.25 linux/drivers/char/keyboard.c - 1.17 linux/drivers/char/serial.c - 1.30 linux/include/linux/kdb.h - 1.8 linux/include/linux/sysctl.h - 1.25 linux/init/main.c - 1.39 linux/kdb/kdb_bt.c - 1.5 linux/kdb/kdbmain.c - 1.10 linux/kernel/sysctl.c - 1.27 From owner-linux-xfs@oss.sgi.com Mon Sep 18 22:01:36 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 22:01:26 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3937 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 22:01:03 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA08376; Mon, 18 Sep 2000 22:07:49 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA80409; Mon, 18 Sep 2000 22:01:01 -0700 (PDT) Date: Mon, 18 Sep 2000 22:01:01 -0700 (PDT) Message-Id: <200009190501.WAA80409@info.engr.sgi.com> X-Pv-Incident: 802017 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 802017 - ASSERT fail in xlog_get_bp on small mem machine To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017 Status : open Priority : 3 Assigned Engineer : dxm Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 18 2000 10:01:00PM ========================== I'd quite like this workaround (it stops the crash and inevitable fsck) to get into the beta. Anyone want to rv this for me? (PS. I've also got an actual fix for the problem, but it's going to need some decent testing so it's not going to make beta). dxm@snort ~/isms/slinx-xfs-tot/linux/fs/xfs> p_rdiff -i xfs_log_recover.c 153c153,156 < ASSERT(bp); --- > if (!bp) > printk("XFS: Failed to allocate %d BB buffer for log recovery\n", > num_bblks); > 162c165 < } /* xlog_get_bp */ --- > } /* xlog_put_bp */ 415a419,420 > if (!bp) > return -ENOMEM; 497c502,507 < big_bp = xlog_get_bp(num_scan_bblks,log->l_mp); --- > big_bp = xlog_get_bp(num_scan_bblks,log->l_mp); > if (!big_bp) { > error = -ENOMEM; > goto bp_err; > } > 665a676,677 > if (!bp) > return -ENOMEM; 749a762,763 > if (!bp) > return -ENOMEM; 909a924,925 > if (!bp) > return -ENOMEM; 949a966,969 > if (!big_bp) { > error = -ENOMEM; > goto bp_err; > } 1114a1135,1136 > if (!bp) > return -ENOMEM; 3118a3141,3142 > if (!hbp) > return -ENOMEM; 3119a3144,3147 > if (!dbp) { > xlog_put_bp(hbp); > return -ENOMEM; > } From owner-linux-xfs@oss.sgi.com Tue Sep 19 05:51:41 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 05:51:31 -0700 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:31634 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 05:51:11 -0700 Received: from techno.informatik.uni-stuttgart.de (root@techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id OAA11451 for ; Tue, 19 Sep 2000 14:49:31 +0200 (MET DST) Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.9.3/2.2) id OAA11557 for linux-xfs@oss.sgi.com; Tue, 19 Sep 2000 14:51:08 +0200 Date: Tue, 19 Sep 2000 14:51:08 +0200 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Problem compiling xfs (SuSE, gcc 2.95.2-98) Message-ID: <20000919145108.A11456@techno.informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i X-Operating-System: Linux techno 2.2.13 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I'm trying to compile the kernel out of the CVS tree. I'm getting this: xfs_bmap.c:3254: internal error--unrecognizable insn: (insn/i 564 563 2232 (parallel[ (set (reg:SI 0 %eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("xfs_os_defs.h") 72)) (set (reg:SI 1 %edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("xfs_os_defs.h") 72)) ] ) -1 (insn_list 524 (nil)) (nil)) The compiler line is: gcc -D__KERNEL__ -I/home/magallon/proj/xfs/kernel/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fschedule-insns2 -mwide-multiply -fexpensive-optimizations -fno-strict-aliasing -g3 -Wno-unused -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xfs_bmap.o xfs_bmap.c Adding -fno-cse-skip-blocks allows the compilation to finish. Is some specific version of gcc needed to compile this? At home I run debian which includes at highly patched version of gcc (2.95.2 + CVS updates) but I've never ran into trouble using that to compile 2.4.x kernels, but I don't really know what SuSE includes... Perhaps someone here who knows his way arround gcc internals can shed some light into this? The part in question seems to be: static inline __u32 xfs_do_div(void *a, __u32 b, int n) { __u32 mod; switch (n) { case 4: mod = *(__u32 *)a % b; *(__u32 *)a = *(__u32 *)a / b; return mod; case 8: mod = do_div(*(__u64 *)a, b); return mod; } /* NOTREACHED */ return 0; } line 72 is the second "mod =". TIA, Marcelo From owner-linux-xfs@oss.sgi.com Tue Sep 19 06:26:41 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 06:26:30 -0700 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:39063 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 06:26:08 -0700 Received: from techno.informatik.uni-stuttgart.de (root@techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id PAA12221 for ; Tue, 19 Sep 2000 15:24:27 +0200 (MET DST) Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.9.3/2.2) id PAA15747 for linux-xfs@oss.sgi.com; Tue, 19 Sep 2000 15:26:04 +0200 Date: Tue, 19 Sep 2000 15:26:04 +0200 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: Problem compiling xfs (SuSE, gcc 2.95.2-98) Message-ID: <20000919152604.A15670@techno.informatik.uni-stuttgart.de> References: <20000919145108.A11456@techno.informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: <20000919145108.A11456@techno.informatik.uni-stuttgart.de>; from marcelo.magallon@bigfoot.com on Tue, Sep 19, 2000 at 02:51:08PM +0200 X-Operating-System: Linux techno 2.2.13 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >> "Marcelo E. Magallon" writes: > Adding -fno-cse-skip-blocks Oops, sorry, make that -fno-cse-follow-jumps Marcelo From owner-linux-xfs@oss.sgi.com Tue Sep 19 07:08:53 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 07:08:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:2376 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 07:08:26 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA06902; Tue, 19 Sep 2000 07:00:44 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA28127; Tue, 19 Sep 2000 07:08:24 -0700 (PDT) Date: Tue, 19 Sep 2000 07:08:24 -0700 (PDT) Message-Id: <200009191408.HAA28127@info.engr.sgi.com> X-Pv-Incident: 802017 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 802017 - ASSERT fail in xlog_get_bp on small mem machine To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017 Status : open Priority : 3 Assigned Engineer : dxm Submitter : dxm *Modified User : lord *Modified User Domain : sgi.com *Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 19 2000 07:08:24AM ========================== I would apply this - without the warning message which replaced the ASSERT, just return the NULL. The caller will report an ENOMEM error back to user space and the mount will fail. The other message is just extra noise. From owner-linux-xfs@oss.sgi.com Tue Sep 19 07:40:13 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 07:40:04 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:52998 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 07:39:45 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e8JEdba61505; Tue, 19 Sep 2000 09:39:38 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39C77AA8.20393935@thebarn.com> Date: Tue, 19 Sep 2000 09:39:36 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Marcelo E. Magallon" CC: linux-xfs@oss.sgi.com Subject: Re: Problem compiling xfs (SuSE, gcc 2.95.2-98) References: <20000919145108.A11456@techno.informatik.uni-stuttgart.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Marcelo E. Magallon" wrote: That compiler has known problems compiling XFS, there is also problems with the correctness of the code that is generated. At this time XFS should be compiled with egcs 2.91.66. > Hi, > > I'm trying to compile the kernel out of the CVS tree. I'm getting this: > > xfs_bmap.c:3254: internal error--unrecognizable insn: > (insn/i 564 563 2232 (parallel[ > (set (reg:SI 0 %eax) > (asm_operands ("") ("=a") 0[ > (reg:DI 1 %edx) > ] > [ > (asm_input:DI ("A")) > ] ("xfs_os_defs.h") 72)) > (set (reg:SI 1 %edx) > (asm_operands ("") ("=d") 1[ > (reg:DI 1 %edx) > ] > [ > (asm_input:DI ("A")) > ] ("xfs_os_defs.h") 72)) > ] ) -1 (insn_list 524 (nil)) > (nil)) > > The compiler line is: > > gcc -D__KERNEL__ -I/home/magallon/proj/xfs/kernel/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fschedule-insns2 -mwide-multiply -fexpensive-optimizations -fno-strict-aliasing -g3 -Wno-unused -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xfs_bmap.o xfs_bmap.c > > Adding -fno-cse-skip-blocks allows the compilation to finish. Is some > specific version of gcc needed to compile this? At home I run debian > which includes at highly patched version of gcc (2.95.2 + CVS updates) > but I've never ran into trouble using that to compile 2.4.x kernels, but > I don't really know what SuSE includes... > > Perhaps someone here who knows his way arround gcc internals can shed > some light into this? The part in question seems to be: > > static inline __u32 xfs_do_div(void *a, __u32 b, int n) > { > __u32 mod; > > switch (n) { > case 4: > mod = *(__u32 *)a % b; > *(__u32 *)a = *(__u32 *)a / b; > return mod; > case 8: > mod = do_div(*(__u64 *)a, b); > return mod; > } > > /* NOTREACHED */ > return 0; > } > > line 72 is the second "mod =". > > TIA, > > Marcelo -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Sep 19 11:18:24 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 11:18:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:55058 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 11:17:46 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA10536; Tue, 19 Sep 2000 11:10:04 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA22727; Tue, 19 Sep 2000 11:17:44 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA55724; Tue, 19 Sep 2000 11:16:27 -0700 (PDT) Date: Tue, 19 Sep 2000 11:16:27 -0700 (PDT) Message-Id: <200009191816.LAA55724@info.engr.sgi.com> X-Pv-Incident: 802204 webPV: jen.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: BUG 802204 - lilo does not work on XFS To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802204 Submitter : lord Submitter Domain : sgi.com Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : Running lilo to install a kernel from an xfs filesystem does not work. It generates a corrupt lilo map file - booting the system results in a prompt of LIL- and a hung machine which requires a rescue disk to get running again. Lilo installs some code in the boot area of a disk which is used to indicate where the kernel lives on disk. When running it uses the FIBMAP ioctl to determine the disk location of the kernel this is recorded into a map file. The location of the map file is then recorded into the boot area of the disk. The above error indicates a corrupted map file - in reading the file lilo reported problems. The ioctl does appear to be returning reasonable results to user space in that they increase as we move down the file in the normal case. I have not confirmed that they are actually correct though. From owner-linux-xfs@oss.sgi.com Tue Sep 19 15:19:05 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 15:18:55 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33854 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 15:18:31 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA06388; Tue, 19 Sep 2000 15:25:18 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA14634; Tue, 19 Sep 2000 15:18:29 -0700 (PDT) Date: Tue, 19 Sep 2000 15:18:29 -0700 (PDT) Message-Id: <200009192218.PAA14634@info.engr.sgi.com> X-Pv-Incident: 802017 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 802017 - ASSERT fail in xlog_get_bp on small mem machine To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017 Status : open Priority : 3 Assigned Engineer : dxm Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 19 2000 03:18:29PM ========================== Modid: 2.4.0-test1-xfs:slinx:74691a Date: Tue Sep 19 15:17:29 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-tot Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/xfs_log_recover.c - 1.189 - pv 802017 rv lord remove ASSERT in xlog_get_bp and check for NULL return instead. Not a solution to the problem, but at least we don't panic. From owner-linux-xfs@oss.sgi.com Tue Sep 19 16:13:45 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 16:13:35 -0700 Received: from Cantor.suse.de ([194.112.123.193]:57873 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Tue, 19 Sep 2000 16:13:23 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id CB7F21E305; Wed, 20 Sep 2000 01:13:21 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 9AF2E10A02D; Wed, 20 Sep 2000 01:13:21 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 165D32F300; Wed, 20 Sep 2000 01:13:16 +0200 (MEST) Date: Wed, 20 Sep 2000 01:13:16 +0200 From: "Andi Kleen" To: sgi.bugs.xfs@fido.engr.sgi.com Cc: nb@sgi.com, linux-xfs@oss.sgi.com Subject: Re: BUG 802204 - lilo does not work on XFS Message-ID: <20000920011316.A30535@gruyere.muc.suse.de> References: <200009191816.LAA55724@info.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200009191816.LAA55724@info.engr.sgi.com>; from pv@relay.sgi.com on Tue, Sep 19, 2000 at 11:16:27AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Sep 19, 2000 at 11:16:27AM -0700, lord@sgi.com wrote: > The ioctl does appear to be returning reasonable results to user > space in that they increase as we move down the file in the normal > case. I have not confirmed that they are actually correct though. The most likely problem is that they're simply in the wrong unit, the arithmetic in the macros linvfs_bmap uses to convert looks suspicious. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 19 16:16:45 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 16:16:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22371 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 16:16:25 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA19814; Tue, 19 Sep 2000 16:08:42 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA91045; Tue, 19 Sep 2000 16:15:04 -0700 (PDT) Date: Tue, 19 Sep 2000 16:15:04 -0700 (PDT) Message-Id: <200009192315.QAA91045@feature.engr.sgi.com> X-Pv-Incident: 802204 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (ak@suse.de.sgi.com) Subject: ADD 802204 - lilo does not work on XFS To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord Status : open Assigned Engineer : nb Priority : 2 *Modified Date : 09/19/00 *Modified User : ak *Modified User Domain : suse.de *Description : Running lilo to install a kernel from an xfs filesystem does not work. It generates a corrupt lilo map file - booting the system results in a prompt of LIL- and a hung machine which requires a rescue disk to get running again. Lilo installs some code in the boot area of a disk which is used to indicate where the kernel lives on disk. When running it uses the FIBMAP ioctl to determine the disk location of the kernel this is recorded into a map file. The location of the map file is then recorded into the boot area of the disk. ..... ========================== ADDITIONAL INFORMATION (ADD) From: "andi kleen" Date: Sep 19 2000 04:15:04PM [pvnews version: 1.71] ========================== On Tue, Sep 19, 2000 at 11:16:27AM -0700, lord@sgi.com wrote: > The ioctl does appear to be returning reasonable results to user > space in that they increase as we move down the file in the normal > case. I have not confirmed that they are actually correct though. The most likely problem is that they're simply in the wrong unit, the arithmetic in the macros linvfs_bmap uses to convert looks suspicious. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 19 18:14:45 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 18:14:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:28792 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 18:14:06 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA00444; Tue, 19 Sep 2000 18:06:24 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA84367; Tue, 19 Sep 2000 18:14:04 -0700 (PDT) Date: Tue, 19 Sep 2000 18:14:04 -0700 (PDT) Message-Id: <200009200114.SAA84367@info.engr.sgi.com> X-Pv-Incident: 802017 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 802017 - ASSERT fail in xlog_get_bp on small mem machine To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017 Status : open Priority : 3 Assigned Engineer : dxm Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 19 2000 06:14:03PM ========================== This patch removes the need for xfs_log_recover.c to allocate large buffers. All log access except for the actual recovery is done with single block reads and writes (the recovery uses 32k buffers, but these are used in normal XFS operation too). The largest allocation and read/write before was 256 blocks (128k). On most remounts, the code now does 256 writes and less than 300 reads. (I'd suggest that the simplicity of the code is an ok trade-off against the inefficiency) 33c33 < #ident "$Revision: 1.189 $" --- > #ident "$Revision: 1.188 $" 296a297 > 298,301c299,303 < xlog_find_verify_cycle(xfs_caddr_t *bap, /* update ptr as we go */ < xfs_daddr_t start_blk, < int nbblks, < uint stop_on_cycle_no) --- > xlog_find_verify_cycle( > xlog_t *log, > xfs_daddr_t start_blk, > int nbblks, > uint stop_on_cycle_no) 303,311c305,322 < int i; < uint cycle; < < for (i=0; i int i; > uint cycle; > xfs_buf_t *bp; > int error = 0; > > bp = xlog_get_bp(1, log->l_mp); > if (!bp) > return -ENOMEM; > > for (i=start_blk; i< start_blk + nbblks; i++) { > error = xlog_bread(log, i, 1, bp); > if (error) > goto out; > > cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT); > if (cycle == stop_on_cycle_no) { > error = i; > goto out; 314c325,331 < return -1; --- > > error = -1; > > out: > xlog_put_bp(bp); > > return error; 329a347 > 331c349,350 < xlog_find_verify_log_record(xfs_caddr_t ba, /* update ptr as we go */ --- > xlog_find_verify_log_record( > xlog_t *log, 336,337c355,358 < xlog_rec_header_t *rhead; < xfs_daddr_t i; --- > xfs_daddr_t i; > xfs_buf_t *bp; > xlog_rec_header_t *head; > int error = 0; 341c362,365 < ba -= BBSIZE; --- > bp = xlog_get_bp(1, log->l_mp); > if (!bp) > return -ENOMEM; > 347c371,372 < return XFS_ERROR(EIO); --- > error = XFS_ERROR(EIO); > goto out; 349c374,380 < if (INT_GET(*(uint *)ba, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) { --- > > error = xlog_bread(log, i, 1, bp); > if (error) > goto out; > head = (xlog_rec_header_t*)XFS_BUF_PTR(bp); > > if (INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) 351,352d381 < } < ba -= BBSIZE; 360,361c389,392 < if (i == -1) < return -1; --- > if (i == -1) { > error = -1; > goto out; > } 370,371c401,402 < rhead = (xlog_rec_header_t *)ba; < if (*last_blk - i + extra_bblks != BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT))+1) --- > if (*last_blk - i + extra_bblks > != BTOBB(INT_GET(head->h_len, ARCH_CONVERT))+1) 373c404,408 < return 0; --- > > out: > xlog_put_bp(bp); > > return error; 396c431 < xfs_buf_t *bp, *big_bp; --- > xfs_buf_t *bp; 401d435 < xfs_caddr_t ba; 498,503d531 < big_bp = xlog_get_bp(num_scan_bblks,log->l_mp); < if (!big_bp) { < error = -ENOMEM; < goto bp_err; < } < 510,513c538 < if (error = xlog_bread(log, start_blk, num_scan_bblks, big_bp)) < goto big_bp_err; < ba = XFS_BUF_PTR(big_bp); < new_blk = xlog_find_verify_cycle(&ba, start_blk, num_scan_bblks, --- > new_blk = xlog_find_verify_cycle(log, start_blk, num_scan_bblks, 545,549c570 < if (error = xlog_bread(log, start_blk, < num_scan_bblks-(int)head_blk, big_bp)) < goto big_bp_err; < ba = XFS_BUF_PTR(big_bp); < new_blk= xlog_find_verify_cycle(&ba, start_blk, --- > new_blk= xlog_find_verify_cycle(log, start_blk, 563,566c584 < if (error = xlog_bread(log, start_blk, (int) head_blk, big_bp)) < goto big_bp_err; < ba = XFS_BUF_PTR(big_bp); < new_blk = xlog_find_verify_cycle(&ba, start_blk, (int) head_blk, --- > new_blk = xlog_find_verify_cycle(log, start_blk, (int) head_blk, 580,581d597 < if (error = xlog_bread(log, start_blk, num_scan_bblks, big_bp)) < goto big_bp_err; 584,585c600 < ba = XFS_BUF_PTR(big_bp) + XLOG_MAX_RECORD_BSIZE; < if ((error = xlog_find_verify_log_record(ba, --- > if ((error = xlog_find_verify_log_record(log, 590c605 < goto big_bp_err; --- > goto bp_err; 592c607 < goto big_bp_err; --- > goto bp_err; 596,599c611 < if (error = xlog_bread(log, start_blk, (int)head_blk, big_bp)) < goto big_bp_err; < ba = XFS_BUF_PTR(big_bp) + BBTOB(head_blk); < if ((error = xlog_find_verify_log_record(ba, --- > if ((error = xlog_find_verify_log_record(log, 607,610d618 < if (error = xlog_bread(log, start_blk, log_bbnum - (int)start_blk, < big_bp)) < goto big_bp_err; < ba = XFS_BUF_PTR(big_bp) + BBTOB(log_bbnum - start_blk); 612c620 < if ((error = xlog_find_verify_log_record(ba, --- > if ((error = xlog_find_verify_log_record(log, 617c625 < goto big_bp_err; --- > goto bp_err; 619c627 < goto big_bp_err; --- > goto bp_err; 623c631 < goto big_bp_err; --- > goto bp_err; 626d633 < xlog_put_bp(big_bp); 640,641d646 < big_bp_err: < xlog_put_bp(big_bp); 910,911c915,916 < xfs_buf_t *bp, *big_bp; < uint first_cycle, last_cycle; --- > xfs_buf_t *bp; > uint first_cycle, last_cycle; 913,915c918,919 < xfs_daddr_t num_scan_bblks; < xfs_caddr_t ba; < int error, log_bbnum = log->l_logBBsize; --- > xfs_daddr_t num_scan_bblks; > int error, log_bbnum = log->l_logBBsize; 961,966d964 < big_bp = xlog_get_bp((int)num_scan_bblks,log->l_mp); < if (!big_bp) { < error = -ENOMEM; < goto bp_err; < } < ASSERT(big_bp); 971,975c969 < < if (error = xlog_bread(log, start_blk, (int)num_scan_bblks, big_bp)) < goto big_bp_err; < ba = XFS_BUF_PTR(big_bp); < --- > 982c976 < new_blk = xlog_find_verify_cycle(&ba, start_blk, --- > new_blk = xlog_find_verify_cycle(log, start_blk, 991,992c985,987 < if (error = xlog_find_verify_log_record(ba, start_blk, &last_blk, 0)) < goto big_bp_err; --- > if (error = xlog_find_verify_log_record(log, start_blk, > &last_blk, 0)) > goto bp_err; 995,996d989 < big_bp_err: < xlog_put_bp(big_bp); 1017,1018c1010 < int tail_block, < xfs_buf_t *bp) --- > int tail_block) 1022d1013 < int curr_block; 1023a1015,1017 > xfs_buf_t *bp; > > error = 0; 1024a1019,1021 > bp = xlog_get_bp(1, log->l_mp); > if (!bp) > return -ENOMEM; 1026,1040d1022 < curr_block = start_block; < for (i = 0; i < blocks; i++) { < INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM); < INT_SET(recp->h_cycle, ARCH_CONVERT, cycle); < INT_SET(recp->h_version, ARCH_CONVERT, 1); < INT_ZERO(recp->h_len, ARCH_CONVERT); < ASSIGN_ANY_LSN(recp->h_lsn, cycle, curr_block, ARCH_CONVERT); < ASSIGN_ANY_LSN(recp->h_tail_lsn, tail_cycle, tail_block, ARCH_CONVERT); < INT_ZERO(recp->h_chksum, ARCH_CONVERT); < INT_ZERO(recp->h_prev_block, ARCH_CONVERT); /* unused */ < INT_ZERO(recp->h_num_logops, ARCH_CONVERT); < < curr_block++; < recp = (xlog_rec_header_t*)(((char *)recp) + BBSIZE); < } 1042c1024,1039 < error = xlog_bwrite(log, start_block, blocks, bp); --- > INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM); > INT_SET(recp->h_cycle, ARCH_CONVERT, cycle); > INT_SET(recp->h_version, ARCH_CONVERT, 1); > INT_ZERO(recp->h_len, ARCH_CONVERT); > ASSIGN_ANY_LSN(recp->h_tail_lsn, tail_cycle, tail_block, ARCH_CONVERT); > INT_ZERO(recp->h_chksum, ARCH_CONVERT); > INT_ZERO(recp->h_prev_block, ARCH_CONVERT); /* unused */ > INT_ZERO(recp->h_num_logops, ARCH_CONVERT); > > for (i = start_block; i < start_block + blocks; i++) { > ASSIGN_ANY_LSN(recp->h_lsn, cycle, i, ARCH_CONVERT); > error = xlog_bwrite(log, i, 1, bp); > if (error) > break; > } > xlog_put_bp(bp); 1075d1071 < xfs_buf_t *bp; 1130,1132d1125 < bp = xlog_get_bp(max_distance,log->l_mp); < if (!bp) < return -ENOMEM; 1144,1148c1137 < tail_block, bp); < if (error) { < xlog_put_bp(bp); < return error; < } --- > tail_block); 1160,1164c1149 < tail_block, bp); < if (error) { < xlog_put_bp(bp); < return error; < } --- > tail_block); 1176,1180c1161 < tail_cycle, tail_block, bp); < if (error) { < xlog_put_bp(bp); < return error; < } --- > tail_cycle, tail_block); 1182,1183d1162 < < xlog_put_bp(bp); From owner-linux-xfs@oss.sgi.com Tue Sep 19 20:28:46 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 20:28:36 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59734 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 20:28:25 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA08512 for ; Tue, 19 Sep 2000 20:35:11 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA27063 for linux-xfs@oss.sgi.com; Wed, 20 Sep 2000 14:27:06 +1100 (EST) Date: Wed, 20 Sep 2000 14:27:06 +1100 (EST) From: Nathan Scott Message-Id: <200009200327.OAA27063@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - doc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:74708a Date: Tue Sep 19 20:26:25 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/Documentation/Configure.help - 1.59 - add some narrative about XFS for the make *config scripts. someone who knows more than i about pagebuf should do a similar thing for config_pagebuf... From owner-linux-xfs@oss.sgi.com Tue Sep 19 20:31:16 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 20:31:06 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8791 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 20:30:51 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA06676; Tue, 19 Sep 2000 20:37:38 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA61982; Tue, 19 Sep 2000 20:30:49 -0700 (PDT) Date: Tue, 19 Sep 2000 20:30:49 -0700 (PDT) Message-Id: <200009200330.UAA61982@info.engr.sgi.com> X-Pv-Incident: 801066 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 801066 - Extra unneeded endian flipping in XFS code To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801066 Status : open Priority : 3 Assigned Engineer : dxm Submitter : lord *Modified User : dxm *Modified User Domain : engr *Description : Capturing some old email state into a PV I was digging through the code trying to figure out why the power pc is getting zero inode numbers and I came across this code in xfs_inobt_get_rec INT_SET(*ino, arch, INT_GET(rec->ir_startino, ARCH_CONVERT)); INT_SET(*fcnt, arch, INT_GET(rec->ir_freecount, ARCH_CONVERT)); INT_SET(*free, arch, INT_GET(rec->ir_free, ARCH_CONVERT)); Places like xfs_dialloc are calling xfs_inobt_get_rec() several times with ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 19 2000 08:30:48PM ========================== I have the changes necessary for a clean user build ready and I'm working on the main part of this bug. (not for beta). From owner-linux-xfs@oss.sgi.com Tue Sep 19 22:22:55 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 22:22:46 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:46378 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 22:22:25 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA23482; Tue, 19 Sep 2000 22:14:43 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA50477; Tue, 19 Sep 2000 22:22:24 -0700 (PDT) Date: Tue, 19 Sep 2000 22:22:24 -0700 (PDT) Message-Id: <200009200522.WAA50477@info.engr.sgi.com> X-Pv-Incident: 802318 webPV: proxy2.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (tes@engr.sgi.com) Subject: BUG 802318 - xfsdump can't do multiple dumps to one tape (without -m) To: tes@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802318 Submitter : tes Submitter Domain : engr Assigned Engineer : tes Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : A QA test revealed that xfsdump using the default drive_scsitape strategy cannot do multiple dumps to a tape. The problem stems from a different behaviour between the Linux scsi tape driver and the IRIX one. In IRIX, the drive can be position to the left of the file mark after a bsf or to the right of a file mark after a fsf, and it will report a status of MT_FMK. However, in Linux, if one does a bsf to the left of the file mark, it does not set the status of MT_FMK (or GMT_EOF). This is confirmed with mt(1) and author of driver. The xfsdump code does a bsf after skipping over the 1st dump's media files. After the bsf, it does a check to ensure it is at a filemark and this fails with: encountered media error attempting BSF There is no way for verification of being to the left of a filemark after a BSF in Linux, so the fix is to remove this check. As far as I can tell, it is just being paranoid. This status checking would not happen in the minrmt (-m) case for xfsdump. Post script: ------------ Having a further look at the code in dump: 16:14 tes@snort 21> grep do_bsf *.c content.c: rval = ( * dop->do_bsf )( drivep, 0, &status ); content.c: rval = ( * dop->do_bsf )( drivep, 0, &status ); drive_minrmt.c:static intgen_t do_bsf( drive_t *, intgen_t , intgen_t *); drive_minrmt.c: do_bsf, /* do_bsf */ drive_minrmt.c:do_bsf( drive_t *drivep, intgen_t count, intgen_t *statp ) drive_scsitape.c:static intgen_t do_bsf( drive_t *, intgen_t , intgen_t *); drive_scsitape.c: do_bsf, /* do_bsf */ drive_scsitape.c:do_bsf( drive_t *drivep, intgen_t count, intgen_t *statp ) It appears to only every do a "do_bsf(count = 0)" which translates to: bsf 1, fsf 1 I can't really see that it is achieving a whole lot ! The only other place where we don't use 0 as the count is in dump/scan which is not exported in IRIX and hasn't been ported to Linux. Hmmmmm. From owner-linux-xfs@oss.sgi.com Tue Sep 19 22:44:25 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 22:44:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:10285 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 22:43:59 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA24733; Tue, 19 Sep 2000 22:36:17 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA60552; Tue, 19 Sep 2000 22:43:57 -0700 (PDT) Date: Tue, 19 Sep 2000 22:43:57 -0700 (PDT) Message-Id: <200009200543.WAA60552@info.engr.sgi.com> X-Pv-Incident: 802318 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (tes@engr.sgi.com) Subject: ADD 802318 - xfsdump can't do multiple dumps to one tape (without -m) To: tes@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802318 Status : open Priority : 3 Assigned Engineer : tes Submitter : tes *Modified User : tes *Modified User Domain : engr *Description : A QA test revealed that xfsdump using the default drive_scsitape strategy cannot do multiple dumps to a tape. The problem stems from a different behaviour between the Linux scsi tape driver and the IRIX one. In IRIX, the drive can be position to the left of the file mark after a bsf or to the right of a file mark after a fsf, and it will report a status of MT_FMK. ..... ========================== ADDITIONAL INFORMATION (ADD) From: tes@engr (BugWorks) Date: Sep 19 2000 10:43:56PM ========================== My previous postscript was unfounded. A will actually achieve a lot; it will put one back to the start of the file, just after the filemark. bsf 1 will put one back to the left of the previous filemark. And the fsf 1 will then move one to the right of the filemark. So in the xfsdump code, it means that when it finds the terminator-media-file it will backspace to the start of the terminator and then start writing the next dump file over the top of it. Bottom line is that my QA'ed fix is the one to go with, i.e. remove the paranoid checks. Will get ivanr to review. From owner-linux-xfs@oss.sgi.com Wed Sep 20 08:16:21 2000 Received: by oss.sgi.com id ; Wed, 20 Sep 2000 08:16:01 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:48902 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 20 Sep 2000 08:15:58 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA05954; Wed, 20 Sep 2000 08:08:13 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA86017; Wed, 20 Sep 2000 08:15:53 -0700 (PDT) Date: Wed, 20 Sep 2000 08:15:53 -0700 (PDT) Message-Id: <200009201515.IAA86017@info.engr.sgi.com> X-Pv-Incident: 802340 webPV: fzr600.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (coreym@sgi.com) Subject: BUG 802340 - kernel panic To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802340 Submitter : coreym Submitter Domain : sgi.com Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 1 Project : xfs-linux Status : open Description : I was running rwtest (doio and iogen) to stress xfs on tarpon and tarpon paniced. I have no way of knowing if it was related to my test or not. The panic string that I received was: Message from syslogd@tarpon at Fri Sep 15 11:49:03 2000 ... tarpon kernel: Kernel panic: kmem_alloc: NULL memory on KM_SLEEP request! From owner-linux-xfs@oss.sgi.com Wed Sep 20 08:23:01 2000 Received: by oss.sgi.com id ; Wed, 20 Sep 2000 08:22:51 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:39944 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 20 Sep 2000 08:22:44 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA06824; Wed, 20 Sep 2000 08:15:01 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA29633; Wed, 20 Sep 2000 08:22:42 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA57279; Wed, 20 Sep 2000 08:21:25 -0700 (PDT) Date: Wed, 20 Sep 2000 08:21:25 -0700 (PDT) Message-Id: <200009201521.IAA57279@info.engr.sgi.com> X-Pv-Incident: 802340 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 802340 - kernel panic To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802340 Status : open Priority : 1 Assigned Engineer : nb Submitter : coreym *Modified User : lord *Modified User Domain : sgi.com *Description : I was running rwtest (doio and iogen) to stress xfs on tarpon and tarpon paniced. I have no way of knowing if it was related to my test or not. The panic string that I received was: Message from syslogd@tarpon at Fri Sep 15 11:49:03 2000 ... tarpon kernel: Kernel panic: kmem_alloc: NULL memory on KM_SLEEP request! ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 20 2000 08:21:24AM ========================== Any chance of filling in a few blanks such as the amount of memory in the system, where the kernel came from - did you build it, or was it a propack install? If you built it, what options did you use. Also, what mount options were used on the filesystem. And finally is the iogen/doio command line findable, or was it part of a larger test mix? From owner-linux-xfs@oss.sgi.com Wed Sep 20 11:26:34 2000 Received: by oss.sgi.com id ; Wed, 20 Sep 2000 11:26:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11808 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 20 Sep 2000 11:25:51 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA01852 for ; Wed, 20 Sep 2000 11:32:38 -0700 (PDT) mail_from (cattelan@gibble.americas.sgi.com) Received: from ironwood-e101.americas.sgi.com (ironwood-e101.americas.sgi.com [128.162.101.96]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA73598 for ; Wed, 20 Sep 2000 13:24:34 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e101.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id NAA27011 for ; Wed, 20 Sep 2000 13:24:33 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e8KIOXh23884 for linux-xfs@oss.sgi.com; Wed, 20 Sep 2000 13:24:33 -0500 Date: Wed, 20 Sep 2000 13:24:33 -0500 From: Russell Cattelan Message-Id: <200009201824.e8KIOXh23884@gibble.americas.sgi.com> Subject: TAKE - Turn off debug in qlogic driver. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Sep 14 15:57:41 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74432a linux/Makefile - 1.65 - Force gcc to a known working version. Subject: TAKE - Date: Wed Sep 20 11:23:01 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74729a linux/drivers/scsi/qla2x00.c - 1.2 - Turn off debug; this was messing up the kernel sysmbols when loading as a module. From owner-linux-xfs@oss.sgi.com Wed Sep 20 11:55:03 2000 Received: by oss.sgi.com id ; Wed, 20 Sep 2000 11:54:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:18502 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 20 Sep 2000 11:54:27 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA06122; Wed, 20 Sep 2000 11:46:44 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA20667; Wed, 20 Sep 2000 11:53:55 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA33769; Wed, 20 Sep 2000 11:52:37 -0700 (PDT) Date: Wed, 20 Sep 2000 11:52:37 -0700 (PDT) Message-Id: <200009201852.LAA33769@info.engr.sgi.com> X-Pv-Incident: 802204 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: REASSIGN 802204 - lilo does not work on XFS To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802204 Status : open Priority : 2 *Assigned Engineer : lord Submitter : lord Project : xfs-linux Assigned Group : xfs-linux Opened Date : 09/19/00 *Modified User : lord *Modified User Domain : sgi.com *Description : Running lilo to install a kernel from an xfs filesystem does not work. It generates a corrupt lilo map file - booting the system results in a prompt of LIL- and a hung machine which requires a rescue disk to get running again. Lilo installs some code in the boot area of a disk which is used to indicate where the kernel lives on disk. When running it uses the FIBMAP ioctl to determine the disk location of the kernel this is recorded into a map file. The location of the map file is then recorded into the boot area of the disk. ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Sep 20 2000 11:52:37AM ========================== I have a fix From owner-linux-xfs@oss.sgi.com Wed Sep 20 12:02:03 2000 Received: by oss.sgi.com id ; Wed, 20 Sep 2000 12:01:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54308 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 20 Sep 2000 12:01:29 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA01706; Wed, 20 Sep 2000 12:08:16 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA19313; Wed, 20 Sep 2000 12:00:09 -0700 (PDT) Date: Wed, 20 Sep 2000 12:00:09 -0700 (PDT) Message-Id: <200009201900.MAA19313@feature.engr.sgi.com> X-Pv-Incident: 802204 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (lord@sgi.com) Subject: TAKE 802204 - lilo does not work on XFS To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord *Status : closed Assigned Engineer : lord *Fixed By : lord *Fixed By Domain : sgi.com *Closed Date : 09/20/00 Priority : 2 *Modified Date : 09/20/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : From: steve lord (TAKE) Date: Sep 20 2000 12:00:09PM [pvnews version: 1.71] ---------------------------- Two bugs in here, the map file has always just been written when we ask for its disk location, so it tends to be delalloc. Flush files which are delalloc. Secondly, the return value from xfs_bmapi was being interpreted badly. It did not take into account the fact that the extent returned could start at a different file offset than we queried for. Date: Wed Sep 20 11:54:51 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:74735a linux/fs/xfs/linux/xfs_iops.c - 1.69 - in linvfs_bmap ensure that a file has a disk location before attempting to find it - flush delalloc files. Then in doing the block calculations take into account the difference between the start of the extent returned and the location we were asking for. Description : Running lilo to install a kernel from an xfs filesystem does not work. It generates a corrupt lilo map file - booting the system results in a prompt of LIL- and a hung machine which requires a rescue disk to get running again. Lilo installs some code in the boot area of a disk which is used to indicate where the kernel lives on disk. When running it uses the FIBMAP ioctl to determine the disk location of the kernel this is recorded into a map file. The location of the map file is then recorded into the boot area of the disk. ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Sep 20 2000 11:52:37AM ========================== I have a fix From owner-linux-xfs@oss.sgi.com Wed Sep 20 17:46:38 2000 Received: by oss.sgi.com id ; Wed, 20 Sep 2000 17:46:19 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:25925 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 20 Sep 2000 17:46:04 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA05419 for ; Wed, 20 Sep 2000 17:52:50 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA77018 for linux-xfs@oss.sgi.com; Thu, 21 Sep 2000 11:43:29 +1100 (EST) Date: Thu, 21 Sep 2000 11:43:29 +1100 (EST) From: Timothy Shimmin Message-Id: <200009210043.LAA77018@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 802318 - xfsdump should be able to do multiple dumps to a tape Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Fixes pv: 802318 Reviewed: ivanr@omen Checkin approval: kenmcd@engr Modid: 2.4.0-test1-xfs:slinx:74778a Date: Wed Sep 20 17:38:47 PDT 2000 Workarea: snort:/build4/tes/slinx-xfs-beta Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/dump/common/drive_scsitape.c - 1.23 - pv=802318;rv=ivanr@engr; Mask out the code which checks that the status is at a FMK after a BSF. This happens for IRIX but not for Linux. Also add an INFO msg about getting EOVERFLOW in read which is typically the result of using too large a block size. cmd/xfs/stress/common.config - 1.5 - Add tape drive for sagan. cmd/xfs/stress/common.dump - 1.14 - Get rid of "-o -F" option so that I can write test 035. This test will change again when I can check in all my changes for the rmt dump tests. cmd/xfs/stress/035 - 1.1 - This test verifies that the fix for pv#802318 is now working. It does multiple dumps to one tape. cmd/xfs/stress/035.out - 1.1 - The out file for 035. From owner-linux-xfs@oss.sgi.com Wed Sep 20 17:47:59 2000 Received: by oss.sgi.com id ; Wed, 20 Sep 2000 17:47:48 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35909 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 20 Sep 2000 17:47:37 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA06867; Wed, 20 Sep 2000 17:54:25 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA96233; Wed, 20 Sep 2000 17:47:36 -0700 (PDT) Date: Wed, 20 Sep 2000 17:47:36 -0700 (PDT) Message-Id: <200009210047.RAA96233@info.engr.sgi.com> X-Pv-Incident: 802318 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (tes@engr.sgi.com) Subject: CLOSE 802318 - xfsdump can't do multiple dumps to one tape (without -m) To: tes@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802318 *Status : closed Priority : 3 Assigned Engineer : tes Submitter : tes Opened Date : 09/19/00 *Closed Date : 09/20/00 *Fixed By : tes *Fixed By Domain : engr *Modified Date : 09/20/00 *Modified User : tes *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: tes@engr (BugWorks) Date: Sep 20 2000 05:47:35PM ========================== Forgot to post the take msg to the bugs address, so will close it manually... Modid: 2.4.0-test1-xfs:slinx:74778a Date: Wed Sep 20 17:38:47 PDT 2000 Workarea: snort:/build4/tes/slinx-xfs-beta Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/dump/common/drive_scsitape.c - 1.23 - pv=802318;rv=ivanr@engr; Mask out the code which checks that the status is at a FMK after a BSF. This happens for IRIX but not for Linux. Also add an INFO msg about getting EOVERFLOW in read which is typically the result of using too large a block size. cmd/xfs/stress/common.config - 1.5 - Add tape drive for sagan. cmd/xfs/stress/common.dump - 1.14 - Get rid of "-o -F" option so that I can write test 035. This test will change again when I can check in all my changes for the rmt dump tests. cmd/xfs/stress/035 - 1.1 - This test verifies that the fix for pv#802318 is now working. It does multiple dumps to one tape. cmd/xfs/stress/035.out - 1.1 - The out file for 035. From owner-linux-xfs@oss.sgi.com Thu Sep 21 16:31:06 2000 Received: by oss.sgi.com id ; Thu, 21 Sep 2000 16:30:57 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:18248 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 21 Sep 2000 16:30:43 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA26699 for ; Thu, 21 Sep 2000 16:23:00 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA03605 for linux-xfs@oss.sgi.com; Fri, 22 Sep 2000 10:29:24 +1100 (EST) Date: Fri, 22 Sep 2000 10:29:24 +1100 (EST) From: Timothy Shimmin Message-Id: <200009212329.KAA03605@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Adds rmt tape capability to xfsdump/xfsrestore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:74825a Date: Thu Sep 21 16:26:06 PDT 2000 Workarea: snort:/build4/tes/slinx-xfs Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/doc/README.xfsdump - 1.2 - Add contents paragraph. Update paragraph on testing. Update TODO list. cmd/xfs/dump/Makefile - 1.5 - Add librmt directory. cmd/xfs/dump/common/drive_minrmt.c - 1.21 - Add handling of ENOSPC - IRIX rmt returns ENOSPC for erased media. cmd/xfs/dump/common/drive_scsitape.c - 1.24 - This actually adds nothing. Oops. It was checked into beta already to fix multiple dumps to a tape. cmd/xfs/dump/dump/Makefile - 1.17 - Add librmt for linking. This adds remote tape capability to xfsdump. cmd/xfs/dump/restore/Makefile - 1.8 - Add librmt for linking. This adds remote tape capability to xfsrestore. cmd/xfs/man/man8/xfsdump.8 - 1.3 cmd/xfs/man/man8/xfsrestore.8 - 1.3 - Put back text the says that remote tapes are supported. cmd/xfs/stress/022 - 1.2 - Add explicit calls for requiring tape and erasing tape. cmd/xfs/stress/022.out - 1.4 - Change to SCRATCH instead of TEST. cmd/xfs/stress/023 - 1.2 - Add explicit calls for requiring tape and erasing tape. cmd/xfs/stress/023.out - 1.4 - Change to SCRATCH instead of TEST. cmd/xfs/stress/024 - 1.2 - Add explicit calls for requiring tape and erasing tape. cmd/xfs/stress/024.out - 1.4 - Change to SCRATCH instead of TEST. cmd/xfs/stress/025 - 1.2 - Add explicit calls for requiring tape and erasing tape. cmd/xfs/stress/025.out - 1.3 - Change to SCRATCH instead of TEST. cmd/xfs/stress/026 - 1.3 - Get rid of variable, no_tape_required - now use function call if require a tape. cmd/xfs/stress/026.out - 1.3 - Change to SCRATCH instead of TEST. cmd/xfs/stress/027 - 1.3 - Get rid of variable, no_tape_required - now use function call if require a tape. cmd/xfs/stress/027.out - 1.2 - Change to SCRATCH instead of TEST. cmd/xfs/stress/028 - 1.4 - Minor changes to match with the updated common.dump. cmd/xfs/stress/028.out - 1.3 - Change to SCRATCH instead of TEST. cmd/xfs/stress/035 - 1.2 - Try restoring the 2nd dump on the tape and comparing that one. cmd/xfs/stress/035.out - 1.2 - Restores smaller 2nd dump now. cmd/xfs/stress/README - 1.6 - Add stuff about RMT_TAPE's and correct reference from common.rc to common.config. cmd/xfs/stress/common.config - 1.6 - Add stuff for RMT_TAPE's for bruce and sagan. cmd/xfs/stress/common.dump - 1.15 - Heaps of changes to make stuff a bit more generic so that we could more easily test remote tape capability. cmd/xfs/stress/group - 1.37 - Add tests for checking the rmt tape capability of xfsdump/restore. cmd/xfs/stress/src/Makefile - 1.14 - Add testrmt to Makefile. cmd/xfs/dump/librmt/Makefile - 1.1 - Build librmt library for dump. cmd/xfs/dump/librmt/isrmt.c - 1.1 cmd/xfs/dump/librmt/rmtabort.c - 1.1 cmd/xfs/dump/librmt/rmtaccess.c - 1.1 cmd/xfs/dump/librmt/rmtclose.c - 1.1 cmd/xfs/dump/librmt/rmtcommand.c - 1.1 cmd/xfs/dump/librmt/rmtcreat.c - 1.1 cmd/xfs/dump/librmt/rmtdev.c - 1.1 cmd/xfs/dump/librmt/rmtfstat.c - 1.1 cmd/xfs/dump/librmt/rmtioctl.c - 1.1 cmd/xfs/dump/librmt/rmtisatty.c - 1.1 - librmt function. cmd/xfs/dump/librmt/rmtlib.h - 1.1 - Local header file for library. cmd/xfs/dump/librmt/rmtlseek.c - 1.1 cmd/xfs/dump/librmt/rmtopen.c - 1.1 cmd/xfs/dump/librmt/rmtread.c - 1.1 cmd/xfs/dump/librmt/rmtstatus.c - 1.1 cmd/xfs/dump/librmt/rmtwrite.c - 1.1 - librmt function. cmd/xfs/stress/036 - 1.1 cmd/xfs/stress/036.out - 1.1 - Test xfsdump/restore minrmt to a remote IRIX tape. cmd/xfs/stress/037 - 1.1 cmd/xfs/stress/037.out - 1.1 - Test xfsdump/restore minrmt to a remote linux tape. cmd/xfs/stress/038 - 1.1 cmd/xfs/stress/038.out - 1.1 - Test xfsdump/restore to a remote linux tape. cmd/xfs/stress/039 - 1.1 cmd/xfs/stress/039.out - 1.1 - Test xfsdump/restore to a remote IRIX tape. cmd/xfs/stress/src/testrmt.c - 1.1 - Test the dump/librmt library in isolation - i.e. out of the context of xfsdump/xfsrestore. It is basically a cut-down mt(1) with remote tape capability like it is on IRIX. From owner-linux-xfs@oss.sgi.com Fri Sep 22 02:34:59 2000 Received: by oss.sgi.com id ; Fri, 22 Sep 2000 02:34:49 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29259 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 22 Sep 2000 02:34:30 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id CAA00737 for ; Fri, 22 Sep 2000 02:41:19 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id EAA78580 for ; Fri, 22 Sep 2000 04:33:14 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id EAA83083 for ; Fri, 22 Sep 2000 04:33:14 -0500 (CDT) Received: (from lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) id EAA25164 for linux-xfs@oss.sgi.com; Fri, 22 Sep 2000 04:29:39 -0500 Date: Fri, 22 Sep 2000 04:29:39 -0500 From: Steve Lord Message-Id: <200009220929.EAA25164@jen.americas.sgi.com> Subject: TAKE - small bugfix to endcase in bulkstat To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Sep 22 02:32:32 PDT 2000 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:74837a linux/fs/xfs/xfs_itable.c - 1.92 - move incorrectly positioned ifdef which would break bulkstat if the case there was no user buffer passed in. From owner-linux-xfs@oss.sgi.com Fri Sep 22 08:25:23 2000 Received: by oss.sgi.com id ; Fri, 22 Sep 2000 08:25:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47719 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 22 Sep 2000 08:24:55 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03557; Fri, 22 Sep 2000 08:31:44 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA56384; Fri, 22 Sep 2000 08:24:54 -0700 (PDT) Date: Fri, 22 Sep 2000 08:24:54 -0700 (PDT) Message-Id: <200009221524.IAA56384@info.engr.sgi.com> X-Pv-Incident: 802626 webPV: jen.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: BUG 802626 - Infinite cpu loop in _pagebuf_handle_iovecs To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802626 Submitter : lord Submitter Domain : sgi.com Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 1 Project : xfs-linux Status : open Description : Running doio on xfs managed to produce a number of cases of read calls getting into a cpu loop in _pagebuf_handle_iovecs Stack traceback for pid 1299 EBP EIP Function(args) 0xc1decf94 0xf8825c22 [pagebuf]_pagebuf_handle_iovecs+0xd2 (0xdda75ee0, 0xc1decf94, 0x0, 0x19000, 0x0) pagebuf .text 0xf8823060 0xf8825b50 0xf8825d90 0xdda75e6c 0xf882649d [pagebuf]_pagebuf_read_helper+0x25 (0xdda75ee0, 0xc1decf94, 0x0, 0x1000) pagebuf .text 0xf8823060 0xf8826478 0xf88264a8 0xdda75eac 0xc012773b do_generic_file_read+0x207 (0xf48f6e60, 0xf48f6e80, 0xdda75ee0, 0xf8826478) kernel .text 0xc0100000 0xc0127534 0xc0127a60 0xdda75f1c 0xf882656b [pagebuf]pagebuf_generic_file_read+0xc3 (0xf48f6e60, 0x403d4008, 0x1a441, 0xf48f6e80) pagebuf .text 0xf8823060 0xf88264a8 0xf88265bc 0xdda75f44 0xf8881ac8 [xfs]xfs_rdwr+0x48 (0xf4d7969c, 0xf48f6e60, 0x403d4008, 0x1a441, 0xf48f6e80) xfs .text 0xf882e060 0xf8881a80 0xf8881af4 0xdda75f70 0xf8881b45 [xfs]xfs_read+0x51 (0xf4d7969c, 0xf48f6e60, 0x403d4008, 0x1a441, 0xf48f6e80) xfs .text 0xf882e060 0xf8881af4 0xf8881b50 0xdda75f98 0xf887e982 [xfs]linvfs_read+0x62 (0xf48f6e60, 0x403d4008, 0x1a441, 0xf48f6e80, 0xdda74000) xfs .text 0xf882e060 0xf887e920 0xf887e98c 0xdda75fbc 0xc0131b18 sys_read+0xa4 (0x3, 0x403d4008, 0x1a441, 0xbffffbc0, 0x0) kernel .text 0xc0100000 0xc0131a74 0xc0131b30 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [2]kdb> pbiodesc 0xdda75ee0 pb_io_desc_t at 0xdda75ee0 io_rdesc [ written 0x56ab count 0x14d96 buf 0xf887e8ca error 0 ] io_dir 1 io_offset 0x19000 io_iovec_nr 0x1 io_iovec 0xdda75ed4 io_iovec_offset 0x56ab io_iovec_index 0x0 io_sshift 0x0 io_i_size 0xf4240 iovec : 403d4008 0001a441 One doio process has racked up over 12 hours of cpu time in this loop! From owner-linux-xfs@oss.sgi.com Fri Sep 22 08:30:23 2000 Received: by oss.sgi.com id ; Fri, 22 Sep 2000 08:30:13 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:11638 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 22 Sep 2000 08:30:03 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA14213; Fri, 22 Sep 2000 08:22:21 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA03986; Fri, 22 Sep 2000 08:30:02 -0700 (PDT) Date: Fri, 22 Sep 2000 08:30:02 -0700 (PDT) Message-Id: <200009221530.IAA03986@info.engr.sgi.com> X-Pv-Incident: 802626 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 802626 - Infinite cpu loop in _pagebuf_handle_iovecs To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802626 Status : open Priority : 1 Assigned Engineer : nb Submitter : lord *Modified User : lord *Modified User Domain : sgi.com *Description : Running doio on xfs managed to produce a number of cases of read calls getting into a cpu loop in _pagebuf_handle_iovecs Stack traceback for pid 1299 EBP EIP Function(args) 0xc1decf94 0xf8825c22 [pagebuf]_pagebuf_handle_iovecs+0xd2 (0xdda75ee0, 0xc1decf94, 0x0, 0x19000, 0x0) pagebuf .text 0xf8823060 0xf8825b50 0xf8825d90 0xdda75e6c 0xf882649d [pagebuf]_pagebuf_read_helper+0x25 (0xdda75ee0, 0xc1decf94, 0x0, 0x1000) pagebuf .text 0xf8823060 0xf8826478 0xf88264a8 0xdda75eac 0xc012773b do_generic_file_read+0x207 (0xf48f6e60, 0xf48f6e80, 0xdda75ee0, 0xf8826478) ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 22 2000 08:30:01AM ========================== Filesystem was mounted without any kio options, so it is buffer head based. Here is a longer version of the arguments for _pagebuf_handle_iovecs 0xdda75e3c 0xf8825c2a [pagebuf]_pagebuf_handle_iovecs+0xda (0xdda75ee0, 0xc1decf94, 0x0, 0x19000, 0x0, 0x1000, 0x1) From owner-linux-xfs@oss.sgi.com Fri Sep 22 10:28:24 2000 Received: by oss.sgi.com id ; Fri, 22 Sep 2000 10:28:14 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29051 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 22 Sep 2000 10:27:51 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA02438; Fri, 22 Sep 2000 10:34:40 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id KAA34829; Fri, 22 Sep 2000 10:27:50 -0700 (PDT) Date: Fri, 22 Sep 2000 10:27:50 -0700 (PDT) Message-Id: <200009221727.KAA34829@info.engr.sgi.com> X-Pv-Incident: 802626 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: REJECT 802626 - Infinite cpu loop in _pagebuf_handle_iovecs To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802626 *Status : rejected Priority : 1 Assigned Engineer : nb Submitter : lord Opened Date : 09/22/00 *Closed Date : 09/22/00 *Fixed By : lord *Fixed By Domain : sgi.com *Modified Date : 09/22/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : ========================== ADDITIONAL INFORMATION (REJECT) From: lord@sgi.com (BugWorks) Date: Sep 22 2000 10:27:49AM ========================== OK, killing this PV, it is not a problem, we do eventually get out of here. The hang is something totally unrelated which I will PV elsewhere. From owner-linux-xfs@oss.sgi.com Sun Sep 24 04:39:12 2000 Received: by oss.sgi.com id ; Sun, 24 Sep 2000 04:39:02 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:61703 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Sun, 24 Sep 2000 04:38:49 -0700 Received: (qmail 7256 invoked from network); 24 Sep 2000 11:38:43 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 24 Sep 2000 11:38:43 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: kdb@oss.sgi.com Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [Announce] kdb v1.5-beta1 is available Date: Sun, 24 Sep 2000 22:38:41 +1100 Message-ID: <29463.969795521@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii http://oss.sgi.com/projects/kdb/download/ix86/ contains a patch for kdb v1.5-beta1 against 2.4.0-test8, patch against 2.4.0-test9-pre6 will be there soon. Copied to linux-xfs for interest only, XFS will stay on kdb v1.4 until kdb v1.5 has been better tested. This version of kdb has had a lot of internal changes from kdb v1.4 so it comes with even less warranty than normal. You may hit problems in the debugger itself so only apply this patch if you want to explore the debugger, if you want to do real debugging then stick to kdb v1.4 for the moment. All the global kdb state has been converted to per cpu state, this gives a lot more control over what kdb can do to individual cpus. Besides the internal rewrite, there are quite a few externally visible changes. man Documentation/kdb/kdb.mm, sections INITIAL KDB COMMANDS onwards. * Initial commands. Edit kdb/kdb_cmds to define your startup commands, build and install the new kernel. Allows per user definition of startup kdb commands. * SS and SSB commands now only let one cpu run and attempt to block interrupts while they do so. Previously ss[b] let all cpus run with interrupts enabled which meant the kernel changed while you were debugging. * kdb can now recover from errors in its own commands. This is the requirement that triggered the rewrite, it turned out to be a can of worms. * kdb can now go recursive which gives you some self debugging capability. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE5zefAi4UHNye0ZOoRAghjAKCSBmVjg4/JNa0P4aU0l+MSBa9QAQCcDdXw LpqTl5moOVKO/9w+n1+y3k8= =1xuA -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Sep 24 20:25:01 2000 Received: by oss.sgi.com id ; Sun, 24 Sep 2000 20:24:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:44046 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 24 Sep 2000 20:24:17 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA09355 for ; Sun, 24 Sep 2000 20:16:32 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA39009 for linux-xfs@oss.sgi.com; Mon, 25 Sep 2000 14:22:56 +1100 (EST) Date: Mon, 25 Sep 2000 14:22:56 +1100 (EST) From: Daniel Moore Message-Id: <200009250322.OAA39009@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_repair error messages Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Use sensible error messages. I wasn't game to enable the force_geo command line option since it looks like a good way to shoot yourself in the foot and filesystems with <3 AGs would not be common. Modid: 2.4.x-xfs:slinx:74927a Date: Sun Sep 24 20:21:34 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/repair/sb.c - 1.35 - Make SB error messages meaningful. From owner-linux-xfs@oss.sgi.com Sun Sep 24 22:56:33 2000 Received: by oss.sgi.com id ; Sun, 24 Sep 2000 22:56:22 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29033 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 24 Sep 2000 22:56:05 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA04765 for ; Sun, 24 Sep 2000 23:02:56 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA27126 for linux-xfs@oss.sgi.com; Mon, 25 Sep 2000 16:54:45 +1100 (EST) Date: Mon, 25 Sep 2000 16:54:45 +1100 (EST) From: Daniel Moore Message-Id: <200009250554.QAA27126@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:74930a Date: Sun Sep 24 22:54:31 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/stress/common.rc - 1.30 - rewrite _fix_malloc so it sucks less data in From owner-linux-xfs@oss.sgi.com Sun Sep 24 23:37:13 2000 Received: by oss.sgi.com id ; Sun, 24 Sep 2000 23:37:02 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36714 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 24 Sep 2000 23:36:39 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA09902 for ; Sun, 24 Sep 2000 23:43:30 -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 RAA90359 for linux-xfs@oss.sgi.com; Mon, 25 Sep 2000 17:34:04 +1100 (EST) Date: Mon, 25 Sep 2000 17:34:04 +1100 (EST) From: Nathan Scott Message-Id: <200009250634.RAA90359@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - SIM Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This monster mod removes all SIM remnants from the kernel code, which tidies up a whole bunch of stuff. Since I was going to be changing almost every XFS kernel file in this, I took the opporunity to make the XFS src use a common header file. This moves all the knowledge of include order, magic #define settings, etc into a common place, as well as moving (almost) all pseudo-inc #include's into one spot (for easier removal later). Alot more stuff came out than went in here & my little srcdiff script also now reports no differences between kernel and libxfs code. The last thing I did was remove #idents - these were causing problems with the user/kernel header reconciliation. Tested this using both debug & non-debug builds and did full qa runs against both without issues. However, I've been manually merging all changes into this tree for over a week now, so I guess its feasible something has been missed/merged incorrectly - I don't think so tho. cheers. Modid: 2.4.x-xfs:slinx:74929a Date: Sun Sep 24 22:42:07 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/include/libxfs.h - 1.17 cmd/xfs/include/xfs_ag.h - 1.2 cmd/xfs/include/xfs_alloc.h - 1.3 cmd/xfs/include/xfs_arch.h - 1.3 cmd/xfs/include/xfs_attr_sf.h - 1.3 cmd/xfs/include/xfs_bmap.h - 1.4 cmd/xfs/include/xfs_bmap_btree.h - 1.2 cmd/xfs/include/xfs_buf_item.h - 1.3 cmd/xfs/include/xfs_cred.h - 1.2 cmd/xfs/include/xfs_da_btree.h - 1.2 cmd/xfs/include/xfs_dfrag.h - 1.5 cmd/xfs/include/xfs_dir.h - 1.2 cmd/xfs/include/xfs_dir2.h - 1.2 cmd/xfs/include/xfs_dir2_block.h - 1.2 cmd/xfs/include/xfs_dir2_leaf.h - 1.2 cmd/xfs/include/xfs_dir2_node.h - 1.2 cmd/xfs/include/xfs_dir2_sf.h - 1.2 cmd/xfs/include/xfs_dir_leaf.h - 1.2 cmd/xfs/include/xfs_dir_sf.h - 1.2 cmd/xfs/include/xfs_fs.h - 1.2 cmd/xfs/include/xfs_ialloc.h - 1.3 cmd/xfs/include/xfs_imap.h - 1.4 cmd/xfs/include/xfs_inode.h - 1.3 cmd/xfs/include/xfs_log.h - 1.2 cmd/xfs/include/xfs_log_priv.h - 1.3 cmd/xfs/include/xfs_mount.h - 1.3 cmd/xfs/include/xfs_quota.h - 1.3 cmd/xfs/include/xfs_rtalloc.h - 1.2 cmd/xfs/include/xfs_sb.h - 1.2 cmd/xfs/include/xfs_types.h - 1.3 - merge changes from current top of tree kernel sources. cmd/xfs/libxfs/util.c - 1.4 - libxfs_da_read_bufr, libxfs_da_bhold, and libxfs_da_bjoin were in the kernel and not needed/built as part of the kernel - move to here since they're only needed in userland. cmd/xfs/libxfs/xfs.h - 1.7 cmd/xfs/libxfs/xfs_alloc.c - 1.2 cmd/xfs/libxfs/xfs_bmap.c - 1.3 cmd/xfs/libxfs/xfs_btree.c - 1.2 cmd/xfs/libxfs/xfs_da_btree.c - 1.2 cmd/xfs/libxfs/xfs_dir2_node.c - 1.2 cmd/xfs/libxfs/xfs_inode.c - 1.4 - merge changes from current top of tree kernel sources. cmd/xfs/logprint/log_print_all.c - 1.3 - xlog_recover_print_item and xlog_recover_print_trans were in the kernel source but only needed by logprint - move to here since they're only needed in userland. cmd/xfs/logprint/xfs_log_recover.c - 1.2 - merge changes from current top of tree kernel sources. linux/fs/xfs/Makefile - 1.108 - don't provide -Ipseudo-inc, rework grio/rt a bit, remove -D_KERNEL, rework quota objects - in general, tidy up. linux/fs/xfs/acl_xfs.c - 1.10 - use xfs.h, remove all traces of SIM, push extern declarations into headers, dead code removal. linux/fs/xfs/linux/Makefile - 1.24 - remove -Ipseudo-inc - only a few places still use these headers, and they're all explicit now. remove -D_KERNEL. linux/fs/xfs/linux/xfs_aclstubs.c - 1.7 linux/fs/xfs/linux/xfs_behavior.c - 1.12 linux/fs/xfs/linux/xfs_cred.c - 1.9 linux/fs/xfs/linux/xfs_cred.h - 1.7 linux/fs/xfs/linux/xfs_debug.c - 1.12 linux/fs/xfs/linux/xfs_dmistubs.c - 1.9 linux/fs/xfs/linux/xfs_file.c - 1.34 linux/fs/xfs/linux/xfs_fs_subr.c - 1.22 linux/fs/xfs/linux/xfs_globals.c - 1.17 linux/fs/xfs/linux/xfs_griostubs.c - 1.11 linux/fs/xfs/linux/xfs_ioctl.c - 1.21 linux/fs/xfs/linux/xfs_iops.c - 1.71 linux/fs/xfs/linux/xfs_linux.h - 1.28 linux/fs/xfs/linux/xfs_locks.c - 1.21 linux/fs/xfs/linux/xfs_lrw.c - 1.55 linux/fs/xfs/linux/xfs_lrw.h - 1.12 linux/fs/xfs/linux/xfs_mount_opt.c - 1.13 linux/fs/xfs/linux/xfs_move.c - 1.12 linux/fs/xfs/linux/xfs_random.c - 1.45 linux/fs/xfs/linux/xfs_sema.h - 1.27 linux/fs/xfs/linux/xfs_super.c - 1.90 linux/fs/xfs/linux/xfs_uaccess.c - 1.5 linux/fs/xfs/linux/xfs_uuid.c - 1.21 linux/fs/xfs/linux/xfs_vfs.c - 1.18 linux/fs/xfs/linux/xfs_vnode.c - 1.44 linux/fs/xfs/mac_xfs.c - 1.9 linux/fs/xfs/macstubs.c - 1.6 linux/fs/xfs/pseudo-inc/ksys/behavior.h - 1.9 linux/fs/xfs/pseudo-inc/ksys/cell_config.h - 1.4 linux/fs/xfs/pseudo-inc/ksys/fsc_notify.h - 1.5 linux/fs/xfs/pseudo-inc/ksys/vfile.h - 1.6 linux/fs/xfs/pseudo-inc/sys/cmn_err.h - 1.5 linux/fs/xfs/pseudo-inc/sys/dirent.h - 1.5 linux/fs/xfs/pseudo-inc/sys/fs_subr.h - 1.9 linux/fs/xfs/pseudo-inc/sys/kabi.h - 1.7 linux/fs/xfs/pseudo-inc/sys/ktrace.h - 1.5 linux/fs/xfs/pseudo-inc/sys/mode.h - 1.3 linux/fs/xfs/pseudo-inc/sys/pathname.h - 1.5 linux/fs/xfs/pseudo-inc/sys/pvfs.h - 1.6 linux/fs/xfs/pseudo-inc/sys/statvfs.h - 1.5 linux/fs/xfs/pseudo-inc/sys/systm.h - 1.9 linux/fs/xfs/pseudo-inc/sys/types.h - 1.20 linux/fs/xfs/pseudo-inc/sys/uio.h - 1.12 linux/fs/xfs/pseudo-inc/sys/uuid.h - 1.9 linux/fs/xfs/pseudo-inc/sys/vfs.h - 1.14 linux/fs/xfs/pseudo-inc/sys/vnode.h - 1.32 linux/fs/xfs/xfs_ag.h - 1.37 linux/fs/xfs/xfs_alloc.c - 1.135 linux/fs/xfs/xfs_alloc.h - 1.47 linux/fs/xfs/xfs_alloc_btree.c - 1.63 linux/fs/xfs/xfs_alloc_btree.h - 1.20 linux/fs/xfs/xfs_arch.h - 1.29 linux/fs/xfs/xfs_attr.c - 1.80 linux/fs/xfs/xfs_attr.h - 1.15 linux/fs/xfs/xfs_attr_fetch.c - 1.8 linux/fs/xfs/xfs_attr_leaf.c - 1.51 linux/fs/xfs/xfs_attr_leaf.h - 1.26 linux/fs/xfs/xfs_attr_sf.h - 1.13 linux/fs/xfs/xfs_bit.h - 1.7 linux/fs/xfs/xfs_bmap.c - 1.260 linux/fs/xfs/xfs_bmap.h - 1.74 linux/fs/xfs/xfs_bmap_btree.c - 1.116 linux/fs/xfs/xfs_bmap_btree.h - 1.50 linux/fs/xfs/xfs_btree.c - 1.87 linux/fs/xfs/xfs_btree.h - 1.50 linux/fs/xfs/xfs_buf.h - 1.62 linux/fs/xfs/xfs_buf_item.c - 1.110 linux/fs/xfs/xfs_buf_item.h - 1.32 linux/fs/xfs/xfs_clnt.h - 1.21 linux/fs/xfs/xfs_cxfs.h - 1.7 linux/fs/xfs/xfs_da_btree.c - 1.112 linux/fs/xfs/xfs_da_btree.h - 1.40 linux/fs/xfs/xfs_dfrag.c - 1.23 linux/fs/xfs/xfs_dfrag.h - 1.5 linux/fs/xfs/xfs_dinode.h - 1.56 linux/fs/xfs/xfs_dir.c - 1.129 linux/fs/xfs/xfs_dir.h - 1.37 linux/fs/xfs/xfs_dir2.c - 1.23 linux/fs/xfs/xfs_dir2.h - 1.6 linux/fs/xfs/xfs_dir2_block.c - 1.16 linux/fs/xfs/xfs_dir2_block.h - 1.6 linux/fs/xfs/xfs_dir2_data.c - 1.12 linux/fs/xfs/xfs_dir2_data.h - 1.6 linux/fs/xfs/xfs_dir2_leaf.c - 1.16 linux/fs/xfs/xfs_dir2_leaf.h - 1.6 linux/fs/xfs/xfs_dir2_node.c - 1.16 linux/fs/xfs/xfs_dir2_node.h - 1.5 linux/fs/xfs/xfs_dir2_sf.c - 1.19 linux/fs/xfs/xfs_dir2_sf.h - 1.10 linux/fs/xfs/xfs_dir2_trace.c - 1.8 linux/fs/xfs/xfs_dir2_trace.h - 1.5 linux/fs/xfs/xfs_dir_leaf.c - 1.89 linux/fs/xfs/xfs_dir_leaf.h - 1.29 linux/fs/xfs/xfs_dir_sf.h - 1.19 linux/fs/xfs/xfs_dmapi.c - 1.25 linux/fs/xfs/xfs_dmapi.h - 1.11 linux/fs/xfs/xfs_dqblk.h - 1.5 linux/fs/xfs/xfs_dquot.c - 1.51 linux/fs/xfs/xfs_dquot.h - 1.16 linux/fs/xfs/xfs_dquot_item.c - 1.20 linux/fs/xfs/xfs_dquot_item.h - 1.5 linux/fs/xfs/xfs_error.c - 1.28 linux/fs/xfs/xfs_error.h - 1.16 linux/fs/xfs/xfs_extfree_item.c - 1.44 linux/fs/xfs/xfs_extfree_item.h - 1.13 linux/fs/xfs/xfs_fsops.c - 1.58 linux/fs/xfs/xfs_fsops.h - 1.18 linux/fs/xfs/xfs_grio.c - 1.85 linux/fs/xfs/xfs_grio.h - 1.2 linux/fs/xfs/xfs_ialloc.c - 1.140 linux/fs/xfs/xfs_ialloc.h - 1.39 linux/fs/xfs/xfs_ialloc_btree.c - 1.61 linux/fs/xfs/xfs_ialloc_btree.h - 1.19 linux/fs/xfs/xfs_iget.c - 1.129 linux/fs/xfs/xfs_imap.h - 1.7 linux/fs/xfs/xfs_inode.c - 1.303 linux/fs/xfs/xfs_inode.h - 1.142 linux/fs/xfs/xfs_inode_item.c - 1.94 linux/fs/xfs/xfs_inode_item.h - 1.38 linux/fs/xfs/xfs_inum.h - 1.18 linux/fs/xfs/xfs_iocore.c - 1.20 linux/fs/xfs/xfs_itable.c - 1.93 linux/fs/xfs/xfs_itable.h - 1.32 linux/fs/xfs/xfs_log.c - 1.223 linux/fs/xfs/xfs_log.h - 1.53 linux/fs/xfs/xfs_log_priv.h - 1.75 linux/fs/xfs/xfs_log_recover.c - 1.190 linux/fs/xfs/xfs_log_recover.h - 1.15 linux/fs/xfs/xfs_macros.c - 1.37 linux/fs/xfs/xfs_macros.h - 1.17 - use xfs.h, remove all traces of SIM, push extern declarations into headers, dead code removal. linux/fs/xfs/xfs_mount.c - 1.239 - use xfs.h, remove all traces of SIM, push extern declarations into headers, dead code removal. also rework mount path so that XFS_MFSI_RRINODES is no longer there - this was only there for repair & we do this differently now (slightly). xfs_mountfs_int has been renamed to xfs_mountfs, and the wrapper routine for the kernel has been removed (as, of course, have the wrapper routines for libsim). linux/fs/xfs/xfs_mount.h - 1.117 linux/fs/xfs/xfs_os_defs.h - 1.13 linux/fs/xfs/xfs_qm.c - 1.54 linux/fs/xfs/xfs_qm.h - 1.16 linux/fs/xfs/xfs_qm_syscalls.c - 1.41 linux/fs/xfs/xfs_quota.h - 1.21 linux/fs/xfs/xfs_quota_priv.h - 1.13 linux/fs/xfs/xfs_rename.c - 1.28 linux/fs/xfs/xfs_rpc_item.c - 1.8 linux/fs/xfs/xfs_rpc_item.h - 1.4 linux/fs/xfs/xfs_rtalloc.c - 1.62 linux/fs/xfs/xfs_rtalloc.h - 1.20 linux/fs/xfs/xfs_rtbit.c - 1.7 linux/fs/xfs/xfs_rw.c - 1.327 linux/fs/xfs/xfs_rw.h - 1.56 linux/fs/xfs/xfs_sb.h - 1.48 linux/fs/xfs/xfs_trans.c - 1.117 linux/fs/xfs/xfs_trans.h - 1.107 linux/fs/xfs/xfs_trans_ail.c - 1.56 linux/fs/xfs/xfs_trans_buf.c - 1.91 linux/fs/xfs/xfs_trans_dquot.c - 1.27 linux/fs/xfs/xfs_trans_extfree.c - 1.19 linux/fs/xfs/xfs_trans_inode.c - 1.37 linux/fs/xfs/xfs_trans_item.c - 1.27 linux/fs/xfs/xfs_trans_priv.h - 1.17 linux/fs/xfs/xfs_trans_space.h - 1.9 linux/fs/xfs/xfs_types.h - 1.48 linux/fs/xfs/xfs_utils.c - 1.33 linux/fs/xfs/xfs_vfsops.c - 1.292 linux/fs/xfs/xfs_vnodeops.c - 1.474 linux/fs/xfs/xfsdmapistubs.c - 1.6 linux/fs/xfs/xfsidbg.c - 1.152 linux/fs/xfs/xfsquotasstubs.c - 1.11 linux/fs/xfs/xfsrtstubs.c - 1.10 linux/include/linux/dmapi.h - 1.2 - use xfs.h, remove all traces of SIM, push extern declarations into headers, dead code removal. linux/include/linux/dmapi_kern.h - 1.3 linux/include/linux/grio.h - 1.2 linux/include/linux/xfs_fs.h - 1.13 - _KERNEL -> __KERNEL__ From owner-linux-xfs@oss.sgi.com Mon Sep 25 15:45:08 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 15:44:58 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27977 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 15:44:32 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA04387 for ; Mon, 25 Sep 2000 15:50:53 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA70749 for linux-xfs@oss.sgi.com; Tue, 26 Sep 2000 09:41:27 +1100 (EST) Date: Tue, 26 Sep 2000 09:41:27 +1100 (EST) From: Daniel Moore Message-Id: <200009252241.JAA70749@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing fixes Modid: 2.4.x-xfs:slinx:74982a Date: Mon Sep 25 15:41:16 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/stress/check - 1.10 cmd/xfs/stress/common.rc - 1.31 - No Message Supplied From owner-linux-xfs@oss.sgi.com Mon Sep 25 17:18:29 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 17:18:14 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13905 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 17:17:45 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09584; Mon, 25 Sep 2000 17:24:08 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA73358; Mon, 25 Sep 2000 17:17:13 -0700 (PDT) Date: Mon, 25 Sep 2000 17:17:13 -0700 (PDT) Message-Id: <200009260017.RAA73358@info.engr.sgi.com> X-Pv-Incident: 801066 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: UPDATE 801066 - Extra unneeded endian flipping in XFS code To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801066 Status : open Priority : 3 Assigned Engineer : dxm Submitter : lord Opened Date : 09/06/00 *Modified User : dxm *Modified User Domain : engr *Description : Capturing some old email state into a PV I was digging through the code trying to figure out why the power pc is getting zero inode numbers and I came across this code in xfs_inobt_get_rec INT_SET(*ino, arch, INT_GET(rec->ir_startino, ARCH_CONVERT)); INT_SET(*fcnt, arch, INT_GET(rec->ir_freecount, ARCH_CONVERT)); INT_SET(*free, arch, INT_GET(rec->ir_free, ARCH_CONVERT)); Places like xfs_dialloc are calling xfs_inobt_get_rec() several times with ..... ========================== ADDITIONAL INFORMATION (UPDATE) From: dxm@engr (BugWorks) Date: Sep 25 2000 05:17:12PM ========================== Fix pointer warnings in dump/restore build. Step one to clean user build. Modid: 2.4.x-xfs:slinx:75001a Date: Mon Sep 25 17:16:19 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-tot Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/dump/common/drive_minrmt.c - 1.22 cmd/xfs/dump/common/drive_scsitape.c - 1.25 cmd/xfs/dump/common/drive_simple.c - 1.12 - fix pointer warning From owner-linux-xfs@oss.sgi.com Mon Sep 25 18:01:19 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 18:01:09 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45907 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 18:00:33 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA05219; Mon, 25 Sep 2000 18:06:40 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA35171; Mon, 25 Sep 2000 17:59:42 -0700 (PDT) Date: Mon, 25 Sep 2000 17:59:42 -0700 (PDT) Message-Id: <200009260059.RAA35171@info.engr.sgi.com> X-Pv-Incident: 802017 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 802017 - ASSERT fail in xlog_get_bp on small mem machine To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017 *Status : closed Priority : 3 Assigned Engineer : dxm Submitter : dxm Opened Date : 09/17/00 *Closed Date : 09/25/00 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 09/25/00 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Sep 25 2000 05:59:42PM ========================== Modid: 2.4.x-xfs:slinx:75004a Date: Mon Sep 25 17:59:23 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-tot Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/fs/xfs/xfs_log.c - 1.224 - pv 802017 ASSERT that xlog_get_bp doesn't fail. linux/fs/xfs/xfs_log_recover.c - 1.191 - pv 802017 Remove need for large buffers during log recovery From owner-linux-xfs@oss.sgi.com Mon Sep 25 19:05:59 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 19:05:49 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:36710 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 19:05:29 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA25002; Mon, 25 Sep 2000 18:56:55 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA01010; Mon, 25 Sep 2000 19:04:33 -0700 (PDT) Date: Mon, 25 Sep 2000 19:04:33 -0700 (PDT) Message-Id: <200009260204.TAA01010@info.engr.sgi.com> X-Pv-Incident: 801066 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 801066 - Extra unneeded endian flipping in XFS code To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801066 *Status : closed Priority : 3 Assigned Engineer : dxm Submitter : lord Opened Date : 09/06/00 *Closed Date : 09/25/00 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 09/25/00 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Sep 25 2000 07:04:33PM ========================== Modid: 2.4.x-xfs:slinx:75007a Date: Mon Sep 25 19:03:57 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-tot Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/dump/common/arch_xlate.c - 1.4 cmd/xfs/include/xfs_arch.h - 1.4 cmd/xfs/include/xfs_ialloc_btree.h - 1.2 cmd/xfs/libxfs/xfs_alloc.c - 1.3 cmd/xfs/libxfs/xfs_alloc_btree.c - 1.2 cmd/xfs/libxfs/xfs_da_btree.c - 1.3 cmd/xfs/libxfs/xfs_dir2_data.c - 1.2 cmd/xfs/libxfs/xfs_dir2_leaf.c - 1.2 cmd/xfs/libxfs/xfs_dir2_node.c - 1.3 cmd/xfs/libxfs/xfs_dir_leaf.c - 1.2 cmd/xfs/libxfs/xfs_ialloc.c - 1.2 cmd/xfs/libxfs/xfs_ialloc_btree.c - 1.2 cmd/xfs/libxfs/xfs_inode.c - 1.5 cmd/xfs/libxfs/xfs_mount.c - 1.2 cmd/xfs/repair/dinode.c - 1.82 linux/fs/xfs/xfs_alloc.c - 1.136 linux/fs/xfs/xfs_alloc_btree.c - 1.64 linux/fs/xfs/xfs_arch.h - 1.30 linux/fs/xfs/xfs_da_btree.c - 1.113 linux/fs/xfs/xfs_dir2_data.c - 1.13 linux/fs/xfs/xfs_dir2_leaf.c - 1.17 linux/fs/xfs/xfs_dir2_node.c - 1.17 linux/fs/xfs/xfs_dir_leaf.c - 1.90 linux/fs/xfs/xfs_ialloc.c - 1.141 linux/fs/xfs/xfs_ialloc_btree.c - 1.62 linux/fs/xfs/xfs_ialloc_btree.h - 1.20 linux/fs/xfs/xfs_inode.c - 1.304 linux/fs/xfs/xfs_mount.c - 1.240 - pv 801066 From owner-linux-xfs@oss.sgi.com Mon Sep 25 20:49:20 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 20:49:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:20595 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 20:48:36 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA01640; Mon, 25 Sep 2000 20:40:12 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA92383; Mon, 25 Sep 2000 20:47:52 -0700 (PDT) Date: Mon, 25 Sep 2000 20:47:52 -0700 (PDT) Message-Id: <200009260347.UAA92383@info.engr.sgi.com> X-Pv-Incident: 802017 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 802017 - ASSERT fail in xlog_get_bp on small mem machine To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017 Status : closed Priority : 3 Assigned Engineer : dxm Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : I haven't seen this problem for ages on my 64Mb crash box, but the problem is still there. I installed XFS on my home machine last night and was very happy with its performance (P100, 32Mb RAM, 32Gb disk) until I tried to cleanly remount my XFS partition and tripped an ASSERT in xlog_get_bp. My home machine is very tight on memory, but I don't think it's an unreasonable machine to try to run XFS on. Unfortunately, ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Sep 25 2000 08:47:51PM ========================== Copy kernel changes into userspace. Modid: 2.4.x-xfs:slinx:75010a Date: Mon Sep 25 20:44:29 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-tot Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/logprint/xfs_log_recover.c - 1.3 - match kernel changes From owner-linux-xfs@oss.sgi.com Mon Sep 25 21:59:20 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 21:59:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:26491 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 21:58:42 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA05956; Mon, 25 Sep 2000 21:50:28 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id VAA00343; Mon, 25 Sep 2000 21:57:40 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id VAA04667; Mon, 25 Sep 2000 21:55:03 -0700 (PDT) Date: Mon, 25 Sep 2000 21:55:03 -0700 (PDT) Message-Id: <200009260455.VAA04667@feature.engr.sgi.com> X-Pv-Incident: 801764 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (nathans@engr.sgi.com) Subject: TAKE 801764 - xfs_check and xfs_repair should fail if device mounted To: nathans@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : dxm *Status : closed Assigned Engineer : nathans *Fixed By : nathans *Fixed By Domain : engr *Closed Date : 09/25/00 Priority : 4 *Modified Date : 09/25/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : From: nathan scott (TAKE) Date: Sep 17 2000 10:15:04PM [pvnews version: 1.71] ---------------------------- Got the green light for this to go into beta. Also rolled the version number for xfs-cmds to 1.0.5 for official beta. Modid: 2.4.0-test1-xfs:slinx:74557a Date: Sun Sep 17 22:09:48 PDT 2000 ..... ========================== ADDITIONAL INFORMATION (TAKE) From: nathan scott Date: Sep 25 2000 09:55:03PM [pvnews version: 1.71] ========================== Modid: 2.4.x-xfs:slinx:75011a Date: Mon Sep 25 21:51:06 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/db/init.c - 1.29 cmd/xfs/db/xfs_check.sh - 1.7 cmd/xfs/db/xfs_check64.sh - 1.5 cmd/xfs/include/libxfs.h - 1.18 cmd/xfs/libxfs/init.c - 1.13 cmd/xfs/logprint/logprint.c - 1.49 cmd/xfs/repair/init.c - 1.15 - where it matters, allow tools to specify whether a filesystem may be mounted, mounted ro, or mounted rw before starting - different tools have different needs. new isinactive flag to libxfs, in combination with existing isreadonly, provides this functionality. Description : both "xfs_check" and "xfs_repair -n" may be run on a mounted filesystem and will usually produce lots of warnings about filesystem corruption due to the inconsistent state the FS is in. Both tools should fail or at least warn that the FS is mounted before proceeding. xfs_logprint should also warn when run on a mounted FS, but can still be useful when mounted. ..... ========================== ADDITIONAL INFORMATION (REOPEN) From: nathans@engr (BugWorks) Date: Sep 17 2000 11:09:28PM ========================== I've backed this fix out... it works but is too simplistic an approach for the general case. We should allow these tools to run on a filesystem which is mounted read-only - this change currently disallows _all_ mounted filesystems, which is too strict. From owner-linux-xfs@oss.sgi.com Mon Sep 25 22:50:10 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 22:50:01 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12381 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 22:49:42 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA06726 for ; Mon, 25 Sep 2000 22:56:04 -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 QAA69038 for linux-xfs@oss.sgi.com; Tue, 26 Sep 2000 16:47:53 +1100 (EST) Date: Tue, 26 Sep 2000 16:47:53 +1100 (EST) From: Nathan Scott Message-Id: <200009260547.QAA69038@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Some followon pseudo-inc cleanup after removing SIM macros. These files have now been removed completely, merged with others, or slimmed down and moved closer to their associated .c files... pseudo-inc/sys/cmn_err.h pseudo-inc/sys/debug.h pseudo-inc/sys/fs_subr.h pseudo-inc/sys/param.h pseudo-inc/sys/pathname.h pseudo-inc/sys/pvfs.h pseudo-inc/sys/systm.h pseudo-inc/sys/types.h pseudo-inc/sys/uio.h pseudo-inc/sys/uuid.h pseudo-inc/sys/vfs.h pseudo-inc/sys/vnode.h xfs_os_defs.h Modid: 2.4.x-xfs:slinx:75012a Date: Mon Sep 25 22:02:06 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/fs/xfs/linux/Makefile - 1.25 - merge uaccess and move .c files - do similar stuff. linux/fs/xfs/linux/xfs_debug.h - 1.2 - keep the cmn_err routines & macros together. linux/fs/xfs/linux/xfs_linux.h - 1.29 - rationalise includes, types, macros from several generic headers into one semi-coherent header. linux/fs/xfs/linux/xfs_move.c - 1.13 - merge uaccess and move .c files - do similar stuff. linux/fs/xfs/linux/xfs_random.c - 1.46 - make a little less random - this is now kmem, procfs, ktrace stuff. linux/fs/xfs/linux/xfs_sema.h - 1.28 - remove pseudo-inc include. linux/fs/xfs/pseudo-inc/sys/file.h - 1.4 - remove dead code. linux/fs/xfs/pseudo-inc/sys/statvfs.h - 1.6 - move some typedefs only needed by this header's statvfs struct here. linux/fs/xfs/xfs.h - 1.2 - remove no longer needed pseudo-inc headers. linux/fs/xfs/xfs_itable.c - 1.94 - remove an extern in a .c file - sourced from a hdr now. linux/fs/xfs/linux/xfs_fs_subr.h - 1.1 linux/fs/xfs/linux/xfs_move.h - 1.1 linux/fs/xfs/linux/xfs_uuid.h - 1.1 linux/fs/xfs/linux/xfs_vfs.h - 1.1 linux/fs/xfs/linux/xfs_vnode.h - 1.1 - move from pseudo-inc to pair up with its .c file here. From owner-linux-xfs@oss.sgi.com Mon Sep 25 23:56:31 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 23:56:21 -0700 Received: from timbuk-fddi.cray.com ([128.162.8.102]:15754 "EHLO timbuk.mw.cray.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 23:55:48 -0700 Received: from relayb.cray.com (root@relayb.mw.cray.com [128.162.2.87]) by timbuk.mw.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id BAA00921 for ; Tue, 26 Sep 2000 01:55:16 -0500 (CDT) Received: from ironwood-e101.mw.cray.com (root@ironwood-e101.mw.cray.com [128.162.101.96]) by relayb.cray.com (8.11.0/8.10.1) with ESMTP id e8Q6qZi29915 for ; Tue, 26 Sep 2000 01:52:35 -0500 Received: from gibble.americas.sgi.com (gibble [128.162.195.80]) by ironwood-e101.mw.cray.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id BAA28181 for ; Tue, 26 Sep 2000 01:55:14 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e8Q6tEo03626 for linux-xfs@oss.sgi.com; Tue, 26 Sep 2000 01:55:14 -0500 Date: Tue, 26 Sep 2000 01:55:14 -0500 From: Russell Cattelan Message-Id: <200009260655.e8Q6tEo03626@gibble.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This file wasn't suppose to be deleted. Date: Mon Sep 25 23:54:55 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel Undoes mod: 2.4.x-xfs:slinx:75026a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:75031a linux/fs/xfs/xfs_os_defs.h - 1.15 From owner-linux-xfs@oss.sgi.com Tue Sep 26 00:57:22 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 00:57:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:8723 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 00:56:45 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA16860 for ; Tue, 26 Sep 2000 00:48:30 -0700 (PDT) mail_from (tes@sherman.melbourne.sgi.com) Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id SAA20309 for linux-xfs@oss.sgi.com; Tue, 26 Sep 2000 18:55:11 +1100 Date: Tue, 26 Sep 2000 18:55:11 +1100 From: Tim Shimmin Message-Id: <200009260755.SAA20309@sherman.melbourne.sgi.com> Subject: TAKE - stress/common.dump To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Use the new seq.notrun capability of stress/check so that xfsdump tests which don't have the needed tape drives can be shown as not having being run. --Tim Date: Tue Sep 26 00:51:39 PDT 2000 Workarea: sherman.melbourne.sgi.com:/hosts/snort/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:75032a cmd/xfs/stress/common.dump - 1.16 - Creates the seq.notrun file if the required tape is not specified, or not available or not online. Also creates fill'ed files with different owners/groups. cmd/xfs/stress/023 - 1.3 - Do a listing comparison as well as the recursive diff of contents. Previously we only did the ls comparison in 022 but do it for files created by stress/src/fill as well. cmd/xfs/stress/023.out - 1.5 - Adds listing comparison. From owner-linux-xfs@oss.sgi.com Tue Sep 26 07:59:34 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 07:59:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:54862 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 07:58:52 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA17645; Tue, 26 Sep 2000 07:50:32 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA38054; Tue, 26 Sep 2000 07:58:13 -0700 (PDT) Date: Tue, 26 Sep 2000 07:58:13 -0700 (PDT) Message-Id: <200009261458.HAA38054@info.engr.sgi.com> X-Pv-Incident: 802340 webPV: fzr600.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (coreym@sgi.com) Subject: ADD 802340 - kernel panic To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802340 Status : open Priority : 1 Assigned Engineer : nb Submitter : coreym *Modified User : coreym *Modified User Domain : sgi.com *Description : I was running rwtest (doio and iogen) to stress xfs on tarpon and tarpon paniced. I have no way of knowing if it was related to my test or not. The panic string that I received was: Message from syslogd@tarpon at Fri Sep 15 11:49:03 2000 ... tarpon kernel: Kernel panic: kmem_alloc: NULL memory on KM_SLEEP request! ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (ADD) From: coreym@sgi.com (BugWorks) Date: Sep 26 2000 07:58:13AM ========================== There are 4 GB of memory on tarpon. The kernal was an updated 2.4. built while running our original 2.4. in an xfs filesystem. Lilo was then generated in that xfs system and written in xfs format. The mount command used was: mount -t xfs /dev/sdg1 /sdg From owner-linux-xfs@oss.sgi.com Tue Sep 26 09:43:36 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 09:43:25 -0700 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:51430 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 09:42:54 -0700 Received: from techno.informatik.uni-stuttgart.de (root@techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id SAA13039 for ; Tue, 26 Sep 2000 18:40:43 +0200 (MET DST) Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.9.3/2.2) id SAA31511 for linux-xfs@oss.sgi.com; Tue, 26 Sep 2000 18:42:21 +0200 Date: Tue, 26 Sep 2000 18:42:20 +0200 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Which version of stat is used for the stress tests? Message-ID: <20000926184220.A31300@techno.informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i X-Operating-System: Linux techno 2.2.13 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, Which version of stat is used to generate the input files for stress tests? After running the whole set, several ones report failure. Most of the problemas are related to the specific version of stat used to generate the validation data. Thanks, Marcelo From owner-linux-xfs@oss.sgi.com Tue Sep 26 12:12:36 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 12:12:26 -0700 Received: from [134.6.25.177] ([134.6.25.177]:18182 "EHLO maxtor.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 12:12:06 -0700 Received: from maxtor.com (IDENT:jd@localhost [127.0.0.1]) by maxtor.com (8.9.3/8.9.3) with ESMTP id MAA17857 for ; Tue, 26 Sep 2000 12:11:12 -0700 Message-ID: <39D0F4D0.E93A1A61@maxtor.com> Date: Tue, 26 Sep 2000 12:11:12 -0700 From: "Joseph I. Davida" Reply-To: joe_davida@maxtor.com X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: linux/fs/xfs/pseudo-inc/sys/types.h Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I just did a cvs update, and compilation failed because of this uncommented junk in linux/fs/xfs/pseudo-inc/sys/types.h: <<<<<<< types.h /* this might be wrong for linux! should be 0 */ /* defined in linux/kdev_t.h */ ======= >>>>>>> 1.20 From owner-linux-xfs@oss.sgi.com Tue Sep 26 13:20:27 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 13:20:16 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16420 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 13:19:54 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA03068 for ; Tue, 26 Sep 2000 13:26:17 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id PAA40440; Tue, 26 Sep 2000 15:17:57 -0500 (CDT) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id PAA46315; Tue, 26 Sep 2000 15:17:55 -0500 (CDT) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e8QKHtF05918; Tue, 26 Sep 2000 15:17:55 -0500 Message-ID: <39D10473.52CD800E@thebarn.com> Date: Tue, 26 Sep 2000 15:17:55 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: joe_davida@maxtor.com CC: linux-xfs@oss.sgi.com Subject: Re: linux/fs/xfs/pseudo-inc/sys/types.h References: <39D0F4D0.E93A1A61@maxtor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Joseph I. Davida" wrote: > I just did a cvs update, and compilation failed > because of this uncommented junk in > linux/fs/xfs/pseudo-inc/sys/types.h: > > <<<<<<< types.h > /* this might be wrong for linux! should be 0 */ > /* defined in linux/kdev_t.h */ > ======= > >>>>>>> 1.20 I would re update your tree. You probably got the tree mid push. Also note depending upon your level of desired involvement. You may want to check out the linux-2.4-xfs-beta tree instead. that tree will remain more stationary and only receive well tested updates from the development tree. -Russell From owner-linux-xfs@oss.sgi.com Tue Sep 26 14:04:17 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 14:04:07 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17491 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 14:03:54 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA18531 for ; Tue, 26 Sep 2000 13:55:30 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02128; Wed, 27 Sep 2000 08:00:40 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA37944; Wed, 27 Sep 2000 08:00:38 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009270800.ZM37948@wobbly.melbourne.sgi.com> Date: Wed, 27 Sep 2000 08:00:36 -0400 In-Reply-To: "Joseph I. Davida" "linux/fs/xfs/pseudo-inc/sys/types.h" (Sep 26, 12:11pm) References: <39D0F4D0.E93A1A61@maxtor.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: joe_davida@maxtor.com, linux-xfs@oss.sgi.com Subject: Re: linux/fs/xfs/pseudo-inc/sys/types.h Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Sep 26, 12:11pm, Joseph I. Davida wrote: > Subject: linux/fs/xfs/pseudo-inc/sys/types.h > I just did a cvs update, and compilation failed > because of this uncommented junk in > linux/fs/xfs/pseudo-inc/sys/types.h: > this file no longer exists in the development tree (several other pseudo-inc headers were also removed yesterday). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 26 16:57:47 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 16:57:28 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58374 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 16:57:09 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA11422 for ; Tue, 26 Sep 2000 16:49:25 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA83091 for linux-xfs@oss.sgi.com; Wed, 27 Sep 2000 10:55:49 +1100 (EST) Date: Wed, 27 Sep 2000 10:55:49 +1100 (EST) From: Daniel Moore Message-Id: <200009262355.KAA83091@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:75074a Date: Tue Sep 26 16:55:35 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/stress/common.config - 1.7 - reconfig leesa cmd/xfs/stress/common.rc - 1.33 - turn off remount ro/rw in check_fs and use unmount/mount instead cmd/xfs/stress/group - 1.41 - add 040, add 016 & 017 to auto group cmd/xfs/tools/srcdiff - 1.8 - add -q flag for quiet mode cmd/xfs/stress/040 - 1.1 - check output from srcdiff cmd/xfs/stress/040.out - 1.1 - output for 040 From owner-linux-xfs@oss.sgi.com Tue Sep 26 17:07:47 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 17:07:38 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:61448 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 17:07:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA12403 for ; Tue, 26 Sep 2000 16:59:32 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03382; Wed, 27 Sep 2000 11:05:58 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA38376; Wed, 27 Sep 2000 11:05:56 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009271105.ZM37848@wobbly.melbourne.sgi.com> Date: Wed, 27 Sep 2000 11:05:55 -0400 In-Reply-To: "Marcelo E. Magallon" "Which version of stat is used for the stress tests?" (Sep 26, 6:42pm) References: <20000926184220.A31300@techno.informatik.uni-stuttgart.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Marcelo E. Magallon" , linux-xfs@oss.sgi.com Subject: Re: Which version of stat is used for the stress tests? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sep 26, 6:42pm, Marcelo E. Magallon wrote: > Subject: Which version of stat is used for the stress tests? > Hi, > > Which version of stat is used to generate the input files for > stress tests? After running the whole set, several ones report > failure. Most of the problemas are related to the specific version of > stat used to generate the validation data. > I believe most of us are using: $ rpm -q stat stat-1.5-12 and not seeing any problems with it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 26 17:29:37 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 17:29:27 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:35852 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 17:29:05 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA14244 for ; Tue, 26 Sep 2000 17:21:20 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA65535 for linux-xfs@oss.sgi.com; Wed, 27 Sep 2000 11:27:45 +1100 (EST) Date: Wed, 27 Sep 2000 11:27:45 +1100 (EST) From: Nathan Scott Message-Id: <200009270027.LAA65535@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - man Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:75082a Date: Tue Sep 26 17:27:18 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/man/man8/xfs_db.8 - 1.3 - add some text about the -i option. From owner-linux-xfs@oss.sgi.com Tue Sep 26 18:14:08 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 18:13:48 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14397 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 18:13:18 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA09158 for ; Tue, 26 Sep 2000 18:20:11 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA30388 for linux-xfs@oss.sgi.com; Wed, 27 Sep 2000 12:11:58 +1100 (EST) Date: Wed, 27 Sep 2000 12:11:58 +1100 (EST) From: Timothy Shimmin Message-Id: <200009270111.MAA30388@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - README.xfsdump Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Mention a workaround to a bug in xfsrestore (-J option) which will happen when restoring onto a host without any on-disk inventory. A typical scenario is when restoring an IRIX tape onto Linux. This will not happen in typical life as one usually does an xfsdump first which updates the on-disk inventory. It's kind of a reincarnation of SGI bug#513879. I'm fixing it for the next release... A note has been passed on for the beta caveats.html doc. --Tim Modid: 2.4.x-xfs-beta:slinx:75089a Date: Tue Sep 26 18:03:31 PDT 2000 Workarea: snort:/build4/tes/slinx-xfs-beta Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-beta cmd/xfs/doc/README.xfsdump - 1.2 - Minor changes + add workaround for xfsrestore bug which is likely to crop up when one tries to restore from IRIX xfs dump tape onto Linux. From owner-linux-xfs@oss.sgi.com Tue Sep 26 19:18:18 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 19:18:08 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:19998 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 19:17:48 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA22913 for ; Tue, 26 Sep 2000 19:10:03 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA04181; Wed, 27 Sep 2000 13:15:13 +1100 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id NAA10357; Wed, 27 Sep 2000 13:15:11 +1100 (EST) Message-Id: <200009270215.NAA10357@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: cattelan@thebarn.com cc: linux-xfs@oss.sgi.com Subject: More Caveats Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Sep 2000 13:15:11 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing (the loopback item is mentioned already , but I think it should be more explicit - the first thing I tried to do with XFS was to get it going on a loopback mount) * External logs The current external log format is not compatible with IRIX and will be changed in the next release. * Mounting on low-memory systems (~ < 64Mb) Log mount/recovery may fail on low-memory systems. This problem is fixed in the development version and will be fixed in the next release. * XFS_(UN)?IOC_RESVSP(64)? ioctls There is a known problem with these ioctls and their use is not recommended at the moment. * XFS on loopback mount XFS does not work on a loopback mount and will most likely cause a kernel panic. * fsr and growfs Both the fsr and growfs tools are work-in-progress and as such should not be used. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Sep 26 20:17:28 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 20:17:08 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:27941 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 20:16:43 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA26871 for ; Tue, 26 Sep 2000 20:08:51 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA04493; Wed, 27 Sep 2000 14:15:17 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA37365; Wed, 27 Sep 2000 14:15:14 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009271415.ZM37583@wobbly.melbourne.sgi.com> Date: Wed, 27 Sep 2000 14:15:11 -0400 In-Reply-To: Daniel Moore "More Caveats" (Sep 27, 1:15pm) References: <200009270215.NAA10357@clouds.melbourne.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: cattelan@thebarn.com Subject: Re: More Caveats Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sep 27, 1:15pm, Daniel Moore wrote: > Subject: More Caveats > One other thing may be worth mentioning - e2fsprogs-devel version 1.19 was released awhile ago. I had a look through the changelog at the time & there didn't seem to be any change that would affect the XFS commands at all (was one uuid related change but couldn't see a way it could affect xfs-cmds). It may be worthwhile making the rpm available along with the other xfs-cmds rpms/tarballs on oss, as was done for 1.18, for people building the tools themselves. Various versions can be found here... http://rpmfind.net/linux/rpm2html/search.php?query=e2fsprogs-devel cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 26 20:49:27 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 20:49:17 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:12818 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 20:48:57 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e8R3moa77689; Tue, 26 Sep 2000 22:48:50 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39D16E22.F4532EFC@thebarn.com> Date: Tue, 26 Sep 2000 22:48:50 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: More Caveats References: <200009270215.NAA10357@clouds.melbourne.sgi.com> <10009271415.ZM37583@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Nathan Scott wrote: > On Sep 27, 1:15pm, Daniel Moore wrote: > > Subject: More Caveats > > > > One other thing may be worth mentioning - e2fsprogs-devel > version 1.19 was released awhile ago. I had a look through > the changelog at the time & there didn't seem to be any > change that would affect the XFS commands at all (was one > uuid related change but couldn't see a way it could affect > xfs-cmds). > > It may be worthwhile making the rpm available along with > the other xfs-cmds rpms/tarballs on oss, as was done for > 1.18, for people building the tools themselves. I had a discussion with Tom Duffy about this. ProPack 1.4 does NOT include a version of e2fsprogs. his take was that if anything that doesn't need upgrading and is on the RH6.2 disc then is wasn't included in ProPack. Note I did feel as a matter of convenience that it would be a good idea for the XFS beta to install e2fsprogs; so it is included on the iso image. But I think Tom is right in that unless there is a clear need for an upgraded version we shouldn't get into the upgrade for the sake of upgrade business. > > Various versions can be found here... > http://rpmfind.net/linux/rpm2html/search.php?query=e2fsprogs-devel > > cheers. > > -- > Nathan -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Sep 26 20:55:47 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 20:55:38 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8003 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 20:55:31 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id VAA07772 for ; Tue, 26 Sep 2000 21:02:24 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA04686; Wed, 27 Sep 2000 14:54:12 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA36682; Wed, 27 Sep 2000 14:54:10 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009271454.ZM31447@wobbly.melbourne.sgi.com> Date: Wed, 27 Sep 2000 14:54:08 -0400 In-Reply-To: Russell Cattelan "Re: More Caveats" (Sep 26, 10:48pm) References: <200009270215.NAA10357@clouds.melbourne.sgi.com> <10009271415.ZM37583@wobbly.melbourne.sgi.com> <39D16E22.F4532EFC@thebarn.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: cattelan@thebarn.com Subject: Re: More Caveats Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Sep 26, 10:48pm, Russell Cattelan wrote: > Subject: Re: More Caveats > ... > I had a discussion with Tom Duffy about this. > ProPack 1.4 does NOT include a version of e2fsprogs. > his take was that if anything that doesn't need upgrading and > is on the RH6.2 disc then is wasn't included in ProPack. > Note I did feel as a matter of convenience that it would be a good > idea for the XFS beta to install e2fsprogs; so it is included on the > iso image. e2fsprogs is a different kettle of fish to e2fsprogs-devel. > > But I think Tom is right in that unless there is a clear need for > an upgraded version we shouldn't get into the upgrade for the > sake of upgrade business. > yup, I agree too - xfs-cmds has no dependence on, or relationship to, e2fsprogs at all - so we have no business messin' with it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 26 22:59:52 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 22:59:31 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45895 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 22:59:06 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA04510 for ; Tue, 26 Sep 2000 23:05:58 -0700 (PDT) mail_from (tes@sherman.melbourne.sgi.com) Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA15929 for linux-xfs@oss.sgi.com; Wed, 27 Sep 2000 16:58:02 +1100 Date: Wed, 27 Sep 2000 16:58:02 +1100 From: Tim Shimmin Message-Id: <200009270558.QAA15929@sherman.melbourne.sgi.com> Subject: TAKE - xfsrestore To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Fixes xfsrestore bug where xfsrestore will core dump when restoring a dump onto a host without the on-disk inventory. --Tim Date: Tue Sep 26 22:55:44 PDT 2000 Workarea: sherman.melbourne.sgi.com:/hosts/snort/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:75100a cmd/xfs/stress/043 - 1.1 cmd/xfs/stress/043.out - 1.1 - Test out the bug where xfsrestore crashes trying to restore the inventory from the tape when no inventory exists on disk. cmd/xfs/stress/group - 1.43 - Add 043. cmd/xfs/dump/inventory/inv_api.c - 1.10 - Change inv_put_sessioninfo to take a inv_sessinfo_t structure as a parameter instead of a buffer. By doing this it means that we don't need to decode the buffer in more places unnecessarily. In particular it means that we can prevent the endian conversion from happening more than once. cmd/xfs/dump/inventory/inv_mgr.c - 1.9 - Change insert_session to take a invt_sessinfo_t structure instead of a buffer. The unpacking of the buffer can be handled prior to calling this function. cmd/xfs/dump/inventory/inv_priv.h - 1.7 - Change the insert_session() prototype to use invt_sessinfo_t. Move inv_put_sessioninfo() into here from inventory.h as we need the typedef for invt_sessinfo_t. cmd/xfs/dump/inventory/inventory.h - 1.6 - Moved inv_put_sessioninfo() to inv_priv.h because we need the invt_sessinfo_t structure and we can't have cyclic includes. cmd/xfs/dump/restore/content.c - 1.16 - To the unpacking of the sessinfo in the one place instead of twice by having it buried in a couple of other functions. cmd/xfs/dump/common/arch_xlate.c - 1.5 - Add some diagnostics (mlogs) to see the invt_session data before and after endian translation. A bug was uncovered where this function was getting called twice. From owner-linux-xfs@oss.sgi.com Tue Sep 26 23:11:52 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 23:11:42 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:19475 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 23:11:16 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e8R6BBa94645; Wed, 27 Sep 2000 01:11:12 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39D18F7E.3D927EFA@thebarn.com> Date: Wed, 27 Sep 2000 01:11:10 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: root CC: linux-xfs@oss.sgi.com Subject: Re: mkfs -t xfs ... core dump References: <39D1266C.DFD7B58B@maxtor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing root wrote: Did you do a make clean before rebuilding the xfs commands? There was a problem at one point where a make in the cmd/xfs dir would produce bad binaries, this was fixed some time ago. > Running with latest build of 2.4.0-test5 > > # mkfs -t xfs /dev/rd/c0d0 > mkfs.xfs: warning - cannot set blocksize on block device /dev/rd/c0d0: I suspect this is cause what kind of device is /dev/rd/c0d0? > > Invalid argument > meta-data=/dev/rd/c0d0 isize=256 agcount=420, agsize=261888 > blks > data = bsize=4096 blocks=109992960, > 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 > > Memory fault (core dumped) > > Attached are mkfs.xfs, and the core file. > > Cheers, > > Joe > > ------------------------------------------------------------------------ > Name: mkfs.xfs > mkfs.xfs Type: unspecified type (application/octet-stream) > Encoding: base64 > Download Status: Not downloaded with message > > Name: mkfs.xfs.core > mkfs.xfs.core Type: unspecified type (application/octet-stream) > Encoding: base64 > Download Status: Not downloaded with message -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Wed Sep 27 07:19:12 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 07:19:03 -0700 Received: from hermes.mixx.net ([212.84.196.2]:57349 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 27 Sep 2000 07:18:51 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 6FFD7F81B for ; Wed, 27 Sep 2000 16:18:49 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 207032CA6D; Wed, 27 Sep 2000 16:18:49 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: nfs fix for test5 Date: 27 Sep 2000 14:18:48 GMT Organization: innominate AG, Berlin, Germany Lines: 47 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 970064328 15956 10.0.0.69 (27 Sep 2000 14:18:48 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test5 (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing the following patch fixes a small nfs problem in -test5 (on which the SGI XFS tree is currently based and which is fixed in later test versions) ... it manifests itself in the fact that you have problems writing big files with your machine being nfs client ... maybe it's worth to add it to the tree as long as it stays at -test5 ... for me here (linux xfs kernel nfs client to an linux normal nfs server) this is the only way to really use this kernel in this envirnonment and it might be the case for other beta tester too (btw. the patch comes from the linux nfs mailinglist) hope that helps t p.s.: ... and now the patch Index: write.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/nfs/write.c,v retrieving revision 1.18 diff -u -r1.18 write.c --- write.c 2000/06/02 00:22:59 1.18 +++ write.c 2000/09/27 14:06:28 @@ -1294,7 +1294,7 @@ struct nfs_page *req; struct dentry *dentry; struct inode *inode; - loff_t start, end, len; + u64 start, end, len; /* Set up the RPC argument and reply structs * NB: take care not to mess about with data->commit et al. */ @@ -1308,7 +1308,7 @@ inode = dentry->d_inode; while (!list_empty(head)) { struct nfs_page *req; - loff_t rqstart, rqend; + u64 rqstart, rqend; req = nfs_list_entry(head->next); nfs_list_remove_request(req); nfs_list_add_request(req, &data->pages); -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Sep 27 07:20:33 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 07:20:13 -0700 Received: from hermes.mixx.net ([212.84.196.2]:59397 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 27 Sep 2000 07:20:01 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id CA806F81B for ; Wed, 27 Sep 2000 16:19:55 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 26EC52CA6D; Wed, 27 Sep 2000 16:19:55 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: nfs fix for test5 Date: 27 Sep 2000 14:19:55 GMT Organization: innominate AG, Berlin, Germany Lines: 60 Distribution: local Message-ID: References: <8qsvk8$fik$1@mate.bln.innominate.de> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 970064395 15956 10.0.0.69 (27 Sep 2000 14:19:55 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test5 (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing one simple side note tomake it more clear: this thing has nothing to do with XFS itself - only with the fact that the xfs tree currently uses the -test5 kernel which has this problem ... t Thomas Graichen wrote: > the following patch fixes a small nfs problem in -test5 (on which the > SGI XFS tree is currently based and which is fixed in later test > versions) ... it manifests itself in the fact that you have problems > writing big files with your machine being nfs client ... maybe it's > worth to add it to the tree as long as it stays at -test5 ... for me > here (linux xfs kernel nfs client to an linux normal nfs server) > this is the only way to really use this kernel in this envirnonment > and it might be the case for other beta tester too (btw. the patch > comes from the linux nfs mailinglist) > hope that helps > t > p.s.: ... and now the patch > Index: write.c > =================================================================== > RCS file: /cvs/linux-2.4-xfs/linux/fs/nfs/write.c,v > retrieving revision 1.18 > diff -u -r1.18 write.c > --- write.c 2000/06/02 00:22:59 1.18 > +++ write.c 2000/09/27 14:06:28 > @@ -1294,7 +1294,7 @@ > struct nfs_page *req; > struct dentry *dentry; > struct inode *inode; > - loff_t start, end, len; > + u64 start, end, len; > > /* Set up the RPC argument and reply structs > * NB: take care not to mess about with data->commit et al. */ > @@ -1308,7 +1308,7 @@ > inode = dentry->d_inode; > while (!list_empty(head)) { > struct nfs_page *req; > - loff_t rqstart, rqend; > + u64 rqstart, rqend; > req = nfs_list_entry(head->next); > nfs_list_remove_request(req); > nfs_list_add_request(req, &data->pages); > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Sep 27 07:23:12 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 07:23:03 -0700 Received: from Cantor.suse.de ([194.112.123.193]:30216 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 27 Sep 2000 07:22:46 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 0ADD11E116; Wed, 27 Sep 2000 16:22:44 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id C40803E44F; Wed, 27 Sep 2000 16:22:43 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 472462F300; Wed, 27 Sep 2000 16:22:43 +0200 (MEST) Date: Wed, 27 Sep 2000 16:22:43 +0200 From: "Andi Kleen" To: Thomas Graichen , thomas.graichen@innominate.de Cc: linux-xfs@oss.sgi.com Subject: Re: nfs fix for test5 Message-ID: <20000927162243.A6081@gruyere.muc.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from news-innominate.list.sgi.xfs@innominate.de on Wed, Sep 27, 2000 at 02:18:48PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Sep 27, 2000 at 02:18:48PM +0000, Thomas Graichen wrote: > Index: write.c > =================================================================== > RCS file: /cvs/linux-2.4-xfs/linux/fs/nfs/write.c,v > retrieving revision 1.18 > diff -u -r1.18 write.c > --- write.c 2000/06/02 00:22:59 1.18 > +++ write.c 2000/09/27 14:06:28 > @@ -1294,7 +1294,7 @@ > struct nfs_page *req; > struct dentry *dentry; > struct inode *inode; > - loff_t start, end, len; > + u64 start, end, len; Looks bogus, loff_t is already 64bits. -Andi From owner-linux-xfs@oss.sgi.com Wed Sep 27 07:38:32 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 07:38:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33635 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 07:38:00 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08192 for ; Wed, 27 Sep 2000 07:44:45 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA04426; Wed, 27 Sep 2000 09:35:42 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id JAA78890; Wed, 27 Sep 2000 09:35:42 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id JAA01289; Wed, 27 Sep 2000 09:31:11 -0500 Message-Id: <200009271431.JAA01289@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Andi Kleen" cc: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: nfs fix for test5 In-Reply-To: Message from "Andi Kleen" of "Wed, 27 Sep 2000 16:22:43 +0200." <20000927162243.A6081@gruyere.muc.suse.de> Date: Wed, 27 Sep 2000 09:31:11 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Wed, Sep 27, 2000 at 02:18:48PM +0000, Thomas Graichen wrote: > > Index: write.c > > =================================================================== > > RCS file: /cvs/linux-2.4-xfs/linux/fs/nfs/write.c,v > > retrieving revision 1.18 > > diff -u -r1.18 write.c > > --- write.c 2000/06/02 00:22:59 1.18 > > +++ write.c 2000/09/27 14:06:28 > > @@ -1294,7 +1294,7 @@ > > struct nfs_page *req; > > struct dentry *dentry; > > struct inode *inode; > > - loff_t start, end, len; > > + u64 start, end, len; > > Looks bogus, loff_t is already 64bits. > > > -Andi And I am still waiting for the coffee to kick in, but Andi is correct, this is already 64 bits, but it is signed, so there may be something in the change, was there any commentry with the original change? Steve p.s. Thomas, looks like I will be in Miami after all. From owner-linux-xfs@oss.sgi.com Wed Sep 27 09:39:53 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 09:39:43 -0700 Received: from hermes.mixx.net ([212.84.196.2]:8202 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 27 Sep 2000 09:39:21 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 2C096F884 for ; Wed, 27 Sep 2000 18:38:57 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id A8D462CA6D; Wed, 27 Sep 2000 18:38:56 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: nfs fix for test5 Date: 27 Sep 2000 16:38:56 GMT Organization: innominate AG, Berlin, Germany Lines: 44 Distribution: local Message-ID: References: <200009271431.JAA01289@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 970072736 9706 10.0.0.69 (27 Sep 2000 16:38:56 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test5 (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> On Wed, Sep 27, 2000 at 02:18:48PM +0000, Thomas Graichen wrote: >> > Index: write.c >> > =================================================================== >> > RCS file: /cvs/linux-2.4-xfs/linux/fs/nfs/write.c,v >> > retrieving revision 1.18 >> > diff -u -r1.18 write.c >> > --- write.c 2000/06/02 00:22:59 1.18 >> > +++ write.c 2000/09/27 14:06:28 >> > @@ -1294,7 +1294,7 @@ >> > struct nfs_page *req; >> > struct dentry *dentry; >> > struct inode *inode; >> > - loff_t start, end, len; >> > + u64 start, end, len; >> >> Looks bogus, loff_t is already 64bits. >> >> >> -Andi > And I am still waiting for the coffee to kick in, but Andi is correct, this > is already 64 bits, but it is signed, so there may be something in the change, > was there any commentry with the original change? but it makes a difference - without i can't for instance do a dd if=/dev/zero of=testfile on an mounted dir with it works fine ... so there is something in it you may find the whole thread at http://www.geocrawler.com/search/?config=789&words=%222.4.0-test5+client%22 > p.s. Thomas, looks like I will be in Miami after all. that sounds fine t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Sep 27 12:02:14 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 12:02:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:21262 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 12:01:38 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA07536; Wed, 27 Sep 2000 11:53:55 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id MAA24645; Wed, 27 Sep 2000 12:01:36 -0700 (PDT) Date: Wed, 27 Sep 2000 12:01:36 -0700 (PDT) Message-Id: <200009271901.MAA24645@info.engr.sgi.com> X-Pv-Incident: 803065 webPV: fzr600.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (coreym@sgi.com) Subject: BUG 803065 - Data corruption while running rwtest To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803065 Submitter : coreym Submitter Domain : sgi.com Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : I was running rwtest on permit and got a data comparison error. Here is the output and related information: [root@permit /mnt]# rwtest iogen 1000000b:rwtest.file | doio -av iogen starting up with the following: Out-pipe: stdout Iterations: Infinite Seed: 1013 Offset-Mode: sequential Overlap Flag: off Mintrans: 1 (1 blocks) Maxtrans: 131072 (256 blocks) O_RAW/O_SSD Multiple: (Determined by device) Syscalls: read write readv writev mmread mmwrite Aio completion types: none Flags: buffered sync Test Files: Path Length iou raw iou file (bytes) (bytes) (bytes) type ----------------------------------------------------------------------------- /mnt/rwtest.file 512000000 1 512 regular doio ( 1012) 23:48:02 --------------------- *** DATA COMPARISON ERROR *** check_file(/mnt/rwtest.file, 323575586, 104613, U:1012:permit:doio*, 19, 0) failed Comparison fd is 5, with open flags 0 Corrupt regions follow - unprintable chars are represented as '.' ----------------------------------------------------------------- corrupt bytes starting at file offset 323575586 1st 32 expected bytes: U:1012:permit:doio*U:1012:permit 1st 32 actual bytes: mit:doio*J:1073:permit:doio*J:10 Request number 1443612 fd 8 is file /mnt/rwtest.file - open flags are 010002 O_RDWR,O_SYNC, write done at file offset 323575586 - pattern is U (0125) number of requests is 1, strides per request is 1 i/o byte count = 104613 memory alignment is unaligned syscall: mmap-write(NULL, 512000000, PROT_WRITE, MAP_SHARED, 8, 0) file is mmaped to: 0x9b8d8000 file-mem=0xaed6df22, length=104613, buffer=0xba120008 rwtest : iogen reported errors (r=141) From owner-linux-xfs@oss.sgi.com Wed Sep 27 12:07:14 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 12:06:53 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38924 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 12:06:50 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA07431; Wed, 27 Sep 2000 12:13:45 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id MAA28432; Wed, 27 Sep 2000 12:06:49 -0700 (PDT) Date: Wed, 27 Sep 2000 12:06:49 -0700 (PDT) Message-Id: <200009271906.MAA28432@info.engr.sgi.com> X-Pv-Incident: 803065 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 803065 - Data corruption while running rwtest To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803065 Status : open Priority : 2 Assigned Engineer : nb Submitter : coreym *Modified User : lord *Modified User Domain : sgi.com *Description : I was running rwtest on permit and got a data comparison error. Here is the output and related information: [root@permit /mnt]# rwtest iogen 1000000b:rwtest.file | doio -av iogen starting up with the following: ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Sep 27 2000 12:06:48PM ========================== what mount options please - it matters for this. Also, where did the iogen/doio commands come from, I suspect there are versions with different sets of things turned on for Linux. Steve From owner-linux-xfs@oss.sgi.com Wed Sep 27 12:27:44 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 12:27:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:30742 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 12:26:58 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA11458; Wed, 27 Sep 2000 12:19:14 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id MAA36946; Wed, 27 Sep 2000 12:26:56 -0700 (PDT) Date: Wed, 27 Sep 2000 12:26:56 -0700 (PDT) Message-Id: <200009271926.MAA36946@info.engr.sgi.com> X-Pv-Incident: 803065 webPV: fzr600.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (coreym@sgi.com) Subject: ADD 803065 - Data corruption while running rwtest To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803065 Status : open Priority : 2 Assigned Engineer : nb Submitter : coreym *Modified User : coreym *Modified User Domain : sgi.com *Description : I was running rwtest on permit and got a data comparison error. Here is the output and related information: [root@permit /mnt]# rwtest iogen 1000000b:rwtest.file | doio -av iogen starting up with the following: ..... ========================== ADDITIONAL INFORMATION (ADD) From: coreym@sgi.com (BugWorks) Date: Sep 27 2000 12:26:55PM ========================== The mount command line used was: mount -t xfs /dev/sdd /mnt The iogen/doio commands came from: /usr/tests/rts/bin/ From owner-linux-xfs@oss.sgi.com Wed Sep 27 13:35:04 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 13:34:44 -0700 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:906 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 13:34:33 -0700 Received: from rock.informatik.uni-stuttgart.de (root@rock [129.69.215.43]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id WAA07294 for ; Wed, 27 Sep 2000 22:32:50 +0200 (MET DST) Received: (from magallon@localhost) by rock.informatik.uni-stuttgart.de (8.9.3/2.2) id WAA06537; Wed, 27 Sep 2000 22:34:29 +0200 Date: Wed, 27 Sep 2000 22:25:53 +0200 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: Which version of stat is used for the stress tests? Message-ID: <20000927222553.A1549@ysabell> References: <20000926184220.A31300@techno.informatik.uni-stuttgart.de> <10009271105.ZM37848@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <10009271105.ZM37848@wobbly.melbourne.sgi.com>; from nathans@wobbly.melbourne.sgi.com on Wed, Sep 27, 2000 at 11:05:55AM -0400 Mail-Followup-To: linux-xfs@oss.sgi.com X-Operating-System: Linux ysabell 2.4.0-test9 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >> Nathan Scott writes: > I believe most of us are using: > > $ rpm -q stat > stat-1.5-12 > > and not seeing any problems with it. Yes, I can imagine that. Could you please note this somewhere? There are two versions of stat(1) floating arround, one is included with RH, one is included with Debian. Their output is slightly different, thus making it difficult to get any useful information from the stress test scripts. I've already patched a bunch of them, but most of them *really* depend of the output format of the version included with RH (which, I must note, does not have any license whatsoever) TIA, Marcelo From owner-linux-xfs@oss.sgi.com Wed Sep 27 17:02:14 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 17:01:54 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49451 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 17:01:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA06406 for ; Wed, 27 Sep 2000 17:08:45 -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 LAA42213 for linux-xfs@oss.sgi.com; Thu, 28 Sep 2000 11:00:31 +1100 (EST) Date: Thu, 28 Sep 2000 11:00:31 +1100 (EST) From: Nathan Scott Message-Id: <200009280000.LAA42213@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - stress Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:75157a Date: Wed Sep 27 16:57:32 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/stress/002 - 1.3 cmd/xfs/stress/019 - 1.8 - use lstat64, not stat. cmd/xfs/stress/019.out - 1.6 - different output for lstat64 - no longer attempt to massage stat(1) output into a common format & use lstat(2), not stat(2) to see symlink info. cmd/xfs/stress/src/Makefile - 1.16 - add lstat64. cmd/xfs/stress/src/lstat64.c - 1.1 - a syscall wrapper more suited to our needs & dodge the stat(1) format differences. From owner-linux-xfs@oss.sgi.com Wed Sep 27 17:15:24 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 17:15:14 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:34348 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 17:15:02 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA04206 for ; Wed, 27 Sep 2000 17:21:55 -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 LAA27938 for linux-xfs@oss.sgi.com; Thu, 28 Sep 2000 11:12:27 +1100 (EST) Date: Thu, 28 Sep 2000 11:12:27 +1100 (EST) From: Nathan Scott Message-Id: <200009280012.LAA27938@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:75159a Date: Wed Sep 27 17:11:43 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/fs/xfs/linux/xfs_iops.c - 1.72 - remove unused headers. linux/fs/xfs/linux/xfs_linux.h - 1.30 - merge in some types and macros which irix provided via sys headers needed by xfs. linux/fs/xfs/linux/xfs_lrw.c - 1.56 linux/fs/xfs/linux/xfs_mount_opt.c - 1.14 - remove unused headers. linux/fs/xfs/linux/xfs_random.c - 1.47 - update a comment. linux/fs/xfs/linux/xfs_super.c - 1.91 linux/fs/xfs/linux/xfs_vfs.c - 1.19 - remove unused headers. linux/fs/xfs/linux/xfs_vnode.h - 1.2 - merge in last couple of vnode-related types & macros. linux/fs/xfs/xfs.h - 1.3 - remove unused headers. From owner-linux-xfs@oss.sgi.com Wed Sep 27 17:34:44 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 17:34:24 -0700 Received: from ing-mat.udec.cl ([152.74.217.2]:54782 "EHLO ing-mat.udec.cl") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 17:33:56 -0700 Received: from localhost by ing-mat.udec.cl (8.9.3/8.9.1) with ESMTP id UAA29110 for ; Wed, 27 Sep 2000 20:37:58 -0400 (CST) Date: Wed, 27 Sep 2000 20:37:58 -0400 (CST) From: Claudio Baeza R To: linux-xfs@oss.sgi.com Subject: RedHat 7.0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, somebody has installed XFS in RedHat-7.0 ? claudio From owner-linux-xfs@oss.sgi.com Wed Sep 27 19:32:36 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 19:32:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:16392 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 19:32:08 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA02953 for ; Wed, 27 Sep 2000 19:24:23 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id VAA94278; Wed, 27 Sep 2000 21:30:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id VAA68216; Wed, 27 Sep 2000 21:30:46 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id VAA30843; Wed, 27 Sep 2000 21:26:15 -0500 Message-Id: <200009280226.VAA30843@jen.americas.sgi.com> To: Claudio Baeza R cc: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 From: lord@sgi.com In-reply-to: Your message of "Wed, 27 Sep 2000 20:37:58 EDT Date: Wed, 27 Sep 2000 21:26:15 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Hello, > > somebody has installed XFS in RedHat-7.0 ? > > > claudio Not within SGI, although we do have someone with redhat 7.0 on their machine now, so it is only a matter of time - Eric are you listening? Steve From owner-linux-xfs@oss.sgi.com Wed Sep 27 21:29:55 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 21:29:45 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45622 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 21:29:29 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA06775 for ; Wed, 27 Sep 2000 21:36:21 -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 PAA09704 for linux-xfs@oss.sgi.com; Thu, 28 Sep 2000 15:26:50 +1100 (EST) Date: Thu, 28 Sep 2000 15:26:50 +1100 (EST) From: Nathan Scott Message-Id: <200009280426.PAA09704@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing last for awhile... Modid: 2.4.x-xfs:slinx:75177a Date: Wed Sep 27 21:14:43 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/fs/xfs/linux/xfs_linux.h - 1.31 - minor - add some stub macros, remove some unused macros, add a couple of function prototypes that had nowhere else to go (qsort,...). linux/fs/xfs/linux/xfs_lrw.c - 1.57 - remove bogus, unused extern. linux/fs/xfs/xfs_bmap.h - 1.75 linux/fs/xfs/linux/xfs_super.h - 1.4 - make sure we declare all of our routines which other files access. linux/fs/xfs/xfs.h - 1.4 - bit of header file churn - remove 5, add 3. linux/fs/xfs/xfs_attr_leaf.c - 1.52 linux/fs/xfs/xfs_dfrag.c - 1.24 linux/fs/xfs/xfs_dir2_block.c - 1.17 linux/fs/xfs/xfs_dir_leaf.c - 1.91 linux/fs/xfs/xfs_grio.c - 1.86 linux/fs/xfs/xfs_inode.c - 1.305 linux/fs/xfs/xfs_itable.c - 1.95 linux/fs/xfs/xfs_log_recover.c - 1.192 linux/fs/xfs/xfs_mount.c - 1.241 linux/fs/xfs/xfs_qm.c - 1.55 linux/fs/xfs/xfs_qm_syscalls.c - 1.42 linux/fs/xfs/xfs_utils.c - 1.34 linux/fs/xfs/xfs_vfsops.c - 1.294 linux/fs/xfs/xfsidbg.c - 1.153 linux/fs/xfs/linux/xfs_super.c - 1.92 linux/fs/xfs/linux/xfs_vfs.c - 1.20 linux/fs/xfs/linux/xfs_vnode.h - 1.3 - remove explicit externs - get these from headers. linux/fs/xfs/linux/xfs_behavior.h - 1.1 - move pseudo-inc behavior.h here, matching it up to its xfs_behavior.c counterpart. linux/fs/xfs/linux/xfs_random.h - 1.1 - make sure we declare all of our routines which other files access. From owner-linux-xfs@oss.sgi.com Wed Sep 27 23:42:17 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 23:41:58 -0700 Received: from hermes.mixx.net ([212.84.196.2]:45579 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 27 Sep 2000 23:41:35 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 6ABDDF88A for ; Thu, 28 Sep 2000 08:41:33 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 1C6372CA6D; Thu, 28 Sep 2000 08:41:33 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: RedHat 7.0 Date: 28 Sep 2000 06:41:33 GMT Organization: innominate AG, Berlin, Germany Lines: 26 Distribution: local Message-ID: References: <200009280226.VAA30843@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 970123293 7825 10.0.0.69 (28 Sep 2000 06:41:33 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test5 (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing lord@sgi.com wrote: >> >> Hello, >> >> somebody has installed XFS in RedHat-7.0 ? >> >> >> claudio > Not within SGI, although we do have someone with redhat 7.0 on their > machine now, so it is only a matter of time - Eric are you listening? maybe i can try this in the evening today ... but i don't expect any real problems - the only thing to take care of is to check which compiler to use: gcc (2.96 - no idea if this one has the same problems as 2.95.2 for xfs) or kgcc (egcs) - but the gcc 2.96 thing should be really worth a try ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Sep 28 00:53:38 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 00:53:19 -0700 Received: from edge.coltex.nl ([194.151.97.115]:50950 "EHLO lsinet.coltex.nl") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 00:52:57 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e8S7qsE20201 for ; Thu, 28 Sep 2000 09:52:54 +0200 Message-Id: <4.3.2.7.2.20000928094851.02295128@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 09:52:28 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: RedHat 7.0 In-Reply-To: References: <200009280226.VAA30843@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 06:41 AM 9/28/2000 +0000, Thomas Graichen wrote: >lord@sgi.com wrote: > >> > >> Hello, > >> > >> somebody has installed XFS in RedHat-7.0 ? > >> > >> > >> claudio > > > Not within SGI, although we do have someone with redhat 7.0 on their > > machine now, so it is only a matter of time - Eric are you listening? > >maybe i can try this in the evening today ... but i don't expect >any real problems - the only thing to take care of is to check >which compiler to use: gcc (2.96 - no idea if this one has >the same problems as 2.95.2 for xfs) or kgcc (egcs) >- but the gcc 2.96 thing should be really >worth a try ... > >t It wouldn't compile the xfs kernel in the pinstripe beta. I have a upgrade running on one of our workstations right now. I'll test at least the beta kernel and then try to compile the cvs kernel. (but as far as I know there are 2.4 kernel issues with gcc2.96 (which is a pre snapshot) Bye -- Seth "Have you gone mad?" "Well, yes, but that's beyond the scope of this email." From owner-linux-xfs@oss.sgi.com Thu Sep 28 01:19:38 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 01:19:29 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:64522 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Thu, 28 Sep 2000 01:19:11 -0700 Received: (qmail 742 invoked from network); 28 Sep 2000 08:19:04 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Sep 2000 08:19:04 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 In-reply-to: Your message of "Thu, 28 Sep 2000 09:52:28 +0200." <4.3.2.7.2.20000928094851.02295128@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 19:19:03 +1100 Message-ID: <18168.970129143@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 28 Sep 2000 09:52:28 +0200, Seth Mos wrote: >I'll test at least the beta kernel and then try to compile the cvs kernel. >(but as far as I know there are 2.4 kernel issues with gcc2.96 (which is a >pre snapshot) gcc 2.95 onwards rewrote the ix86 code for function prologues. kdb backtrace cannot handle the newer prologue code, gdb has problems with it as well. gcc 2.7.2.3 and gcc 2.91 (egcs-1.1.2) are OK. From owner-linux-xfs@oss.sgi.com Thu Sep 28 04:43:18 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 04:42:59 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:57099 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Thu, 28 Sep 2000 04:42:42 -0700 Received: (qmail 2044 invoked from network); 28 Sep 2000 11:42:35 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Sep 2000 11:42:35 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: kdb@oss.sgi.com Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Keir Fraser Subject: [Announce] kdb v1.5-beta2 is available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 22:42:34 +1100 Message-ID: <9450.970141354@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing http://oss.sgi.com/projects/kdb/download/ix86/ contains a patch for kdb v1.5-beta2 against 2.4.0-test9-pre7. Copied to linux-xfs for interest only, XFS will stay on kdb v1.4 until kdb v1.5 has been better tested. If nobody complains then this will become kdb v1.5 some time next week. This version of kdb has had a lot of internal changes from kdb v1.4 so it comes with even less warranty than normal. You may hit problems in the debugger itself so only apply this patch if you want to explore the debugger, if you want to do real debugging then stick to kdb v1.4 for the moment. Changes from kdb v1.5-beta1. * Upgrade to 2.4.0-test9-pre7. * Breakpoints that are set via kdb/kdb_cmds at bootup are now activated automatically. They are also applied to each cpu as it boots so you can specify global hardware breakpoints and they will appear on all cpus. * SS and SSB commands have some minor bugs fixes. The change to only release one cpu for ss[b] appears to be working. * NMI oopser for uniprocessors. This builds on Keir Fraser's excellent patch for activating the local APIC on P6 systems and (ab)uses the local APIC to generate NMI on systems which have a local APIC but no IO-APIC, typically any P6 and above uniprocessor. So you poor developers with uniprocessors can now get diagnostics when the system gets into a spin loop. On the Processor configuration menu, select 'APIC and IO-APIC support on uniprocessors'. That option will detect the local APIC if it exists. See the help for 'NMI watchdog active for uniprocessors' and Documentation/nmi_watchdog.txt. * gdb single step sometimes hangs with this version of kdb, probably related to the dr7 changes in 2.4.0-test9-pre7. Under investigation, for the moment do not use gdb single stepping. From owner-linux-xfs@oss.sgi.com Thu Sep 28 07:08:39 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 07:08:29 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35919 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 07:08:07 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08469 for ; Thu, 28 Sep 2000 07:15:02 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA33093; Thu, 28 Sep 2000 09:06:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id JAA60121; Thu, 28 Sep 2000 09:06:47 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id JAA32637; Thu, 28 Sep 2000 09:02:11 -0500 Message-Id: <200009281402.JAA32637@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Keith Owens cc: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 In-Reply-To: Message from Keith Owens of "Thu, 28 Sep 2000 19:19:03 +1100." <18168.970129143@ocs3.ocs-net> Date: Thu, 28 Sep 2000 09:02:11 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Thu, 28 Sep 2000 09:52:28 +0200, > Seth Mos wrote: > >I'll test at least the beta kernel and then try to compile the cvs kernel. > >(but as far as I know there are 2.4 kernel issues with gcc2.96 (which is a > >pre snapshot) > > gcc 2.95 onwards rewrote the ix86 code for function prologues. kdb > backtrace cannot handle the newer prologue code, gdb has problems with > it as well. gcc 2.7.2.3 and gcc 2.91 (egcs-1.1.2) are OK. I have not checked, but I think redhat ships two compilers, there is a kgcc package in the 7.0 release for kernel compilation, not sure of the version in it. Other concerns would be that the binaries of user space which are dynamically linked agains glibc will have issues with the newer glibc in Redhat 7.0. In theory they would not but..... Steve From owner-linux-xfs@oss.sgi.com Thu Sep 28 07:53:39 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 07:53:31 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:49415 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 07:53:13 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e8SEr3a05501; Thu, 28 Sep 2000 09:53:04 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39D35B4F.1EC3FE17@thebarn.com> Date: Thu, 28 Sep 2000 09:53:03 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Keith Owens , linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 References: <200009281402.JAA32637@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > > On Thu, 28 Sep 2000 09:52:28 +0200, > > Seth Mos wrote: > > >I'll test at least the beta kernel and then try to compile the cvs kernel. > > >(but as far as I know there are 2.4 kernel issues with gcc2.96 (which is a > > >pre snapshot) > > > > gcc 2.95 onwards rewrote the ix86 code for function prologues. kdb > > backtrace cannot handle the newer prologue code, gdb has problems with > > it as well. gcc 2.7.2.3 and gcc 2.91 (egcs-1.1.2) are OK. > > I have not checked, but I think redhat ships two compilers, there is a > kgcc package in the 7.0 release for kernel compilation, not sure of the > version in it. > > Other concerns would be that the binaries of user space which are > dynamically linked agains glibc will have issues with the newer glibc > in Redhat 7.0. In theory they would not but..... > > Steve For gins I tried the ProPack install on a 7.0 system. Seems 7.0 uses rpm 4. whatever, the ProPack installer expects rpm 3.0.5 (I think), need less to say things didn't jive. I tried the not PP rpms, they did install but I had trouble with lilo not loading the correct kernel... probably pilot error. I haven't tried compiling things yet. I did try compiling XFS some time back with gcc 2.96 and it ran into several compilation errors. I assume they are still there. gcc 2.95 will compile XFS but produces incorrect results. The two things I am aware of unexplained hangs in sv_wait, and incorrect results when doing shifts: specifically shifting a value left and then immediately shifting it right on the next line of code. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Sep 28 07:58:30 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 07:58:09 -0700 Received: from edge.coltex.nl ([194.151.97.115]:2321 "EHLO lsinet.coltex.nl") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 07:58:00 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e8SEvvE22052; Thu, 28 Sep 2000 16:57:58 +0200 Message-Id: <4.3.2.7.2.20000928163645.0230f8d0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 16:57:16 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: RedHat 7.0 Cc: linux-xfs@oss.sgi.com In-Reply-To: <200009281402.JAA32637@jen.americas.sgi.com> References: <18168.970129143@ocs3.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 09:02 AM 9/28/2000 -0500, Steve Lord wrote: > > On Thu, 28 Sep 2000 09:52:28 +0200, > > Seth Mos wrote: > > >I'll test at least the beta kernel and then try to compile the cvs kernel. > > >(but as far as I know there are 2.4 kernel issues with gcc2.96 (which > is a > > >pre snapshot) > > > > gcc 2.95 onwards rewrote the ix86 code for function prologues. kdb > > backtrace cannot handle the newer prologue code, gdb has problems with > > it as well. gcc 2.7.2.3 and gcc 2.91 (egcs-1.1.2) are OK. > >I have not checked, but I think redhat ships two compilers, there is a >kgcc package in the 7.0 release for kernel compilation, not sure of the >version in it. I would have to check if it's available. Workstation is upgraded by now and running in it's previous state. (always tricky upgrading machines - breaking stuff) The standard apache seems broken with some rsa crypto clash (php-4.02) Is the compiler hardcoded in the xfs source? (just checked out cvs tree) I got the error that gcc-2.91-6 was not available ?! gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c scripts/split-include include/linux/autoconf.h include/config gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -c -o init/main.o init/main.c gcc: installation problem, cannot exec `cpp0': No such file or directory gcc: installation problem, cannot exec `cc1': No such file or directory gcc: file path prefix `/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/' never used make: *** [init/main.o] Error 1 ?? That should definitely not happen. I did make mrproper before compiling. make mrproper && make menuconfig && make dep && make bzImage etc.. >Other concerns would be that the binaries of user space which are >dynamically linked agains glibc will have issues with the newer glibc >in Redhat 7.0. In theory they would not but..... Not really found any (yet ;-) More to come -- Seth "Have you gone mad?" "Well, yes, but that's beyond the scope of this email." From owner-linux-xfs@oss.sgi.com Thu Sep 28 07:59:00 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 07:58:39 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2134 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 07:58:33 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03646; Thu, 28 Sep 2000 08:05:29 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA91089; Thu, 28 Sep 2000 07:58:32 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA38934; Thu, 28 Sep 2000 07:57:15 -0700 (PDT) Date: Thu, 28 Sep 2000 07:57:15 -0700 (PDT) Message-Id: <200009281457.HAA38934@info.engr.sgi.com> X-Pv-Incident: 803065 webPV: fzr600.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (coreym@sgi.com) Subject: ADD 803065 - Data corruption while running rwtest To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803065 Status : open Priority : 2 Assigned Engineer : nb Submitter : coreym *Modified User : coreym *Modified User Domain : sgi.com *Description : I was running rwtest on permit and got a data comparison error. Here is the output and related information: [root@permit /mnt]# rwtest iogen 1000000b:rwtest.file | doio -av iogen starting up with the following: ..... ========================== ADDITIONAL INFORMATION (ADD) From: coreym@sgi.com (BugWorks) Date: Sep 28 2000 07:57:14AM ========================== I did not have file locking turned on and the tests were running to the same file. This is not data corruption, I will close this PV. From owner-linux-xfs@oss.sgi.com Thu Sep 28 07:59:29 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 07:59:09 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7510 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 07:58:54 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA02228; Thu, 28 Sep 2000 08:05:50 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA49113; Thu, 28 Sep 2000 07:58:53 -0700 (PDT) Date: Thu, 28 Sep 2000 07:58:53 -0700 (PDT) Message-Id: <200009281458.HAA49113@info.engr.sgi.com> X-Pv-Incident: 803065 webPV: fzr600.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (coreym@sgi.com) Subject: CLOSE 803065 - Data corruption while running rwtest To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803065 *Status : closed Priority : 2 Assigned Engineer : nb Submitter : coreym Opened Date : 09/27/00 *Closed Date : 09/28/00 *Fixed By : coreym *Fixed By Domain : sgi.com *Modified Date : 09/28/00 *Modified User : coreym *Modified User Domain : sgi.com *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: coreym@sgi.com (BugWorks) Date: Sep 28 2000 07:58:53AM ========================== From owner-linux-xfs@oss.sgi.com Thu Sep 28 08:11:00 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 08:10:39 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:14345 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 08:10:08 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA04535 for ; Thu, 28 Sep 2000 08:02:24 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA36562; Thu, 28 Sep 2000 10:07:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id KAA00418; Thu, 28 Sep 2000 10:07:48 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id KAA09971; Thu, 28 Sep 2000 10:03:12 -0500 Message-Id: <200009281503.KAA09971@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 In-Reply-To: Message from Seth Mos of "Thu, 28 Sep 2000 16:57:16 +0200." <4.3.2.7.2.20000928163645.0230f8d0@pop.xs4all.nl> Date: Thu, 28 Sep 2000 10:03:10 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > At 09:02 AM 9/28/2000 -0500, Steve Lord wrote: > > > On Thu, 28 Sep 2000 09:52:28 +0200, > > > Seth Mos wrote: > > > >I'll test at least the beta kernel and then try to compile the cvs kerne l. > > > >(but as far as I know there are 2.4 kernel issues with gcc2.96 (which > > is a > > > >pre snapshot) > > > > > > gcc 2.95 onwards rewrote the ix86 code for function prologues. kdb > > > backtrace cannot handle the newer prologue code, gdb has problems with > > > it as well. gcc 2.7.2.3 and gcc 2.91 (egcs-1.1.2) are OK. > > > >I have not checked, but I think redhat ships two compilers, there is a > >kgcc package in the 7.0 release for kernel compilation, not sure of the > >version in it. > > I would have to check if it's available. Workstation is upgraded by now and > running in it's previous state. (always tricky upgrading machines - > breaking stuff) The standard apache seems broken with some rsa crypto clash > (php-4.02) > > Is the compiler hardcoded in the xfs source? (just checked out cvs tree) > I got the error that gcc-2.91-6 was not available ?! > > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o > scripts/split-include scripts/split-include.c > scripts/split-include include/linux/autoconf.h include/config > gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux/include -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe > -fno-strength-reduce -c -o init/main.o init/main.c > gcc: installation problem, cannot exec `cpp0': No such file or directory > gcc: installation problem, cannot exec `cc1': No such file or directory > gcc: file path prefix `/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/' > never used > make: *** [init/main.o] Error 1 > > ?? > > That should definitely not happen. I did make mrproper before compiling. > make mrproper && make menuconfig && make dep && make bzImage etc.. > The compiler did get hardcoded into the top level makefile of the kernel, there is one line right at the top you need to edit: CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 I suspect 7.0 does something similar, check out what they define CC as in there kernel source and try using the same thing. Steve From owner-linux-xfs@oss.sgi.com Thu Sep 28 08:13:40 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 08:13:30 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:51207 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 08:13:14 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e8SFCqa05524; Thu, 28 Sep 2000 10:12:53 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39D35FF3.CACCFED0@thebarn.com> Date: Thu, 28 Sep 2000 10:12:52 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 References: <18168.970129143@ocs3.ocs-net> <4.3.2.7.2.20000928163645.0230f8d0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Seth Mos wrote: > At 09:02 AM 9/28/2000 -0500, Steve Lord wrote: > > > On Thu, 28 Sep 2000 09:52:28 +0200, > > > Seth Mos wrote: > > > >I'll test at least the beta kernel and then try to compile the cvs kernel. > > > >(but as far as I know there are 2.4 kernel issues with gcc2.96 (which > > is a > > > >pre snapshot) > > > > > > gcc 2.95 onwards rewrote the ix86 code for function prologues. kdb > > > backtrace cannot handle the newer prologue code, gdb has problems with > > > it as well. gcc 2.7.2.3 and gcc 2.91 (egcs-1.1.2) are OK. > > > >I have not checked, but I think redhat ships two compilers, there is a > >kgcc package in the 7.0 release for kernel compilation, not sure of the > >version in it. > > I would have to check if it's available. Workstation is upgraded by now and > running in it's previous state. (always tricky upgrading machines - > breaking stuff) The standard apache seems broken with some rsa crypto clash > (php-4.02) > > Is the compiler hardcoded in the xfs source? (just checked out cvs tree) > I got the error that gcc-2.91-6 was not available ?! Yes! It's in the top level make file. Hopefully this will be a heads up to anybody trying the newer compilers that there is a problem. > > > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o > scripts/split-include scripts/split-include.c > scripts/split-include include/linux/autoconf.h include/config > gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux/include -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe > -fno-strength-reduce -c -o init/main.o init/main.c > gcc: installation problem, cannot exec `cpp0': No such file or directory > gcc: installation problem, cannot exec `cc1': No such file or directory > gcc: file path prefix `/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/' > never used > make: *** [init/main.o] Error 1 > > ?? > > That should definitely not happen. I did make mrproper before compiling. > make mrproper && make menuconfig && make dep && make bzImage etc.. > > >Other concerns would be that the binaries of user space which are > >dynamically linked agains glibc will have issues with the newer glibc > >in Redhat 7.0. In theory they would not but..... > > Not really found any (yet ;-) > More to come > > -- > Seth > "Have you gone mad?" > "Well, yes, but that's beyond the scope of this email." -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Sep 28 08:24:00 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 08:23:50 -0700 Received: from edge.coltex.nl ([194.151.97.115]:40721 "EHLO lsinet.coltex.nl") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 08:23:36 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e8SFNYE22154 for ; Thu, 28 Sep 2000 17:23:34 +0200 Message-Id: <4.3.2.7.2.20000928171143.0230ee90@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 17:22:52 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: RedHat 7.0 In-Reply-To: <39D35B4F.1EC3FE17@thebarn.com> References: <200009281402.JAA32637@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 09:53 AM 9/28/2000 -0500, you wrote: >Steve Lord wrote: > > Other concerns would be that the binaries of user space which are > > dynamically linked agains glibc will have issues with the newer glibc > > in Redhat 7.0. In theory they would not but..... > > > > Steve > >For gins I tried the ProPack install on a 7.0 system. >Seems 7.0 uses rpm 4. whatever, the ProPack installer expects >rpm 3.0.5 (I think), need less to say things didn't jive. True >I tried the not PP rpms, they did install but I had trouble with >lilo not loading the correct kernel... probably pilot error. I have installed the XFS_BETA_2 rpms from the beta release and I have a test5 kernel with xfs compiled when the machine still was a redhat 6.2 box. Both these kernels have the following problem after booting. it runs init. You get the line "Mounting proc filesystem" (disk activity) followed by a quick "Unknown group utmp" message. "init: entering runlevel 3" After that the login prompt stares at you. try to log in as root and it will barf at you, and I quote: "You don't exist, go away" How rude. ;-) After hitting the reset button the machine will leave all partitions in a unclean state with just a few minor errors on the / disk. -- Seth "Have you gone mad?" "Well, yes, but that's beyond the scope of this email." From owner-linux-xfs@oss.sgi.com Thu Sep 28 08:36:10 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 08:36:00 -0700 Received: from hermes.mixx.net ([212.84.196.2]:24330 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 28 Sep 2000 08:35:41 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id E316FF8F2 for ; Thu, 28 Sep 2000 17:35:38 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id C6CB82CA6D; Thu, 28 Sep 2000 17:35:38 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: lkcd? Date: 28 Sep 2000 15:35:38 GMT Organization: innominate AG, Berlin, Germany Lines: 14 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 970155338 21436 10.0.0.69 (28 Sep 2000 15:35:38 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test5 (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing now that XFS is in beta and will in some time also begin to be used in production - wouldn't it be a good idea to also add the lkcd (linux kernel crash dumps) stuff to the XFS kernel too for the cases where no kdb trace is possible (production machine which has to reboot imeadeately, remote machine, machine running X etc.)? t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Sep 28 13:50:44 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 13:50:24 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:15113 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 13:50:01 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA01559 for ; Thu, 28 Sep 2000 13:56:56 -0700 (PDT) mail_from (mann@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id PAA47356 for ; Thu, 28 Sep 2000 15:48:44 -0500 (CDT) Received: from fsgi632.americas.sgi.com (fsgi632.americas.sgi.com [128.162.184.134]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id PAA68183 for ; Thu, 28 Sep 2000 15:48:43 -0500 (CDT) Received: from sgi.com by fsgi632.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id PAA01413; Thu, 28 Sep 2000 15:48:43 -0500 (CDT) Message-ID: <39D3AEA9.54BEF677@sgi.com> Date: Thu, 28 Sep 2000 15:48:42 -0500 From: Mark Nordstrand X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 References: <200009281503.KAA09971@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > The compiler did get hardcoded into the top level makefile of the > kernel, there is one line right at the top you need to edit: > > CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 > > I suspect 7.0 does something similar, check out what they define CC > as in there kernel source and try using the same thing. I just installed the kgcc rpm from the distro and change the above line to: CC = $(CROSS_COMPILE)kgcc -V egcs-2.91.66 and the kernel is compiling now. kgcc appears to, in fact, be egcs-2.91.66. Mark From owner-linux-xfs@oss.sgi.com Thu Sep 28 15:12:34 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 15:12:25 -0700 Received: from feanor.nuclear.demokritos.gr ([143.233.244.29]:53516 "EHLO feanor.nuclear.demokritos.gr") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 15:12:09 -0700 Received: from localhost ([127.0.0.1]) by feanor.nuclear.demokritos.gr with esmtp (Exim 3.12 #1 (Debian)) id 13elru-0002q7-00 for ; Fri, 29 Sep 2000 01:09:30 +0300 Date: Fri, 29 Sep 2000 01:09:29 +0300 (EEST) From: Konstantinos Margaritis To: linux-xfs@oss.sgi.com Subject: XFS on ppc (doesn't compile) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I've been tempted by the latest reports on success of XFS on powerpc, and thought I'd give it a try. To my dismay, it didn't compile. on kernel/sysctl.c it fails on asm/kdb.h (kdb is not ported to powerpc). Is it wise to force-undefine CONFIG_KDB_H? (Unselecting debugging information on kernel setup doesn't have any effect obviously). Also, would patching a later kernel with the xfs patch? (namely -test[89]) Thanks for any help. Konstantinos Margaritis PS: Please CC to me, as I am not on the list (yet). From owner-linux-xfs@oss.sgi.com Thu Sep 28 15:31:35 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 15:31:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:53783 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 15:31:10 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA03396 for ; Thu, 28 Sep 2000 15:38:06 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id RAA95045; Thu, 28 Sep 2000 17:29:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id RAA58051; Thu, 28 Sep 2000 17:29:21 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id RAA10554; Thu, 28 Sep 2000 17:24:41 -0500 Message-Id: <200009282224.RAA10554@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Konstantinos Margaritis cc: linux-xfs@oss.sgi.com Subject: Re: XFS on ppc (doesn't compile) In-Reply-To: Message from Konstantinos Margaritis of "Fri, 29 Sep 2000 01:09:29 +0300." Date: Thu, 28 Sep 2000 17:24:41 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > I've been tempted by the latest reports on success of XFS on powerpc, and > thought I'd give it a try. To my dismay, it didn't compile. > on kernel/sysctl.c it fails on asm/kdb.h (kdb is not ported to powerpc). > > Is it wise to force-undefine CONFIG_KDB_H? (Unselecting debugging > information on kernel setup doesn't have any effect obviously). > > Also, would patching a later kernel with the xfs patch? (namely -test[89]) > Thanks for any help. > > Konstantinos Margaritis > > PS: Please CC to me, as I am not on the list (yet). For ppc specific stuff take a look here, there are some patches: http://innominate.org/~graichen/projects/xfs/ I am in the process of upgrading the development tree to test8 right now, so this will show up in the cvs tree. test9 will take a bit more work because of the vm changes and changes outside the filesystem in our tree. Steve From owner-linux-xfs@oss.sgi.com Thu Sep 28 15:43:05 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 15:42:45 -0700 Received: from tux.mkp.net ([130.225.60.11]:11275 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 15:42:19 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=tyra.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 13emHF-00061l-00; Fri, 29 Sep 2000 00:35:41 +0200 Received: (from mkp@localhost) by tyra.mkp.net (8.9.3/8.9.3) id SAA19490; Thu, 28 Sep 2000 18:40:25 -0400 X-Authentication-Warning: tyra.mkp.net: mkp set sender to mkp@mkp.net using -f To: Konstantinos Margaritis Cc: linux-xfs@oss.sgi.com Subject: Re: XFS on ppc (doesn't compile) References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 28 Sep 2000 18:40:24 -0400 In-Reply-To: Konstantinos Margaritis's message of "Fri, 29 Sep 2000 01:09:29 +0300 (EEST)" Message-ID: Lines: 31 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> " " == Konstantinos Margaritis writes: > I've been tempted by the latest reports on success of XFS on > powerpc, and thought I'd give it a try. To my dismay, it didn't > compile. on kernel/sysctl.c it fails on asm/kdb.h (kdb is not > ported to powerpc). I mailed Keith about it this morning (tried compiling on my Alpha for the fun of it - dies horribly because of 8K pages). > Is it wise to force-undefine CONFIG_KDB_H? (Unselecting debugging > information on kernel setup doesn't have any effect obviously). --- kernel/sysctl.c.orig Thu Sep 28 12:32:17 2000 +++ kernel/sysctl.c Thu Sep 28 12:28:19 2000 @@ -30,7 +30,10 @@ #include #include #include + +#ifdef CONFIG_KDB #include +#endif #include -- Martin K. Petersen Cereal Bowl Engineer, Linuxcare, Inc. http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME From owner-linux-xfs@oss.sgi.com Thu Sep 28 15:43:45 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 15:43:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:33607 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 15:43:24 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA02274 for ; Thu, 28 Sep 2000 15:35:37 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA72776; Thu, 28 Sep 2000 15:36:30 -0700 (PDT) Message-ID: <39D3C958.4829EEE9@sgi.com> Date: Thu, 28 Sep 2000 15:42:32 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Konstantinos Margaritis , linux-xfs@oss.sgi.com Subject: Re: XFS on ppc (doesn't compile) References: <200009282224.RAA10554@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > [ ... ] > > Also, would patching a later kernel with the xfs patch? (namely -test[89]) > > Thanks for any help. > > > > Konstantinos Margaritis > > [ ... ] > > I am in the process of upgrading the development tree to test8 right now, > so this will show up in the cvs tree. test9 will take a bit more work because > of the vm changes and changes outside the filesystem in our tree. Also, note that test9 (final) is yet to be released! preX's are too unstable to be worth a port; example, there are various reports of lock-ups in test9-pre7 ... -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Sep 28 15:51:04 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 15:50:44 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:28697 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 15:50:42 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00554 for ; Thu, 28 Sep 2000 15:57:31 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id RAA69484 for ; Thu, 28 Sep 2000 17:49:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id RAA70996 for ; Thu, 28 Sep 2000 17:49:19 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id RAA10742 for ; Thu, 28 Sep 2000 17:44:39 -0500 Message-Id: <200009282244.RAA10742@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: XFS CVS development tree moving up to test8 Date: Thu, 28 Sep 2000 17:44:39 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I am in the process of checking in a merge up to 2.4.0-test8 to our development leg (it is churning away in another window right now) this should make it out to the cvs tree in a few hours - and there will be a major download next time you do an update, we can probably respin some patches soon to apply to a vanilla test8. Because we have some unofficial system calls in the tree for xfs and there are other new system calls in test8 I would recommend a command rebuild after this (make clean; make). This really only affects extended attribute code, but these calls are in some of the command binaries, and some of the test programs will fail if this is not done. Steve From owner-linux-xfs@oss.sgi.com Thu Sep 28 16:02:35 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 16:02:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40730 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 16:01:49 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA09916 for ; Thu, 28 Sep 2000 16:08:45 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id SAA01568 for ; Thu, 28 Sep 2000 18:00:33 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id SAA50913 for ; Thu, 28 Sep 2000 18:00:32 -0500 (CDT) Received: (from lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) id RAA10946 for linux-xfs@oss.sgi.com; Thu, 28 Sep 2000 17:55:52 -0500 Date: Thu, 28 Sep 2000 17:55:52 -0500 From: Steve Lord Message-Id: <200009282255.RAA10946@jen.americas.sgi.com> Subject: TAKE - ppc fix, conditional include of kdb.h To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Sep 28 15:59:52 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-2.4.0-test8 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:75339a linux/kernel/sysctl.c - 1.29 - ifdef kdb.h for platforms which do not have support yet. From owner-linux-xfs@oss.sgi.com Thu Sep 28 16:19:39 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 16:19:19 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:13648 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 16:19:13 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA06582 for ; Thu, 28 Sep 2000 16:11:24 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA19346; Fri, 29 Sep 2000 10:17:50 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA42727; Fri, 29 Sep 2000 10:17:49 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009291017.ZM42747@wobbly.melbourne.sgi.com> Date: Fri, 29 Sep 2000 10:17:47 -0400 In-Reply-To: "Joseph I. Davida" "Re: Librmt" (Sep 28, 4:06pm) References: <39D3CF13.4D29A28B@maxtor.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: joe_davida@maxtor.com, cattelan@sgi.com, tes@sgi.com Subject: Re: Librmt Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ok, thanks Joe. Russell/Tim - looks like something went wrong when librmt was checked in? (ptools->cvs scripts not picking it up?) A simple workaround until this is fixed would be to remove "dump" from the list in the SUBDIRS macro in cmd/xfs/Makefile - your build should then complete successfully, it'll just skip over building the xfsdump and xfsrestore commands. cheers. On Sep 28, 4:06pm, Joseph I. Davida wrote: > Subject: Re: Librmt > Nathan, I did as you suggested, even preceded > it with cvs update. Still, make realclean > issues a similar message, and make issues > > === librmt === > make[2]: *** No rule to make target `default'. Stop. > make[1]: *** [default] Error 2 > make: *** [default] Error 2 > > The thing is I dont even have a directory librmt > anywhere under cmd. So cvs update is broken?? > > Joe >-- End of excerpt from Joseph I. Davida -- Nathan From owner-linux-xfs@oss.sgi.com Thu Sep 28 17:59:59 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 17:59:50 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38690 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 17:59:31 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA03117 for ; Thu, 28 Sep 2000 18:06:26 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20000; Fri, 29 Sep 2000 11:58:04 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Martin K. Petersen" cc: Konstantinos Margaritis , linux-xfs@oss.sgi.com Subject: Re: XFS on ppc (doesn't compile) In-reply-to: Your message of "28 Sep 2000 18:40:24 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Sep 2000 11:58:04 +1100 Message-ID: <1627.970189084@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 28 Sep 2000 18:40:24 -0400, "Martin K. Petersen" wrote: >>>>>> " " == Konstantinos Margaritis writes: > >> I've been tempted by the latest reports on success of XFS on >> powerpc, and thought I'd give it a try. To my dismay, it didn't >> compile. on kernel/sysctl.c it fails on asm/kdb.h (kdb is not >> ported to powerpc). > >I mailed Keith about it this morning (tried compiling on my Alpha for >the fun of it - dies horribly because of 8K pages). > >--- kernel/sysctl.c.orig Thu Sep 28 12:32:17 2000 >+++ kernel/sysctl.c Thu Sep 28 12:28:19 2000 >@@ -30,7 +30,10 @@ > #include > #include > #include >+ >+#ifdef CONFIG_KDB > #include >+#endif > > #include Colour me puzzled. Does this mean that your XFS patch includes kdb patches but there is no include/linux/kdb.h? Looks like somebody has included only part of kdb on XFS for PPC. You can ship include/{linux,asm}/kdb.h on all architectures. You can then #include without testing for #ifdef CONFIG_KDB, again on all architectures. You just cannot activate kdb on most architectures. I do not want to clutter up the mainline source code with #ifdef if I do not have to. I would rather ship a dummy include/asm/kdb.h for all architectures and remove #ifdef from the mainline source. Can you revert the above patch and add this. Let me know if it lets you compile. Index: 0-test9-pre7.1/include/linux/kdb.h --- 0-test9-pre7.1/include/linux/kdb.h Fri, 29 Sep 2000 11:56:22 +1100 kaos () +++ 0-test9-pre7.3(w)/include/linux/kdb.h Thu, 28 Sep 2000 22:25:06 +1100 kaos (linux-2.4/R/c/5_kdb.h 1.2.1.8 644) @@ -0,0 +1,226 @@ +/* + * Minimalist Kernel Debugger + * + * Copyright (C) 1999 Silicon Graphics, Inc. + * Copyright (C) Scott Lurndal (slurn@engr.sgi.com) + * Copyright (C) Scott Foehner (sfoehner@engr.sgi.com) + * Copyright (C) Srinivasa Thirumalachar (sprasad@engr.sgi.com) + * + * See the file LIA-COPYRIGHT for additional information. + * + * Written March 1999 by Scott Lurndal at Silicon Graphics, Inc. + * + * Modifications from: + * Richard Bass 1999/07/20 + * Many bug fixes and enhancements. + * Scott Foehner + * Port to ia64 + * Scott Lurndal 1999/12/12 + * v1.0 restructuring. + * Keith Owens 2000/05/23 + * KDB v1.2 + * Keith Owens 2000/09/16 + * KDB v1.4 + * kdb=on/off/early at boot, /proc/sys/kernel/kdb. + * Env BTAPROMPT. + */ + + +#if !defined(__KDB_H) +#define __KDB_H + +#include + +#define KDB_MAJOR_VERSION 1 +#define KDB_MINOR_VERSION 5 +#define KDB_TEST_VERSION "-beta2" + + /* + * kdb_initial_cpu is initialized to -1, and is set to the cpu + * number whenever the kernel debugger is entered. + */ +extern volatile int kdb_initial_cpu; +#ifdef CONFIG_KDB +#define KDB_IS_RUNNING() (kdb_initial_cpu != -1) +#else +#define KDB_IS_RUNNING() (0) +#endif /* CONFIG_KDB */ + + /* + * kdb_on + * + * Defines whether kdb is on or not. Default value + * is set by CONFIG_KDB_OFF. Boot with kdb=on/off + * or echo "[01]" > /proc/sys/kernel/kdb to change it. + */ +extern int kdb_on; + + /* + * kdb_port is initialized to zero, and is set to the I/O port + * address of the serial port when the console is setup in + * serial_console_setup. + */ +extern int kdb_port; + + /* + * KDB_FLAG_EARLYKDB is set when the 'kdb' option is specified + * as a boot parameter (e.g. via lilo). It indicates that the + * kernel debugger should be entered as soon as practical. + */ +#define KDB_FLAG_EARLYKDB 0x00000001 + + /* + * Internal debug flags + */ +#define KDB_DEBUG_FLAG_BT 0x0001 /* Stack traceback debug */ +#define KDB_DEBUG_FLAG_BP 0x0002 /* Breakpoint subsystem debug */ +#define KDB_DEBUG_FLAG_LBR 0x0004 /* Print last branch register */ +#define KDB_DEBUG_FLAG_AR 0x0008 /* Activation record, generic */ +#define KDB_DEBUG_FLAG_ARA 0x0010 /* Activation record, arch specific */ +#define KDB_DEBUG_FLAG_CALLBACK 0x0020 /* Event callbacks to kdb */ +#define KDB_DEBUG_FLAG_STATE 0x0040 /* State flags */ +#define KDB_DEBUG_FLAG_MASK 0xffff /* All debug flags */ +#define KDB_DEBUG_FLAG_SHIFT 16 /* Shift factor for dbflags */ + +extern volatile int kdb_flags; /* Global flags, see kdb_state for per cpu state */ + +#define KDB_FLAG(flag) (kdb_flags & KDB_FLAG_##flag) +#define KDB_FLAG_SET(flag) ((void)(kdb_flags |= KDB_FLAG_##flag)) +#define KDB_FLAG_CLEAR(flag) ((void)(kdb_flags &= ~KDB_FLAG_##flag)) +#define KDB_DEBUG(flag) (kdb_flags & (KDB_DEBUG_FLAG_##flag << KDB_DEBUG_FLAG_SHIFT)) +#define KDB_DEBUG_STATE(text,value) if (KDB_DEBUG(STATE)) kdb_print_state(text, value) + + /* + * Per cpu kdb state. A cpu can be under kdb control but outside kdb, + * for example when doing single step. + */ +volatile extern int kdb_state[ /*NR_CPUS*/ ]; +#define KDB_STATE_KDB 0x00000001 /* Cpu is inside kdb */ +#define KDB_STATE_LEAVING 0x00000002 /* Cpu is leaving kdb */ +#define KDB_STATE_CMD 0x00000004 /* Running a kdb command */ +#define KDB_STATE_KDB_CONTROL 0x00000008 /* This cpu is under kdb control */ +#define KDB_STATE_HOLD_CPU 0x00000010 /* Hold this cpu inside kdb */ +#define KDB_STATE_DOING_SS 0x00000020 /* Doing ss command */ +#define KDB_STATE_DOING_SSB 0x00000040 /* Doing ssb command, DOING_SS is also set */ +#define KDB_STATE_SSBPT 0x00000080 /* Install breakpoint after one ss, independent of DOING_SS */ +#define KDB_STATE_REENTRY 0x00000100 /* Valid re-entry into kdb */ +#define KDB_STATE_SUPPRESS 0x00000200 /* Suppress error messages */ +#define KDB_STATE_LONGJMP 0x00000400 /* longjmp() data is available */ +#define KDB_STATE_NO_WATCHDOG 0x00000800 /* Ignore watchdog */ +#define KDB_STATE_PRINTF_LOCK 0x00001000 /* Holds kdb_printf lock */ +#define KDB_STATE_WAIT_IPI 0x00002000 /* Waiting for kdb_ipi() NMI */ +#define KDB_STATE_RECURSE 0x00004000 /* Recursive entry to kdb */ +#define KDB_STATE_ARCH 0xff000000 /* Reserved for arch specific use */ + +#define KDB_STATE_CPU(flag,cpu) (kdb_state[cpu] & KDB_STATE_##flag) +#define KDB_STATE_SET_CPU(flag,cpu) ((void)(kdb_state[cpu] |= KDB_STATE_##flag)) +#define KDB_STATE_CLEAR_CPU(flag,cpu) ((void)(kdb_state[cpu] &= ~KDB_STATE_##flag)) + +#define KDB_STATE(flag) KDB_STATE_CPU(flag,smp_processor_id()) +#define KDB_STATE_SET(flag) KDB_STATE_SET_CPU(flag,smp_processor_id()) +#define KDB_STATE_CLEAR(flag) KDB_STATE_CLEAR_CPU(flag,smp_processor_id()) + + /* + * External entry point for the kernel debugger. The pt_regs + * at the time of entry are supplied along with the reason for + * entry to the kernel debugger. + */ + +typedef enum { + KDB_REASON_ENTER = 1, /* Call kdb() directly - regs invalid */ + KDB_REASON_FAULT, /* Kernel fault - regs valid */ + KDB_REASON_BREAK, /* Breakpoint inst. - regs valid */ + KDB_REASON_DEBUG, /* Debug Fault - regs valid */ + KDB_REASON_PANIC, /* Kernel Panic - regs valid */ + KDB_REASON_SWITCH, /* CPU switch - regs valid*/ + KDB_REASON_INT, /* KDB_ENTER trap - regs valid */ + KDB_REASON_KEYBOARD, /* Keyboard entry - regs valid */ + KDB_REASON_NMI, /* Non-maskable interrupt; regs valid */ + KDB_REASON_WATCHDOG, /* Watchdog interrupt; regs valid */ + KDB_REASON_RECURSE, /* Recursive entry to kdb; regs probably valid */ + KDB_REASON_SILENT /* Silent entry/exit to kdb; regs invalid */ +} kdb_reason_t; + +#ifdef CONFIG_KDB +extern int kdb(kdb_reason_t reason, int error_code, kdb_eframe_t); +#else +#define kdb(reason,error_code,frame) (0) +#endif + +typedef int (*kdb_func_t)(int, const char **, const char **, kdb_eframe_t); + + /* + * Symbol table format returned by kallsyms. + */ + +typedef struct __ksymtab { + unsigned long value; /* Address of symbol */ + const char *mod_name; /* Module containing symbol or "kernel" */ + unsigned long mod_start; + unsigned long mod_end; + const char *sec_name; /* Section containing symbol */ + unsigned long sec_start; + unsigned long sec_end; + const char *sym_name; /* Full symbol name, including any version */ + unsigned long sym_start; + unsigned long sym_end; + } kdb_symtab_t; + + /* + * Exported Symbols for kernel loadable modules to use. + */ +extern int kdb_register(char *, kdb_func_t, char *, char *, short); +extern int kdb_unregister(char *); + +extern unsigned long kdba_getword(unsigned long, size_t); +extern unsigned long kdba_putword(unsigned long, size_t, unsigned long); + +extern int kdbgetularg(const char *, unsigned long *); +extern char *kdbgetenv(const char *); +extern int kdbgetintenv(const char *, int *); +extern int kdbgetaddrarg(int, const char**, int*, unsigned long *, + long *, char **, kdb_eframe_t); +extern int kdbgetsymval(const char *, kdb_symtab_t *); +extern int kdbnearsym(unsigned long, kdb_symtab_t *); +extern void kdb_printf(const char *,...) + __attribute__ ((format (printf, 1, 2))); +extern void kdb_init(void); +extern void kdb_symbol_print(kdb_machreg_t, const kdb_symtab_t *, unsigned int); + +#if defined(CONFIG_SMP) + /* + * Kernel debugger non-maskable IPI handler. + */ +extern int kdb_ipi(kdb_eframe_t, void (*ack_interrupt)(void)); +extern void smp_kdb_stop(void); +#else /* CONFIG_SMP */ +#define smp_kdb_stop() +#endif /* CONFIG_SMP */ + + /* + * Interface from general kernel to enable any hardware + * error reporting mechanisms. Such as the Intel Machine + * Check Architecture, for example. + */ +extern void kdb_enablehwfault(void); + + /* + * Interface from kernel trap handling code to kernel debugger. + */ +extern int kdba_callback_die(struct pt_regs *, int, long, void*); +extern int kdba_callback_bp(struct pt_regs *, int, long, void*); +extern int kdba_callback_debug(struct pt_regs *, int, long, void *); + + /* + * Determine if a kernel address is valid or not. + */ + +extern int kdb_vmlist_check(unsigned long, unsigned long); + + /* + * Routine for debugging the debugger state. + */ + +extern void kdb_print_state(const char *, int); + +#endif /* __KDB_H */ Index: 0-test9-pre7.1/include/asm-ppc/kdb.h --- 0-test9-pre7.1/include/asm-ppc/kdb.h Fri, 29 Sep 2000 11:56:22 +1100 kaos () +++ 0-test9-pre7.3(w)/include/asm-ppc/kdb.h Fri, 29 Sep 2000 11:55:17 +1100 kaos (linux-2.4/c/d/48_kdb.h 644) @@ -0,0 +1,23 @@ +/* + * Minimalist Kernel Debugger + * + * Copyright (C) 2000 Silicon Graphics, Inc. + * + * Written September 2000 by Keith Owens at Silicon Graphics, Inc. + * Dummy asm/kdb.h for PPC. + */ +#if !defined(_ASM_KDB_H) +#define _ASM_KDB_H + + /* + * Define the exception frame for this architeture + */ +struct pt_regs; +typedef struct pt_regs *kdb_eframe_t; + + /* + * Needed for exported symbols. + */ +typedef unsigned long kdb_machreg_t; + +#endif /* ASM_KDB_H */ From owner-linux-xfs@oss.sgi.com Thu Sep 28 23:19:41 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 23:19:32 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:558 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 23:19:13 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA05543 for ; Thu, 28 Sep 2000 23:26:07 -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 RAA36775 for linux-xfs@oss.sgi.com; Fri, 29 Sep 2000 17:16:37 +1100 (EST) Date: Fri, 29 Sep 2000 17:16:37 +1100 (EST) From: Nathan Scott Message-Id: <200009290616.RAA36775@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - misc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Found a couple more SIM macros off in the system headers. I wonder how I would go about updating the statfs(2) man page for XFS? (anyone?) thanks. Modid: 2.4.x-xfs:slinx:75353a Date: Thu Sep 28 23:06:57 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/include/xfs_fs.h - 1.4 linux/include/linux/xfs_fs.h - 1.15 - add definition of XFS_SUPER_MAGIC for use by statfs(2) from user space. linux/include/linux/grio.h - 1.3 linux/include/linux/vnode.h - 1.4 - remove leftover SIM macros. From owner-linux-xfs@oss.sgi.com Fri Sep 29 02:47:54 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 02:47:44 -0700 Received: from edge.coltex.nl ([194.151.97.115]:26630 "EHLO lsinet.coltex.nl") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 02:47:24 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e8T9lKE23716 for ; Fri, 29 Sep 2000 11:47:21 +0200 Message-Id: <4.3.2.7.2.20000929114015.02aec2e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Sep 2000 11:46:53 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: RedHat 7.0 - unbootable In-Reply-To: <200009281615.LAA14374@jen.americas.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 11:15 AM 9/28/2000 -0500, you wrote: > > At 09:53 AM 9/28/2000 -0500, you wrote: > > >Steve Lord wrote: >Hmm, I am not sure what the kernel had to do with login problems - I take it >a redhat supplied kernel does not give you this grief. It appears proc is not being mounted this is the command in /etc/rc.d/rc.sysinit action "Mounting proc filesystem: " mount -n -t proc /proc /proc This is the same on a redhat 6.1 box After that it goes into a downwards spiral because there is no proc and the init can't write it's parameters in there. Is this something which was on the buglist for test5? It would make a great candidate. I recompiled the kernel with kgcc (gcc 2.91.66 indeed) and it compiles everything without problems. This is indeed a oneline fix. Still no difference in boot behaviour. And oh, because of this /proc maddness you can't boot single user.... bummer. Bye -- Seth "Have you gone mad?" "Well, yes, but that's beyond the scope of this email." From owner-linux-xfs@oss.sgi.com Fri Sep 29 03:40:58 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 03:40:48 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7991 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 03:40:30 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id DAA01946 for ; Fri, 29 Sep 2000 03:47:26 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id FAA13881; Fri, 29 Sep 2000 05:39:12 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id FAA87482; Fri, 29 Sep 2000 05:39:12 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id FAA18571; Fri, 29 Sep 2000 05:34:27 -0500 Message-Id: <200009291034.FAA18571@jen.americas.sgi.com> To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 - unbootable From: lord@sgi.com In-reply-to: Your message of "Fri, 29 Sep 2000 11:46:53 +0200 Date: Fri, 29 Sep 2000 05:34:27 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > At 11:15 AM 9/28/2000 -0500, you wrote: > > > At 09:53 AM 9/28/2000 -0500, you wrote: > > > >Steve Lord wrote: > >Hmm, I am not sure what the kernel had to do with login problems - I take it > >a redhat supplied kernel does not give you this grief. > > It appears proc is not being mounted > > this is the command in /etc/rc.d/rc.sysinit > action "Mounting proc filesystem: " mount -n -t proc /proc /proc > This is the same on a redhat 6.1 box > > After that it goes into a downwards spiral because there is no proc and the > init can't write it's parameters in there. Is this something which was on > the buglist for test5? It would make a great candidate. > > I recompiled the kernel with kgcc (gcc 2.91.66 indeed) and it compiles > everything without problems. This is indeed a oneline fix. > Still no difference in boot behaviour. > > And oh, because of this /proc maddness you can't boot single user.... > bummer. > > Bye > > -- > Seth > "Have you gone mad?" > "Well, yes, but that's beyond the scope of this email." All I can say at the moment is that I run XFS kernels everyday on a redhat 6.2 system. We have duplicated this exact behavior, and should have a solution shortly - there is nothing special about /proc in our kernel. We should figure this one out soon. Steve From owner-linux-xfs@oss.sgi.com Fri Sep 29 03:45:49 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 03:45:39 -0700 Received: from Cantor.suse.de ([194.112.123.193]:54541 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Fri, 29 Sep 2000 03:45:19 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 85FD51E113; Fri, 29 Sep 2000 12:45:17 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 51BC43E44F; Fri, 29 Sep 2000 12:45:17 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 1F4772F301; Fri, 29 Sep 2000 12:45:13 +0200 (MEST) Date: Fri, 29 Sep 2000 12:45:13 +0200 From: "Andi Kleen" To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: XFS CVS development tree moving up to test8 Message-ID: <20000929124513.A14471@gruyere.muc.suse.de> References: <200009282244.RAA10742@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200009282244.RAA10742@jen.americas.sgi.com>; from lord@sgi.com on Thu, Sep 28, 2000 at 05:44:39PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, Sep 28, 2000 at 05:44:39PM -0500, Steve Lord wrote: > Because we have some unofficial system calls in the tree for xfs and > there are other new system calls in test8 I would recommend a command > rebuild after this (make clean; make). This really only affects extended > attribute code, but these calls are in some of the command binaries, > and some of the test programs will fail if this is not done. Do you have plans to disable the system calls for the beta ? (or allocate official slots for them) -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 29 05:26:30 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 05:26:20 -0700 Received: from office.mandrakesoft.com ([195.68.114.34]:63736 "HELO tourist.mandrakesoft.com") by oss.sgi.com with SMTP id ; Fri, 29 Sep 2000 05:26:06 -0700 Received: by tourist.mandrakesoft.com (Postfix, from userid 501) id 7A24696A7; Fri, 29 Sep 2000 14:26:02 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: xfs.o = 19M ? From: Chmouel Boudjnah Date: 29 Sep 2000 14:26:02 +0200 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I just compiled the last xfs branch from the CVS and noticed that the xfs.o is : [chmou@pasadenas chmou]$ du -sh /lib/modules/2.4.0-test8/kernel/fs/xfs/xfs.o 19M /lib/modules/2.4.0-test8/kernel/fs/xfs/xfs.o is it normal ? it's a bit large for an initrd... -- MandrakeSoft Inc http://www.chmouel.org Paris, France --Chmouel From owner-linux-xfs@oss.sgi.com Fri Sep 29 06:53:20 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 06:53:00 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:44615 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 06:52:30 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA05265 for ; Fri, 29 Sep 2000 06:44:46 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id IAA18291; Fri, 29 Sep 2000 08:49:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id IAA12964; Fri, 29 Sep 2000 08:49:52 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id IAA18832; Fri, 29 Sep 2000 08:45:06 -0500 Message-Id: <200009291345.IAA18832@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Chmouel Boudjnah cc: linux-xfs@oss.sgi.com Subject: Re: xfs.o = 19M ? In-Reply-To: Message from Chmouel Boudjnah of "29 Sep 2000 14:26:02 +0200." Date: Fri, 29 Sep 2000 08:45:00 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hi, > > I just compiled the last xfs branch from the CVS and noticed that the > xfs.o is : > > [chmou@pasadenas chmou]$ du -sh /lib/modules/2.4.0-test8/kernel/fs/xfs/xfs.o > 19M /lib/modules/2.4.0-test8/kernel/fs/xfs/xfs.o We currently have debugging symbols turned on in the xfs module, if you were to take out the -g3 in the make files you will find they shrink a lot. The loaded module is still large, but a lot smaller than this: Module Size Used by xfs 482715 0 (autoclean) pagebuf 41115 0 (autoclean) [xfs] nfs 90542 2 (autoclean) autofs 13469 4 (autoclean) ide-cd 28339 0 (autoclean) cdrom 31015 0 (autoclean) [ide-cd] floppy 52516 0 (autoclean) Something about test8 made it grow about 50Kbytes, not sure what yet. Steve > > is it normal ? it's a bit large for an initrd... > > -- > MandrakeSoft Inc http://www.chmouel.org > Paris, France --Chmouel From owner-linux-xfs@oss.sgi.com Fri Sep 29 06:57:50 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 06:57:30 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:49224 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 06:57:22 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA05802 for ; Fri, 29 Sep 2000 06:49:37 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id IAA43366; Fri, 29 Sep 2000 08:54:39 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id IAA03861; Fri, 29 Sep 2000 08:54:39 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id IAA18870; Fri, 29 Sep 2000 08:49:53 -0500 Message-Id: <200009291349.IAA18870@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Andi Kleen" cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: XFS CVS development tree moving up to test8 In-Reply-To: Message from "Andi Kleen" of "Fri, 29 Sep 2000 12:45:13 +0200." <20000929124513.A14471@gruyere.muc.suse.de> Date: Fri, 29 Sep 2000 08:49:53 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Thu, Sep 28, 2000 at 05:44:39PM -0500, Steve Lord wrote: > > Because we have some unofficial system calls in the tree for xfs and > > there are other new system calls in test8 I would recommend a command > > rebuild after this (make clean; make). This really only affects extended > > attribute code, but these calls are in some of the command binaries, > > and some of the test programs will fail if this is not done. > > Do you have plans to disable the system calls for the beta ? (or allocate > official slots for them) > > -Andi The calls are in the beta images - and the caveat list says they will change. Since nothing as yet is really using them I was not in a hurry to get this sorted out - but it does make tree merges a pain. We do need to find a solution, although I suspect it would only be a temporary one given the fact that there is at least one other extended attribute interface out there (http://acl.bestbits.at/). It has just not made it to the top of the list yet. Steve From owner-linux-xfs@oss.sgi.com Fri Sep 29 07:02:20 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 07:02:00 -0700 Received: from Cantor.suse.de ([194.112.123.193]:45839 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Fri, 29 Sep 2000 07:01:46 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id B69201E16E; Fri, 29 Sep 2000 16:01:44 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 76AD23E44F; Fri, 29 Sep 2000 16:01:44 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id E95142F300; Fri, 29 Sep 2000 16:01:43 +0200 (MEST) Date: Fri, 29 Sep 2000 16:01:43 +0200 From: "Andi Kleen" To: Steve Lord Cc: "Andi Kleen" , linux-xfs@oss.sgi.com Subject: Re: XFS CVS development tree moving up to test8 Message-ID: <20000929160143.A19429@gruyere.muc.suse.de> References: <200009291349.IAA18870@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200009291349.IAA18870@jen.americas.sgi.com>; from lord@sgi.com on Fri, Sep 29, 2000 at 08:49:53AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, Sep 29, 2000 at 08:49:53AM -0500, Steve Lord wrote: > > On Thu, Sep 28, 2000 at 05:44:39PM -0500, Steve Lord wrote: > > > Because we have some unofficial system calls in the tree for xfs and > > > there are other new system calls in test8 I would recommend a command > > > rebuild after this (make clean; make). This really only affects extended > > > attribute code, but these calls are in some of the command binaries, > > > and some of the test programs will fail if this is not done. > > > > Do you have plans to disable the system calls for the beta ? (or allocate > > official slots for them) > > > > -Andi > > > The calls are in the beta images - and the caveat list says they will > change. Since nothing as yet is really using them I was not in a hurry > to get this sorted out - but it does make tree merges a pain. We do need > to find a solution, although I suspect it would only be a temporary one > given the fact that there is at least one other extended attribute > interface out there (http://acl.bestbits.at/). It has just not made it to > the top of the list yet. The big problem is that there is no reliable way to detect these calls. If Linus adds another system call there it may just cause the the XFS programs to crash in weird ways. When nobody is using them yet I would suggest to disable them unless a final solution for the API is found. -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 29 08:34:40 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 08:34:21 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:37530 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 08:33:51 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id KAA08760; Fri, 29 Sep 2000 10:33:18 -0500 (CDT) Message-Id: <4.2.0.58.20000929100534.01a26840@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 29 Sep 2000 10:35:53 -0500 To: Steve Lord From: "William L. Jones" Subject: Re: sync crash Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <"William L. Jones"'s message of "Fri, 29 Sep 2000 08:39:56 -0500"> <4.2.0.58.20000929083756.01a14d00@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve, I think that _pagebuf_page_io called ll_rw_block, line 1436 in _pagebuf_page_io, with a rw value of WRITERAW which past it to generic_make_request which barfs on it. ll_rw_block nows about WRITERAW but generic_make_request does not I think the may be a missing a patch? I updated my source and ll_rw_blk.c is still the same. Bill Jones From owner-linux-xfs@oss.sgi.com Fri Sep 29 08:38:50 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 08:38:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:7270 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 08:38:28 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA20286 for ; Fri, 29 Sep 2000 08:30:43 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA50240; Fri, 29 Sep 2000 10:36:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id KAA12408; Fri, 29 Sep 2000 10:36:43 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id KAA20057; Fri, 29 Sep 2000 10:31:56 -0500 Message-Id: <200009291531.KAA20057@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "William L. Jones" cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: sync crash In-Reply-To: Message from "William L. Jones" of "Fri, 29 Sep 2000 10:35:53 CDT." <4.2.0.58.20000929100534.01a26840@127.0.0.1> Date: Fri, 29 Sep 2000 10:31:56 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Steve, > > I think that _pagebuf_page_io called ll_rw_block, line 1436 in > _pagebuf_page_io, with > a rw value of WRITERAW which past it > to generic_make_request which barfs on it. > > > ll_rw_block nows about WRITERAW but generic_make_request does not > > I think the may be a missing a patch? I updated my source and ll_rw_blk.c > is still > the same. > > Bill Jones Hmm, looks like I missed one, WRITERAW is really gone in test8, but we needed to bypass getting buffers on the various lists, so I kept it in. I will take a look. Thanks Steve From owner-linux-xfs@oss.sgi.com Fri Sep 29 08:48:11 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 08:47:51 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:55195 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 08:47:42 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id KAA08957; Fri, 29 Sep 2000 10:47:32 -0500 (CDT) Message-Id: <4.2.0.58.20000929104810.01a316a0@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 29 Sep 2000 10:50:07 -0500 To: Steve Lord , "William L. Jones" From: "William L. Jones" Subject: Re: sync crash Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <200009291531.KAA20057@jen.americas.sgi.com> References: <4.2.0.58.20000929100534.01a26840@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I took another look at _pagebuf_page_io and the only time we take the WRITERAW path is on LVM file systems. Which probaly explains why you didn't see it. At 10:31 AM 9/29/00 -0500, Steve Lord wrote: > > > > Steve, > > > > I think that _pagebuf_page_io called ll_rw_block, line 1436 in > > _pagebuf_page_io, with > > a rw value of WRITERAW which past it > > to generic_make_request which barfs on it. > > > > > > ll_rw_block nows about WRITERAW but generic_make_request does not > > > > I think the may be a missing a patch? I updated my source and ll_rw_blk.c > > is still > > the same. > > > > Bill Jones > > >Hmm, looks like I missed one, WRITERAW is really gone in test8, but we needed >to bypass getting buffers on the various lists, so I kept it in. I will take >a look. > >Thanks > > Steve > > From owner-linux-xfs@oss.sgi.com Fri Sep 29 09:11:30 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 09:11:21 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:12914 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 09:11:20 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA26324 for ; Fri, 29 Sep 2000 09:03:36 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA6207231 for ; Fri, 29 Sep 2000 11:10:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id LAA21742 for ; Fri, 29 Sep 2000 11:10:02 -0500 (CDT) Received: (from lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) id LAA21251 for linux-xfs@oss.sgi.com; Fri, 29 Sep 2000 11:05:15 -0500 Date: Fri, 29 Sep 2000 11:05:15 -0500 From: Steve Lord Message-Id: <200009291605.LAA21251@jen.americas.sgi.com> Subject: TAKE - fix LVM To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Sep 29 09:09:40 PDT 2000 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:75365a linux/drivers/block/ll_rw_blk.c - 1.43 - fix type which broke lvm volumes From owner-linux-xfs@oss.sgi.com Fri Sep 29 09:13:31 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 09:13:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:60274 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 09:13:06 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA26664 for ; Fri, 29 Sep 2000 09:05:21 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA6240991 for ; Fri, 29 Sep 2000 11:11:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id LAA34111 for ; Fri, 29 Sep 2000 11:11:48 -0500 (CDT) Received: (from lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) id LAA21372 for linux-xfs@oss.sgi.com; Fri, 29 Sep 2000 11:07:01 -0500 Date: Fri, 29 Sep 2000 11:07:01 -0500 From: Steve Lord Message-Id: <200009291607.LAA21372@jen.americas.sgi.com> Subject: TAKE - alpha build fix To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Sep 29 09:11:32 PDT 2000 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:75366a linux/fs/pagebuf/page_buf.c - 1.35 linux/fs/pagebuf/page_buf_io.c - 1.30 - Use softirq.h rather than hardirq.h - fix for alpha build From owner-linux-xfs@oss.sgi.com Fri Sep 29 12:07:53 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 12:07:34 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40289 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 12:07:14 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA01988 for ; Fri, 29 Sep 2000 12:14:10 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA6258336 for ; Fri, 29 Sep 2000 14:05:57 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id OAA53357 for ; Fri, 29 Sep 2000 14:05:57 -0500 (CDT) Received: (from lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) id OAA26597 for linux-xfs@oss.sgi.com; Fri, 29 Sep 2000 14:01:09 -0500 Date: Fri, 29 Sep 2000 14:01:09 -0500 From: Steve Lord Message-Id: <200009291901.OAA26597@jen.americas.sgi.com> Subject: TAKE - remove some recent XFS allocator changes To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a merge of an Irix change to back out some algorithmic changes in the xfs allocator and mkfs programs. There was a change to use stripe width rather than stripe unit alignment in allocations for these filesystems. The code worked just fine, the problem is it hammered the first disk in a stripe and killed performance in some configurations. A different version of this fix will come along one day. Merge Irix mod to Back out stripe width alignment Date: Fri Sep 29 12:03:03 PDT 2000 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:75389a cmd/xfs/mkfs/xfs_mkfs.c - 1.177 linux/fs/xfs/xfs_vnodeops.c - 1.475 linux/fs/xfs/xfs_mount.c - 1.242 linux/fs/xfs/xfs_bmap.h - 1.76 linux/fs/xfs/xfs_bmap.c - 1.261 linux/fs/xfs/linux/xfs_lrw.c - 1.58 cmd/xfs/include/xfs_bmap.h - 1.6 cmd/xfs/libxfs/xfs_bmap.c - 1.4 From owner-linux-xfs@oss.sgi.com Fri Sep 29 12:15:54 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 12:15:34 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23906 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 12:15:19 -0700 Received: from chuckle.americas.sgi.com (chuckle.americas.sgi.com [128.162.184.123]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA02381 for ; Fri, 29 Sep 2000 12:22:16 -0700 (PDT) mail_from (root@chuckle.americas.sgi.com) Received: (from root@localhost) by chuckle.americas.sgi.com (8.9.3/8.9.3) id OAA12829 for linux-xfs@oss.sgi.com; Fri, 29 Sep 2000 14:15:55 -0500 Date: Fri, 29 Sep 2000 14:15:55 -0500 From: root Message-Id: <200009291915.OAA12829@chuckle.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Sep 29 12:13:55 PDT 2000 Workarea: chuckle.americas.sgi.com:/export/extra/x2.4-xfs-beta The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-beta Modid: 2.4.x-xfs-beta:slinx:75391a SPECS/kernel-2.4non_pp_xfsbeta.spec - 1.1 SPECS/kernel-2.4pp_xfsbeta.spec - 1.1 - Save spec file used to build XFS beta images From owner-linux-xfs@oss.sgi.com Fri Sep 29 14:06:14 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 14:05:54 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:48709 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 14:05:23 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA04242 for ; Fri, 29 Sep 2000 13:57:39 -0700 (PDT) mail_from (lord@jen.americas.sgi.com) Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id QAA6260877; Fri, 29 Sep 2000 16:02:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id QAA13972; Fri, 29 Sep 2000 16:02:49 -0500 (CDT) Received: from jen.americas.sgi.com (lord@localhost) by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id PAA26957; Fri, 29 Sep 2000 15:58:00 -0500 Message-Id: <200009292058.PAA26957@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Davida, Joe" cc: linux-xfs@oss.sgi.com Subject: Re: librmt In-Reply-To: Message from "Davida, Joe" of "Fri, 29 Sep 2000 13:37:13 MDT." <09D1E9BD9C30D311919200A0C9DD5C2C02536FCC@mcaexc01.msj.maxtor.com> Date: Fri, 29 Sep 2000 15:58:00 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Thanks Steve, > I did a complete fresh checkout and it > brought in librmt. > > I have a question re: best layout of the raid > array. For best performance for small files, > what should the raid stripe size be? The > Xtremeraid2000 allows a minimum raid block > size of 8KB per disk in the stripe, max is > 64KB. Concurrent to this, what should be the > XFS block size for best I/O > performance on lots of small files? I was thinking > that the FileSystem block size should in all > cases be identical to stripe block size, to allow > as much parallellism of I/O on the drives in the raid > as possible. > > Cheers, > > Joe > First of all, we are currently only supporting 4K filesystem block size, so for now you should use this. I don't really have a hard and fast answer for what would behave best for small files, since at SGI striped file systems usually go together with big I/O. But I would try 8K for now. Steve p.s. how goes the mkfs issue? From owner-linux-xfs@oss.sgi.com Fri Sep 29 18:46:55 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 18:46:35 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:10763 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Fri, 29 Sep 2000 18:46:09 -0700 Received: (qmail 10867 invoked from network); 30 Sep 2000 01:46:03 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 30 Sep 2000 01:46:03 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 - unbootable In-reply-to: Your message of "Fri, 29 Sep 2000 11:46:53 +0200." <4.3.2.7.2.20000929114015.02aec2e0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Sep 2000 12:46:03 +1100 Message-ID: <5344.970278363@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 29 Sep 2000 11:46:53 +0200, Seth Mos wrote: >And oh, because of this /proc maddness you can't boot single user.... >bummer. At boot prompt, type the kernel label and append "init=/bin/sh". Gives you a single user system without executing the startup scripts. You have to "mount -o remount,rw /" to make any changes to /. To shutdown from this mode, "mount -o remount,ro /", sync a couple of times then "halt -fn". From owner-linux-xfs@oss.sgi.com Fri Sep 29 18:48:45 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 18:48:26 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:12811 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Fri, 29 Sep 2000 18:48:12 -0700 Received: (qmail 10893 invoked from network); 30 Sep 2000 01:48:09 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 30 Sep 2000 01:48:09 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Chmouel Boudjnah cc: linux-xfs@oss.sgi.com Subject: Re: xfs.o = 19M ? In-reply-to: Your message of "29 Sep 2000 14:26:02 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Sep 2000 12:48:08 +1100 Message-ID: <5385.970278488@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 29 Sep 2000 14:26:02 +0200, Chmouel Boudjnah wrote: >[chmou@pasadenas chmou]$ du -sh /lib/modules/2.4.0-test8/kernel/fs/xfs/xfs.o >19M /lib/modules/2.4.0-test8/kernel/fs/xfs/xfs.o > >is it normal ? it's a bit large for an initrd... strip -S /lib/modules/2.4.0-test8/kernel/fs/xfs/xfs.o before mkinitrd. From owner-linux-xfs@oss.sgi.com Sat Sep 30 15:20:52 2000 Received: by oss.sgi.com id ; Sat, 30 Sep 2000 15:20:43 -0700 Received: from p3E9EDEF4.dip.t-dialin.net ([62.158.222.244]:37526 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Sat, 30 Sep 2000 15:20:30 -0700 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.9.3/8.9.3) id XAA01079 for linux-xfs@oss.sgi.com; Sat, 30 Sep 2000 23:35:27 +0200 Date: Sat, 30 Sep 2000 23:35:27 +0200 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 - unbootable Message-ID: <20000930233527.A926@s2y4n2c.de> References: <4.3.2.7.2.20000929114015.02aec2e0@pop.xs4all.nl> <5344.970278363@ocs3.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <5344.970278363@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hello redhat 7.0 ist unbootable with my xfs kernel (old one, cvs from 2000-08-17, compiled on redhat 6.2) with the same errors. the redhat 7.0 installation is on a ext2 partition. i have bootet the original redhat 7.0 kernel (2.2.16-22) and the xfs kernel (2.4.0-test5-xfs-20000817) with "init=/bin/bash" on lilo prompt. and done following: mount -orw,remount / strace -o ls.strace-`uname -r` i attached both strace outputs. i think the xfs kernel (all 2.4.0-test5 kernels?) returns the wrong error on fstat64. original redhat 7.0 kernel: [...] open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 ENOSYS (Function not implemented) fcntl(4, F_SETFD, FD_CLOEXEC) = 0 brk(0x8059000) = 0x8059000 [...] xfs kernel: [...] open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 EFAULT (Bad address) close(4) = 0 write(2, "ls: ", 4) = 4 write(2, "/", 1) = 1 write(2, ": Bad address", 13) = 13 write(2, "\n", 1) = 1 close(1) = 0 _exit(1) = ? hope that helps. utz lehmann From owner-linux-xfs@oss.sgi.com Sat Sep 30 15:25:52 2000 Received: by oss.sgi.com id ; Sat, 30 Sep 2000 15:25:33 -0700 Received: from p3E9EDEF4.dip.t-dialin.net ([62.158.222.244]:38294 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Sat, 30 Sep 2000 15:25:16 -0700 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.9.3/8.9.3) id XAA01133 for linux-xfs@oss.sgi.com; Sat, 30 Sep 2000 23:40:17 +0200 From: utz@s2y4n2c.de Date: Sat, 30 Sep 2000 23:40:17 +0200 To: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 - unbootable Message-ID: <20000930234017.A1106@s2y4n2c.de> References: <4.3.2.7.2.20000929114015.02aec2e0@pop.xs4all.nl> <5344.970278363@ocs3.ocs-net> <20000930233527.A926@s2y4n2c.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" X-Mailer: Mutt 1.0.1i In-Reply-To: <20000930233527.A926@s2y4n2c.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii sorry forgot the attachments... utz lehmann [xfs@s2y4n2c.de] wrote: > hello > > redhat 7.0 ist unbootable with my xfs kernel (old one, cvs from 2000-08-17, > compiled on redhat 6.2) with the same errors. > the redhat 7.0 installation is on a ext2 partition. > > i have bootet the original redhat 7.0 kernel (2.2.16-22) and the xfs kernel > (2.4.0-test5-xfs-20000817) with "init=/bin/bash" on lilo prompt. and done > following: > > mount -orw,remount / > strace -o ls.strace-`uname -r` > > i attached both strace outputs. > > i think the xfs kernel (all 2.4.0-test5 kernels?) returns the wrong error on > fstat64. > > original redhat 7.0 kernel: > [...] > open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 > fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 ENOSYS (Function not > implemented) > fcntl(4, F_SETFD, FD_CLOEXEC) = 0 > brk(0x8059000) = 0x8059000 > [...] > > xfs kernel: > [...] > open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 > fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 EFAULT (Bad address) > close(4) = 0 > write(2, "ls: ", 4) = 4 > write(2, "/", 1) = 1 > write(2, ": Bad address", 13) = 13 > write(2, "\n", 1) = 1 > close(1) = 0 > _exit(1) = ? > > > > hope that helps. > > utz lehmann --fUYQa+Pmc3FrFX/N Content-Type: application/octet-stream Content-Disposition: attachment; filename="ls.strace-2.2.16-22.gz" Content-Transfer-Encoding: base64 H4sICO5U1jkAA2xzLnN0cmFjZS0yLjIuMTYtMjIAvVdbc9o4FH7nV2h4Ml0Cku88MJ2UmCxT ijNAt02XjsexRfHEtjy2kpAm/e97JAPh1gTSzML4Jut8OvrO1XROg1uqVJtXUdqMi2od/VuV l2qz+h0emu8Q0dCtnxfoXfN7DbURrnjFfRHwWHl46Iz73kdnOKgjcfbc0dDpO6cj51cdqQCh NtQGMU9UFfBadTT43O/XEf5Volzl1wquoRd/MHduY0OzArvC4tBLEj9TSigdt8w6uhi6Y2/o nJ49yrsvw97YqaNPpxfexbD3z+nYeRT3pwN3cPnJ/TyqoxMCWkgl5jrGxMQYV1hGU2CB8qAZ h42CNbKcxswPQXPXG565g/5lrdTmhCBn4DqDMVIGDBU3wQxNo5gilqMwymnAWX5f28UL/GBG t9EEnl6ZFtznpq7ooNb8ago/0w72MLNce3Q5Qkr3Jg14xFKUMo6iJItpQlNOw1oJJ8AeCu4l LKTtkdfrDp3zR2zqMAyjRfSTtnWsYquOGo3GwiI77Mr3K3o3OIXXGyRagsQgZgVV9BeNKhcr CYqjK3FwmieBnwmi1E2SVgTt35FlGE87Iiq27fUd5dQPhVx1QizL6XcnRP7xzl9bHIt32YSY 4opxFcBKRxOI4rpNEzGIteuFzlen8xxhKhGEJVnOOLiMUo7BgSFybLEJiQI+69SWhC2XXZ97 TAR0e1+ds1KNuQrST7rof2a8QJjN3PXt44ynm7aJLestzDdRNTisQ4xHTEsz7ePNZ+yYj2gt aRKAs9RN++2YbzlX1Y09vnOA/QjR1ixYwm0vMZVLEFU90kWeTZcl7FHOktykK7eVeWKRWraF xdwflGdRqByAS4xXVRApI59s/JzsUgZmPcno+BAZGU08Sqj0sRf0a6OWhTXQTdUrERNVFdge d86dMTD/8EGzAQ2xjBWQ5IvoB4oCP4WkT4MZWwuUJ8me2zn/0huMvoH0XeHl7K6tQpDBbcDi to3l7TyL5jRulw/3i4f1siy2YR20WZn340UBg56hvuTN2OMcBxYwCVeCbeSMs95wO2fI9LdW wcq8FNLbZnoTx2sp6dEVwfih73Y+wi0gOZ2xO7ysrXQaw5io6Bz5e+r4YUi/S3YvKz4NUh6X LUDXGznjLgR698zr9F2RiWrHMijhXgRDmwZvHWRwmWkgTENYqlg2LTBumthe5tpj1V3CCTBo ODWC4CmPqOg5IaFqLVJbwBm6vj0b/2ay3Nwrippo2RLuX+2rZ4u5zxa1jR5L1Z9tsN6ifZUR uKqU0vdnoa+jJqJzrqL8DhjCk7T6VAgh1azmV3dstsPLH+f6PfBrfEMNBcJpEqVTtpfzQ1vu 0iZkyyadvyH2TFWVNsmBnXbiX1O4KhCOpPb/mOf1mf0ujzgVklX4QAMywDvhfJ1N+ITHRaPg uR/QCZdExWW/Y9hC1LDXZRmEHJr5MZyhYdsQPpFfaaWoqQlRU1sTBaYAesYSCqKg7F9TdpOG IH9LBIxYd7GsLpfVF/5C3txfPDqP+AEFv43eV/4DS4t3/dcOAAA= --fUYQa+Pmc3FrFX/N Content-Type: application/octet-stream Content-Disposition: attachment; filename="ls.strace-2.4.0-test5-xfs-20000817.gz" Content-Transfer-Encoding: base64 H4sICIJR1jkAA2xzLnN0cmFjZS0yLjQuMC10ZXN0NS14ZnMtMjAwMDA4MTcArVbtb5pAGP/u X3HxEyyod4BAl5jF6tmYMWiQbuvmQiicKxkK4a6tXbv/fXdgK+padRvk5F6e53fP+yNZkuiW SM3OVbLopLSpgK/N8tPsNL/xRecNQDq4DQsK3nS+yaAHYCOg9zRiqfTwMPDt4D32HAWI38Cd eNjG/Qn+pQCVQ6htvQ1bjFDWbS1ntKVC/ljI5PCqrgDnwrYVAH9VqFfFDwnKYO/DaZcW7Gpm ZDWyNA7m8zCXKigdnhgKOPdcP/Bwf/hYzj55Yx8r4EP/PDj3xh/7Pn4U877jOpcf3IuJAlqI S1EKsdQhRAYXspHlZMGtQljUSeM2zdp5QdIsjLnobuANXce+lCtpWghgx8WODyQnA/Qmugaz JCUgK0CcFCRiWXEv7+JFYXRNttEEnt6YURYyQ5e4iR4oC+ZZTHqTYDzy8NkjNHS+zXdp8pP0 dKhCUwHtdntlxB2DlOfPFtkwAz/e0NsUekdpRomk7/VDeVmlU5pcicFIMY/CXOimbuq1Vyez 213rhFRoWXWdChLGgq85RaaJ7dEUlS/cebXVWJ3lU2SIL4RNDlZFh0AU321DoS4yd0MHf8aD 10ymImGyeV5kjPtZqvb4gDy+LaFEicIDDctPJnu6tk57TNiOxp/xsBJjKdJpLYv+b+6LhOOM 3YA81n26YRnQNP+HA6eqxod5iPuQYWqGdbwDuzsORNpJ6RQOZ6qbHtxx4BOtqnf/ED0HeBAh rebDCm77ill5BVLVI4Pk1SpXwR4VLvObxXPglrViVV62mQXtd8LyJJYOwFXVvyr8JU+5suBr vE88nGrNo8NDeMp8YsmclDG2R74eODGh1lUtZDSSTDRHbm1/cIZ9bvmHU83iaCDLM8pAQpPv IInCRbYAJLrOaomy5hy7g7NPY2fyhXPf0aDI7noqTzI+jbK0Z8FyusyTJUl71eJ+tah3U6GG eZCyZe1PV0nOW/9Wmg/H3naalzWr1niqYhKT287iJk1rdeTRFflzaruD93zKkfDAd71L+bl1 +nxP9E4Gwj90zMOQXq5Q+0WfRQuWVpyjYIL9Ec/O0TAY2K4oH3LNVELeUf/C5q3+NIxBGMcF oVQ+Ko3uioQRSfw7SulbwLV7gU3otKYVZkAv4vcAqtG+BTXhBJ8mb9JqNeLp4jVkAVwp9/Ll deUCskzYQbTvGr8Bj/zN/XoKAAA= --fUYQa+Pmc3FrFX/N-- From owner-linux-xfs@oss.sgi.com Sat Sep 30 17:10:13 2000 Received: by oss.sgi.com id ; Sat, 30 Sep 2000 17:09:53 -0700 Received: from hermes.mixx.net ([212.84.196.2]:36100 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 30 Sep 2000 17:09:23 -0700 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 8D2E3F9AC for ; Sun, 1 Oct 2000 02:09:21 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 6BAC72CA6D; Sun, 1 Oct 2000 02:09:21 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: RedHat 7.0 - unbootable Date: 1 Oct 2000 00:09:21 GMT Organization: innominate AG, Berlin, Germany Lines: 63 Distribution: local Message-ID: References: <4.3.2.7.2.20000929114015.02aec2e0@pop.xs4all.nl> <5344.970278363@ocs3.ocs-net> <20000930233527.A926@s2y4n2c.de> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 970358961 25663 10.0.0.69 (1 Oct 2000 00:09:21 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test5 (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing i think a good idea would also be to compare clean 2.4.0-test5/8 and the xfs tree - maybe it is not really an xfs issuse and more an "redhat adds dozens of patches to its kernel" thing? - maybe the same problem also exists with clean 2.4.0 ... just an idea - maybe someone can try it out (have myself no 7.0 set up so far to test it) t utz lehmann wrote: > hello > redhat 7.0 ist unbootable with my xfs kernel (old one, cvs from 2000-08-17, > compiled on redhat 6.2) with the same errors. > the redhat 7.0 installation is on a ext2 partition. > i have bootet the original redhat 7.0 kernel (2.2.16-22) and the xfs kernel > (2.4.0-test5-xfs-20000817) with "init=/bin/bash" on lilo prompt. and done > following: > mount -orw,remount / > strace -o ls.strace-`uname -r` > i attached both strace outputs. > i think the xfs kernel (all 2.4.0-test5 kernels?) returns the wrong error on > fstat64. > original redhat 7.0 kernel: > [...] > open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 > fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 ENOSYS (Function not > implemented) > fcntl(4, F_SETFD, FD_CLOEXEC) = 0 > brk(0x8059000) = 0x8059000 > [...] > xfs kernel: > [...] > open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 > fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 EFAULT (Bad address) > close(4) = 0 > write(2, "ls: ", 4) = 4 > write(2, "/", 1) = 1 > write(2, ": Bad address", 13) = 13 > write(2, "\n", 1) = 1 > close(1) = 0 > _exit(1) = ? > hope that helps. > utz lehmann -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sat Sep 30 18:13:44 2000 Received: by oss.sgi.com id ; Sat, 30 Sep 2000 18:13:34 -0700 Received: from pC19F0202.dip.t-dialin.net ([193.159.2.2]:53142 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Sat, 30 Sep 2000 18:13:10 -0700 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.9.3/8.9.3) id CAA02726; Sun, 1 Oct 2000 02:27:27 +0200 From: xfs@s2y4n2c.de Date: Sun, 1 Oct 2000 02:27:27 +0200 To: Thomas Graichen Cc: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 - unbootable Message-ID: <20001001022727.A2644@s2y4n2c.de> References: <4.3.2.7.2.20000929114015.02aec2e0@pop.xs4all.nl> <5344.970278363@ocs3.ocs-net> <20000930233527.A926@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi i just checked it with a vanila 2.4.0-test5. it works. open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 ENOSYS (Function not implemented) fcntl(4, F_SETFD, FD_CLOEXEC) = 0 seems that the xfs patch does something wrong. or the new glibc is not fault tolerant enough. i made the ls test with my redhat 6.2 installation on a xfs root partition. fcntl64 is not used. open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 brk(0x8068000) = 0x8068000 i just make a complete cvs checkout and will test the newest xfs kernel. utz btw: thanks to sgi for porting xfs to linux. i know it from irix. best filesystem i know. Thomas Graichen [news-innominate.list.sgi.xfs@innominate.de] wrote: > i think a good idea would also be to compare clean 2.4.0-test5/8 and > the xfs tree - maybe it is not really an xfs issuse and more an > "redhat adds dozens of patches to its kernel" thing? - maybe > the same problem also exists with clean 2.4.0 ... just an > idea - maybe someone can try it out (have myself no 7.0 > set up so far to test it) > > t > > utz lehmann wrote: > > hello > > > redhat 7.0 ist unbootable with my xfs kernel (old one, cvs from 2000-08-17, > > compiled on redhat 6.2) with the same errors. > > the redhat 7.0 installation is on a ext2 partition. > > > i have bootet the original redhat 7.0 kernel (2.2.16-22) and the xfs kernel > > (2.4.0-test5-xfs-20000817) with "init=/bin/bash" on lilo prompt. and done > > following: > > > mount -orw,remount / > > strace -o ls.strace-`uname -r` > > > i attached both strace outputs. > > > i think the xfs kernel (all 2.4.0-test5 kernels?) returns the wrong error on > > fstat64. > > > original redhat 7.0 kernel: > > [...] > > open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 > > fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > > fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 ENOSYS (Function not > > implemented) > > fcntl(4, F_SETFD, FD_CLOEXEC) = 0 > > brk(0x8059000) = 0x8059000 > > [...] > > > xfs kernel: > > [...] > > open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 > > fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > > fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 EFAULT (Bad address) > > close(4) = 0 > > write(2, "ls: ", 4) = 4 > > write(2, "/", 1) = 1 > > write(2, ": Bad address", 13) = 13 > > write(2, "\n", 1) = 1 > > close(1) = 0 > > _exit(1) = ? > > > > > hope that helps. > > > utz lehmann > > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sat Sep 30 18:24:14 2000 Received: by oss.sgi.com id ; Sat, 30 Sep 2000 18:23:54 -0700 Received: from Cantor.suse.de ([194.112.123.193]:30734 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Sat, 30 Sep 2000 18:23:36 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 67FCD1E278; Sun, 1 Oct 2000 03:23:35 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 2CD7B3E44F; Sun, 1 Oct 2000 03:23:35 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 799922F300; Sun, 1 Oct 2000 03:23:34 +0200 (MEST) Date: Sun, 1 Oct 2000 03:23:34 +0200 From: "Andi Kleen" To: xfs@s2y4n2c.de Cc: Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 - unbootable Message-ID: <20001001032334.A11618@gruyere.muc.suse.de> References: <4.3.2.7.2.20000929114015.02aec2e0@pop.xs4all.nl> <5344.970278363@ocs3.ocs-net> <20000930233527.A926@s2y4n2c.de> <20001001022727.A2644@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001001022727.A2644@s2y4n2c.de>; from xfs@s2y4n2c.de on Sun, Oct 01, 2000 at 02:27:27AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, Oct 01, 2000 at 02:27:27AM +0200, xfs@s2y4n2c.de wrote: > hi > > i just checked it with a vanila 2.4.0-test5. it works. > > open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4 > fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > fcntl64(4, F_SETFD, FD_CLOEXEC) = -1 ENOSYS (Function not > implemented) > fcntl(4, F_SETFD, FD_CLOEXEC) = 0 > > seems that the xfs patch does something wrong. > or the new glibc is not fault tolerant enough. i made the ls test with my > redhat 6.2 installation on a xfs root partition. fcntl64 is not used. I think I know what the problem is. The old XFS beta5 kernel has attr_* system calls in the call slots that are fstat64() et.al. on the RH7.0/later 2.4 kernels. The RH7 glibc seems to expect LFS calls there (rightfully, because later 2.4 after test5 put them there). Calling the attr_* calls as different system calls does no good. Does it work when you replace the .long SYMBOL_NAME(sys_attr_get) .long SYMBOL_NAME(sys_attr_set) .long SYMBOL_NAME(sys_attr_remove) .long SYMBOL_NAME(sys_attr_list) .long SYMBOL_NAME(sys_attr_getf) .long SYMBOL_NAME(sys_attr_setf) .long SYMBOL_NAME(sys_attr_removef) .long SYMBOL_NAME(sys_attr_listf) lines at the end of arch/i386/kernel/entry.S with .long SYMBOL_NAME(sys_ni_syscall) for each attr line ? -Andi From owner-linux-xfs@oss.sgi.com Sat Sep 30 19:28:03 2000 Received: by oss.sgi.com id ; Sat, 30 Sep 2000 19:27:54 -0700 Received: from sun.rhrk.uni-kl.de ([131.246.137.50]:9363 "HELO sun.rhrk.uni-kl.de") by oss.sgi.com with SMTP id ; Sat, 30 Sep 2000 19:27:28 -0700 Received: from aixs1.rhrk.uni-kl.de ( exim@aixs1.rhrk.uni-kl.de [131.246.137.3] ) by sun.rhrk.uni-kl.de id aa16177 for ; 1 Oct 2000 04:27 MESZ Received: from trip210.wohnheim.uni-kl.de ([131.246.188.10] helo=student.uni-kl.de) by aixs1.rhrk.uni-kl.de with esmtp (Exim 3.03 #2) id 13fYqa-000DAg-00 for linux-xfs@oss.sgi.com; Sun, 01 Oct 2000 04:27:24 +0200 Message-ID: <39D6A1B2.DBB2061@student.uni-kl.de> Date: Sun, 01 Oct 2000 02:30:10 +0000 From: Ralf Sinoradzki X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Little Problem with XFS and Debian Woody Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi ! Perhaps there are some DEBIAN users listening who could help me: I've patched Kernel2.4.0-test5 with the XFS-beta-patch. After compiling with egcs 2.91.66 everything seemed to be OK. (gcc 2.95.2 did not work like it is mentioned in the FAQ) I'm using XFS on the /var,/usr,/home and /temp-partitions. When I install new packages with dselect, a lot of install- skripts fail ("cannot rmdir /var/lib/dpkg/tmp.ci"). There is a controlfile in it, that was not removed. If I remove it by hand, I can install the package but the next one stops with the same error. xfs_check said, that everything was ok. Then I copied '/var/lib/dpkg' to an ext2fs-partition and mounted it with 'mount -t bind' in /var/lib/dpkg on the XFS-partition. Now everything works fine. I wonder, why the debian-skripts fail on an XFS-partition and work fine on ext2fs. I don't know, if there are bugs in the debian-package-system or if there is a bug in XFS. It's a bit strange, that the same file is removed on ext2fs-partitions and not on XFS-partitions. Nevertheless I'm very impressed by XFS. Thanks, Ralf P.S: My machine is an Athlon 800, 2 IDE-Drives, XFS compiled into the kernel. From owner-linux-xfs@oss.sgi.com Sat Sep 30 19:41:33 2000 Received: by oss.sgi.com id ; Sat, 30 Sep 2000 19:41:13 -0700 Received: from p3EE05993.dip.t-dialin.net ([62.224.89.147]:59798 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Sat, 30 Sep 2000 19:40:47 -0700 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.9.3/8.9.3) id DAA03693; Sun, 1 Oct 2000 03:55:45 +0200 Date: Sun, 1 Oct 2000 03:55:44 +0200 From: utz lehmann To: Andi Kleen Cc: xfs@s2y4n2c.de, Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 - unbootable Message-ID: <20001001035544.A3641@s2y4n2c.de> References: <4.3.2.7.2.20000929114015.02aec2e0@pop.xs4all.nl> <5344.970278363@ocs3.ocs-net> <20000930233527.A926@s2y4n2c.de> <20001001022727.A2644@s2y4n2c.de> <20001001032334.A11618@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20001001032334.A11618@gruyere.muc.suse.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Andi Kleen [ak@suse.de] wrote: > I think I know what the problem is. The old XFS beta5 kernel has attr_* > system calls in the call slots that are fstat64() et.al. on the > RH7.0/later 2.4 kernels. The RH7 glibc seems to expect LFS calls there > (rightfully, because later 2.4 after test5 put them there). Calling > the attr_* calls as different system calls does no good. > > Does it work when you replace the > > .long SYMBOL_NAME(sys_attr_get) > .long SYMBOL_NAME(sys_attr_set) > .long SYMBOL_NAME(sys_attr_remove) > .long SYMBOL_NAME(sys_attr_list) > .long SYMBOL_NAME(sys_attr_getf) > .long SYMBOL_NAME(sys_attr_setf) > .long SYMBOL_NAME(sys_attr_removef) > .long SYMBOL_NAME(sys_attr_listf) > > lines at the end of arch/i386/kernel/entry.S with > > .long SYMBOL_NAME(sys_ni_syscall) > > for each attr line ? > > > -Andi yes, it work with my pre beta kernel from 2000-08-17. and todays cvs kernel (2.4.0-test8 based) works too (without the change above). thanks utz